The Web3 founder’s legal-readiness checklist
You cannot reclassify a token after the sale, or undo a fiat flow after it has happened. The legal structure of a Web3 build has to be set in the right order, before the launch, not after. This is the checklist we run with founders building across India, the UAE and the US.
Work through it in order. Each item is a decision that gates the next one. The aim is to find the gaps while they are still cheap to fix, before a token sale, a banking application, or an investor’s diligence makes them expensive.
Entity and jurisdiction
Where the development company, the foundation, and the token issuer each sit.
- Where do your users, buyers and investors actually sit, and does your home jurisdiction permit the activity? Some jurisdictions are DeFi-unfriendly by default, which forces the question early.
- Is the structure built before the token, not after? A foundation-plus-devco split (for example a Cayman or UAE foundation with a Delaware or BVI development company) is hard to retrofit once tokens are live.
- Is the UAE leg a regulated free zone (DMCC, ADGM, or RAK / Innovation City) with real substance, or a mailbox? Substance is now the test, not the address.
- Where does the India leg sit, and how does value move between the entities under FEMA?
Token classification
What your token is in law, which is answered separately in every jurisdiction you touch.
- Have you classified the token in each place your buyers sit? The same token can be a security in the US under the investment-contract test, a regulated virtual asset under VARA or ADGM in the UAE, a crypto-asset under MiCA in the EU, and a taxable VDA in India.
- Do the documents match what the token actually does? Writing “utility token” does not change an economic reality that reads like a security.
- Have you fixed the classification before the sale? You cannot reclassify after buyers have paid.
Licensing and registration
The authorisations your specific activity triggers, by jurisdiction.
- Does your activity (exchange, custody, broker-dealer, token issuance) require a VARA licence in Dubai, or an ADGM / FSRA authorisation in Abu Dhabi?
- If you serve Indian users, do you need FIU-IND registration as a VDA Service Provider, with the AML obligations that follow?
- If US persons can transact, have you checked money-transmitter / MSB and the SEC and CFTC posture?
- Do you have a named Compliance Officer or MLRO, and a pre-application gap analysis before you file?
AML, KYC and the Travel Rule
The programme a regulator, an auditor, or a bank will ask to see.
- Is there a written AML/CFT policy with a named person responsible? A tool you bought is not a policy.
- KYC on users, sanctions screening, and a suspicious-transaction reporting process that actually runs?
- Are you ready for the FATF Travel Rule on transfers between service providers?
Taking fiat, and getting banked
The compliance layer that appears the moment real money touches the product.
- Who holds the fiat? Taking card or bank payments adds a compliance layer that usually runs through a regulated banking or payments partner, not your own entity.
- Can you show a clean source of funds? A bank needs the off-chain documents that explain your on-chain flows; “trust the chain” is not a paper trail.
- Does the structure read as coherent? A token issued in one place, a company in another, and a bank in a third, with no story connecting them, reads as structuring and gets declined.
Tax
The liability that does not wait for you to be ready.
- Where is your taxable nexus, and is there permanent-establishment risk from where your team actually works?
- India exposure: the 30% flat VDA tax with no loss set-off, plus 1% TDS on transfers materially changes a business model. Has it been modelled, not assumed?
- UAE corporate tax, US tax, and VAT / GST treatment of your fees and token flows?
- Is transfer pricing between the foundation, the devco and the India entity defensible?
Data protection
Your KYC and user data are personal data, governed wherever your users live.
- Lawful basis and consent for the personal data you collect, under DPDP (India), GDPR (EU) and the UAE PDPL as applicable?
- A breach-notification process that exists before there is a breach?
- Cross-border transfer of user data handled lawfully between your entities?
IP, contracts and governance
Who owns what, who can bind the entity, and who controls the treasury.
- Is the IP assigned to the right entity, with contributor and contractor agreements that actually transfer it, including anonymous contributors?
- Clear token-holder terms, and a privacy and risk-disclosure set that matches the classification?
- If there is a DAO, does it have a legal wrapper? Without one, members can be treated as partners and carry personal liability.
- Treasury and multisig controls that map to the charter, so the on-chain governance and the entity agree?
Sequence the structure before you launch. Jurisdiction decides what you can do; classification decides what the token is; licensing, AML, banking and tax decide whether you can take real money for it. Get them in that order, before the token sale and before the data room, because almost none of it can be undone cleanly after the fact. The legal homework is not the afterthought to a Web3 build. It decides where the build is allowed to exist.
Building across India, the UAE or the US?
Send us your structure and we will map the gaps against this checklist, in one call, before they cost you a licence or a banking relationship.
Want this as a PDF in your inbox?
Email us and we will send the current version, and the updated one each time the law moves. Or print the page: it is built for paper.
This checklist is general information for founders, not legal advice for your specific company, token, or transaction. Regulatory positions across India, the UAE, the EU and the US change; confirm every point against current law before relying on it. The right structure depends on your activity, your users, and the jurisdictions you touch. Have your setup reviewed before launch.
Prepared by Infinilex Consultancy · infinilex.io · Verified as of 30 June 2026. Printed copies date; check infinilex.io/resources/ for the current version.