Operations for web3 and crypto companies

I cofounded a Web3 platform, structured it as a Delaware public benefit corporation, and ran its entity, IRS and platform work end to end. So the answer is the specific one: I have filed the things, held the calendar and had the awkward conversation with a bank.

What that does not make me is a protocol engineer or a token lawyer, and the page is honest about where those lines sit.

No, and you should be wary of anyone who offers it alongside operations work. Contract auditing is a specialist security discipline with its own firms and its own track records.

What happens here is the operational layer around it: who can deploy, what the review step is before a deployment, how key holders are added and removed, and what the record shows afterwards.

No. That is counsel, and it needs to be counsel who does this specific thing in your jurisdiction.

What is useful is the layer underneath: separating what the rule actually requires from how your company satisfies it, so that when the answer moves, and it will, only the second part gets rebuilt. Working alongside your counsel rather than instead of them is the whole point.

It is normal and it is manageable, and it is usually the least documented part of the business.

The work is a written onboarding and offboarding path, an access list that is actually accurate, agreements that exist and are signed, and a payment process that does not depend on one person being online. None of that changes how you work, it just makes it provable.

Answering them before they are asked. Almost every counterparty asks the same set: entity chart, filings current, signing authority, payment approvals, contractor agreements, access control, incident history.

Assembling that once, and then keeping it current on a rhythm, converts a recurring scramble into a folder. Companies that do this close faster and negotiate better, because the other side stops discounting for uncertainty.

No. Engagements are invoiced and paid conventionally.

That is a deliberate choice rather than a judgment about your treasury. Introducing a volatile asset into a service relationship adds a variable neither side needs.

The opposite, though it does change what you document. Writing down a procedure that assumes a specific rule is fragile. Writing down what the rule requires, separately from how you currently satisfy it, is durable.

When the requirement moves you rewrite one layer. Most companies write only the second layer, which is why every change feels like starting over.

It should not, and if it does the scope is wrong. The point is removing the things that stop being possible when one person is asleep, not adding approval to work that never needed it.

The test is whether the team can do more without asking anyone. If the answer after an engagement is no, it failed.

Yes, and it is a common shape. What matters operationally is that the chart is written down, that each entity has a named owner for its obligations, and that intercompany arrangements are documented rather than understood.

Where a jurisdiction needs local counsel or a local agent, that gets brought in for that piece.

Mapping what exists: entities and their status, who holds what access, how money actually moves, and where the records live. Most of that comes from watching rather than from asking.

The output is a picture of the operation as it really runs and a ranked list of what to fix first. It is usually the first time anyone has seen the whole thing on one page.