A Practical Legal Guide for Crypto Founders. Based on our work with early-stage crypto startups and accelerator programs.
Every early-stage crypto founder eventually asks some version of the same question: is it too early to be spending money on lawyers? This legal guide for crypto founders explains which decisions need to be made early, which can wait, and how to tell the difference.
Most founders don’t ignore legal because they don’t care. They ignore it because every startup is a game of prioritization. Shipping the MVP, onboarding users, raising money all feel urgent. Legal almost never does.
The catch is that the legal decisions that matter most are usually the ones that are hardest to reverse later. By the time they become obviously important, changing them can mean restructuring the company, redesigning the token, renegotiating investment terms or rewriting code that’s already live.
It’s a fair question, and the honest answer is that some of it is too early.
Plenty of legal work that gets sold to seed-stage companies is genuinely premature. Licensing applications before there’s a product. Twelve-jurisdiction memos before there are users. A Cayman foundation for a project that will never issue a token.
But a small number of decisions are different. They’re cheap to get right at the start and expensive or impossible to reverse later. The purpose of this article is to separate those two categories.
We use a simple mental model for this, borrowed from how founders already think about their own products: a stack.
Three layers, bottom-up:
- Startup Basics: the foundation every startup needs, crypto or not.
- The Crypto Layer: what being a crypto company adds on top.
- Token, Too?: the additional layer if you issue one.
You build a stack from the bottom. Most of the expensive mistakes we’re asked to fix come from founders who focused on the top and ignored the bottom: they designed tokenomics but never asked how that fits the corporate structure, picked a jurisdiction because a competitor used it, or raised on terms that assumed a token structure nobody had actually analyzed.
There is one question underneath all of this, and it is the only test you need to sort urgent from deferrable.
The Decision Rule
Is it irreversible, or expensive to unwind? Do it now.
Is it cheap to change later? Wait.
Not cost. Not seniority. Not how important it sounds. Reversibility. Every verdict below is an answer to that one question.
Layer 1: Startup Basics
This layer is not unique to crypto startups. It is the same base layer for them as for a B2B SaaS company. It is also, consistently, the layer early-stage crypto teams neglect most, for two main reasons: it feels boring compared to the big questions, and crypto founders have a misconception that a smart contract, a multisig or a “DAO” can live alone on the ether.
Four things live here:
Corporate entity: your legal home base
An entity separates your personal liability from the business, and it is a precondition for almost everything else: raising money, signing contracts, owning assets, opening accounts.
Founders often think about forming an entity when it’s time to raise capital. That makes sense, as investors inject capital into an entity and get equity in it, so an entity is a must-have at that point.
But the reality is that a legal entity is practically speaking a must-have when other things happen, in many cases long before the first raise is on the table: when a project launches, starts engaging users (yes, even Beta users), collecting fees, and engaging with partners, employees or contractors.
Limited liability exists precisely to disconnect the company’s liability from the founders’. Now imagine you start onboarding users and they somehow lose their funds. All the legal disclaimers in the world won’t prevent them from suing. If you have a legal entity, they can sue that entity for everything it has. If you don’t have one, they can sue YOU, personally, for all you have.
Same principle applies to revenues. Yes, these may go to the project’s wallet. But if there is no legal entity wrapping that project, as far as tax authorities are concerned these revenues must be attributed to a legal personality, in this case, potentially YOU again.
The part founders underestimate is that entity type and jurisdiction are substantive choices, not administrative ones. They drive your corporate tax rate, your regulatory exposure, which investors can or would invest, and what a future acquirer or listing venue will accept. Restructuring after the fact is possible, but it is slow, costs real money, and often triggers tax on the way through.
Verdict: do this now. This is not deferrable. Operating with no entity creates real personal exposure for the founders. Operating with an entity chosen in five minutes because a blog post recommended it is one of the most common avoidable problems we see.
Reversibility: low. Undoing it means a new entity, moving assets and IP into it, and often a tax event on the way.
Intellectual property: if it’s not assigned, the company doesn’t own it
This one surprises people. Where a contributor is not an employee, whether a contractor, an adviser, a co-founder who was building before the company existed or someone paid in tokens, the default in most systems is that the author owns what they wrote, not the company that paid for it.
Employment changes the picture: in the US, the UK and much of the EU, code written by an employee in the course of their employment generally vests in the employer automatically. But early crypto teams are rarely built out of employees, which is exactly why the gaps open up here.
So unless IP has been formally assigned, the company may not own its own product. That covers code, designs, names, brand, documentation, anything built. And it needs to be in writing with every contributor: co-founders, employees, contractors, that developer who helped for three weeks in exchange for tokens, the designer who did the logo. Scope-of-employment arguments, moral rights and jurisdictional variation mean an express written assignment is the only reliable answer.
This becomes visible at the worst possible moment. It surfaces in diligence, when a potential investor’s counsel asks for the chain of IP assignment and discovers there isn’t one. At that point your leverage is gone, and a former contributor you parted ways with badly has something you need.
Verdict: do this now, and keep doing it. It costs very little to paper properly at the outset. It costs a great deal to fix retroactively, because fixing it requires the cooperation of people who may no longer be motivated to give it.
Reversibility: depends entirely on other people’s goodwill, which is the worst kind of dependency to build into a company.
Founders agreement: set the rules before you need them
A founders agreement covers equity and token splits, vesting, roles and decision rights, and what happens when someone leaves.
In our experience the founder disputes that do the most damage are not the ones caused by a bad agreement. They’re the ones caused by not having one at all. And the dynamic is predictable: the agreement is easy to write while everyone is aligned and optimistic, and nearly impossible to write once there’s a disagreement about who contributed what, because by then every clause has a winner and a loser.
Two crypto-specific notes:
First, if there is any prospect of a token, the agreement should address token allocation alongside equity, not just equity, because founders often assume their equity split automatically carries over to tokens and it does not unless someone writes that down.
Second, vesting matters more in crypto than elsewhere, because teams change quickly and token allocations are large relative to salaries. But that doesn’t make equity vesting (or reverse-vesting) less crucial.
Verdict: do this now. The best time to sign it is while everyone still gets along.
Reversibility: high today, near zero the moment founders disagree. The window closes without warning.
Tax: three separate questions
Tax exposure for a distributed crypto team is rarely a single question. It’s at least three:
- Where the company is incorporated drives the corporate tax rate and treaty access.
- Where the founders and key people are personally based can create tax obligations in those countries too, both for them individually and, in some cases, for the company through permanent establishment.
- Where value actually accrues determines whether the structure you’ve designed will survive scrutiny.
The failure mode is picking a low-tax jurisdiction of incorporation while the entire team sits somewhere else, and assuming the first fact overrides the second. It generally doesn’t.
Verdict: get the structural questions answered now; defer the compliance machinery. You do not need a full transfer-pricing study pre-seed. You do need to know, before you incorporate, whether the structure you’re about to build creates a tax problem, because getting the structure wrong early creates expensive problems to fix later.
Reversibility: the structure, low. The compliance machinery around it, high. Which is why one is a now and the other is a later.
Layer 2: The Crypto Layer
Now the crypto-specific analysis.
This layer is where the difference between a crypto startup and an ordinary software startup actually bites: a conventional software company usually operates in one legal system and becomes regulated later, if ever. A crypto company can be inside financial-services regulation before it has any revenue.
Centralized or decentralized: a spectrum, not a switch
Centralized means there is an identifiable person or entity exercising control over the project, its operation, or its use.
Decentralized means no single person or entity controls the protocol or is essential for it to function, and participation is open to anyone meeting the technical requirements.
The important point: decentralization is a spectrum, not a switch, and where you sit on it has real legal consequences. The label carries little weight on its own, because what gets assessed is actual control. Who holds upgrade authority and admin keys. Who controls the treasury. Who runs the front end. Who earns fees. Who can pause or censor. Whether governance is genuinely dispersed or effectively concentrated in three wallets.
Very few projects launch as decentralized. Even the ones with the highest and most sincere decentralization aspirations start with a core team and a roadmap to decentralization. That roadmap is the important part at the early stages, and what we urge our clients to do is to be fully honest with themselves (and us) about that part: is that the direction the project is going to go, or is it just a label? That affects how the foundations should be set. A decentralized project needs a legal foundation that supports it in the long run, whereas a partly-decentralized or a DINO (“decentralized in name only”) project should be built to accommodate that.
Verdict: understand your position now; it will change, and that’s fine. Most projects start meaningfully centralized. That is not a problem in itself. The problem is building the foundation wrong.
Reversibility: your position on the spectrum is supposed to change. The foundation you build around it is much harder to move.
Beware of Regulation! Token and services: both matter
Founders tend to assume the regulatory question is “is my token a security?”
That’s one question. It is often not the one that determines their exposure.
The services you provide can bring you into regulatory scope regardless of whether you have a token at all.
Services worth checking against a regulatory perimeter:
- Exchange, custody, transfers: these can fall under crypto-asset frameworks or, in some structures, traditional financial regulation.
- Staking and yield: depending on design, these can look like deposit-taking, collective investment, or a securities offering.
- Vaults: pooled, managed strategies attract different analysis than simple self-custody.
- Moving value: this can cross over into payment services and money transmission regimes.
- Management or advice: fund management and financial advice are separately licensed activities in most significant markets.
Verdict: this is the analysis to do before your architecture hardens. Not because you need a formal legal opinion pre-seed, you generally don’t. But because in a heavily-regulated industry, the regulatory classification of your product should be part of your strategy, not an after-thought: it should guide the product design, as well as the corporate structure and go-to-market strategy. All of these are things that are nearly free on a whiteboard and very expensive once the product is live.
Reversibility: total on a whiteboard. Close to none once the product is live and users depend on it.
Geographic scope: regulation follows activity
Four different geographies, four different sets of obligations:
- Incorporation: where the company is legally set up.
- Clients / users: where your users are actually located.
- Operations: where you and the team actually work from.
- Marketing: where you solicit or advertise. This one alone can trigger rules, independently of the other three.
That last point catches people. Having users in a country is not the same as offering or soliciting services there, and most regulatory perimeters turn on the latter (not the US though…).
But running geo-targeted ads, or onboarding in a local language with local payment rails, can amount to offering services in a market even where you have no entity, no office, and no intention of being there. Regulation follows activity, not just incorporation.
Verdict: map this now, buy advice selectively. You do not need counsel in every country where someone has touched your product. You need to identify the handful of jurisdictions that matter most to you, and that create real exposure given your actual go-to-market, and get proper advice on those. Commissioning twenty memos produces expense and contradictions, not clarity.
Reversibility: reasonably high. You can enter a market later. Retreating from one you have already entered, and already marketed into, is the harder direction.
Your legal structure determines who will work with you
Founders often think legal exists to satisfy regulators.
In practice, many of the first people who care about your structure aren’t regulators at all. They’re the banks onboarding you, the exchanges and launchpads reviewing your listing application, the institutional investors running diligence, the payment providers deciding whether to serve you, and the enterprise customers whose procurement team needs someone to sign a contract.
Your structure determines whether these conversations are easy, difficult or impossible.
- Banks and payment providers will not open an account for a project without a clear corporate structure, identifiable beneficial owners and a jurisdiction they are willing to bank. This is a commercial policy question, not a legal one, and no amount of being technically in the right will change a compliance officer’s mind.
- Exchanges and launchpads run their own diligence before listing. That typically means questions about your entity, your token’s classification, who your prior distributions went to, and whether anyone can sign an enforceable listing agreement.
- Institutional investors are often constrained by their own fund documents about what they can hold, from which jurisdictions, and in what form. A structure that makes you uninvestable to half your target list is a commercial problem that looks like a legal one.
- Enterprise customers need a counterparty that can sign a contract, indemnify them, carry insurance and pass a vendor review. An unwrapped protocol or a DAO usually cannot do any of that.
That last point is not hypothetical. In March 2026, Risk Labs, the team behind Across Protocol, proposed converting the project into a US corporation and buying out its token holders, stating that the existing token and DAO structure had materially impaired its ability to close partnerships with institutional and enterprise counterparties and to enter into enforceable contracts. A well-funded, well-regarded team paid to exit a structure it had already built.
Verdict: think about this now, revisit it at every stage. You do not need to optimize for counterparties you won’t meet for two years. You do need to avoid building a structure that quietly disqualifies you from the partnerships your business plan depends on.
Reversibility: technically possible, as Across shows, but it took a governance vote, a corporate conversion and a buyout of every token holder. That is the expensive version.
Layer 3: Token, Too?
The top of the stack is conditional, and worth stating plainly: many blockchain projects never need a token.
To Token or Not to Token?
The recurring pattern we see is founders deciding to issue a token because the market expects one, then working backwards to find it a use. That order produces a token whose function is decorative and whose classification is therefore harder to defend, since a token with no genuine protocol purpose is hard to distinguish from a purely investment instrument.
We have the same conversation with almost every crypto founder: “does the project NEED a token?” If it does, great. If it doesn’t, let’s discuss why you want it, and make sure you understand the tradeoffs. In some cases, having a token makes sense even if it is not absolutely required for the project to work. To raise funds, to create a community around it, to incentivize users, to allow founders and backers to bring money home without draining protocol revenues. All valid reasons. But that comes with a price, and we often mention the big 3:
- Focus. Once a token is out there, the team’s attention is immediately divided between the project and the graph. This affects both ability to build, and how every decision is being made: not only how it would help the product, but also how it would affect the token.
- Fastest way for a good project to die. A great project with a token going to near-0, for whatever reason, is effectively dead. Everything you have built doesn’t matter if the token crashes beyond repair. And remember, you don’t always control the circumstances or the narrative.
- Increased Risk. Our job is to help you mitigate legal and regulatory risks in connection with your token (and everything else). But even the most conservative and calculated token launch carries residual risks, from regulatory action to unhappy token holders. No one can make those risks go away entirely.
Verdict: Consider it now; be honest with yourselves and your advisors, and seriously consider whether a token is right for you.
Reversibility: issuing a token is one of the least reversible things you will ever do. Deciding not to issue one yet costs nothing.
Raise strategy: equity, token, or both
There are three broad shapes:
- Equity. Traditional. Investors get shares in the company. Simplest and best understood, and many blockchain companies never need anything else.
- Token. Investors receive tokens at a future launch. Note that this can still trigger regulation depending on how it’s structured. The absence of shares does not by itself mean the absence of a regulated instrument.
- Hybrid. Investors get equity now plus rights to tokens later. This balances traditional VC expectations against crypto-native ones, and it preserves flexibility to decide the token question later.
Structure this before you raise, not after. Fundraising terms are the hardest thing on this list to unwind, because unwinding them requires renegotiating with people who have already wired money. A side letter promising tokens on terms that turn out to be unworkable is a problem you will be living with for years.
Verdict: Consider the shape now; you can defer the detail. This folds back to the previous question of whether you should have a token at all, and should be considered as part of that decision. What the actual raise terms look like can be determined when the time is right.
Reversibility: near zero once the money is wired. This is the single least reversible item in the article.
Token regulatory treatment
As above, the regulatory treatment of the token is generally separate from that of the product and services.
The things to look at are:
- The token itself. Is it a security? A derivative? Asset-backed or a stablecoin? Each of these leads somewhere different.
- Token features. Staking, yield, and buyback-and-burn mechanics all feed back into classification. A token that accrues value to holders through protocol revenue is a different legal object from one that doesn’t, even if the whitepaper describes them the same way.
- The token sale. This is a separate analysis from the token’s own characteristics. In SEC v. Ripple Labs (S.D.N.Y. 2023) the court found the same token had been sold as an investment contract to institutional buyers under written contracts, but not in programmatic sales on exchanges. Other judges in the same district declined to follow that manner-of-sale distinction, and it was never tested on appeal. The underlying point survives the disagreement: who you sell to, how, and when is its own question.
Token design
If you do launch a token, again the right time to analyze and consider its regulatory status is at the design stage. Many times, a minor tweak can significantly reduce the risk of a token being non-compliant or falling within a harder regulatory perimeter. These changes are easy to do at the planning stage, very hard after the whitepaper is out, and near-impossible after launch.
A good advisor would help you separate the core features of the token from the nice-to-haves, and accordingly point to the things that need fixing, those that can easily be replaced with less risky features, and help you get to the design that reaches your goal with the lowest risk of inadvertently being treated as a regulated instrument.
The high-level characteristics of the token, those you would include in an early litepaper or investor deck, should be carefully considered in light of regulatory and structural considerations, alongside the business ones.
Changing the essentials after putting them out there doesn’t look great. And the project’s foundations should be set in light of what you expect the token to look like: a memecoin, a utility token, a governance token and a staking token should each be supported by the appropriate legal foundations.
Which is why designing the token’s core should go hand in hand with the considerations laid out in the first two layers above.
Verdict: Consider the core now; if launch is later, you can defer the detail.
Reversibility: high at design stage. Much lower after the whitepaper is published. Near zero after launch.
Token sale and launch
There are many ways to launch a token, from a public sale to a fair launch, each with its pros, cons and regulatory implications.
As above, how you sell a token and to whom carries significant regulatory implications, independently of the token’s own characteristics. A pre-sale of a non-security token can in itself be a securities offering, and a sale of tokens that are securities to accredited investors can be exempt from securities law registration, but has to follow clear rules. And any sale of any crypto may separately trigger regulatory implications outside of the securities world, from AML/KYC requirements to a full blown crypto licensing regime for operating something like an exchange. Work absolutely needs to be done here.
In most cases, the token sale and launch happen at some later stage. Deferring the legal work related to that makes perfect sense in most cases: deciding on the chosen sale path in light of both business and regulatory considerations, drafting and negotiating sale terms, engaging with launchpads, compliance checklists. All of these can be done when the time is right, and don’t need to happen on day one.
One thing to THINK about at the early stage: what type of sale and launch would fit what you’re building. If there is a clear path, take that into account in building the infrastructure out the gate.
Verdict: Defer the work; consider the strategy early on to be taken into account when building the foundation.
Reversibility: high. This is genuinely deferrable work, which is exactly why it belongs at the top of the stack.
Mythbusters
Five things we hear constantly that do not do the work founders think they do.
“We’re decentralized.” Decentralization affects your regulatory exposure. It doesn’t eliminate it. And what counts is measured control, not self-description.
“We’re just a tech company.” The activity your product performs determines whether you’re regulated, not what you call yourself. Building software that custodies assets and moves value is generally treated as a regulated activity performed with software.
“We’re offshore.” Being incorporated somewhere else doesn’t make other countries’ regulators disappear. Their jurisdiction generally attaches to where the activity reaches, not where the certificate of incorporation is filed.
“We’re a DAO.” A DAO is a governance mechanism, not a legal form. It is not a recognized structure in most jurisdictions, and it does not automatically make you decentralized. Without a wrapper, a DAO risks being characterized as a general partnership or unincorporated association, and US courts have allowed claims on that basis to proceed against DAO token holders, which can expose active participants personally.
“We’ll fix it after launch.” Sometimes you can. Often you can’t. Legal work that shapes the company’s foundations is dramatically cheaper before investors, users and token holders are relying on those foundations.
So what can actually wait?
This is the part that usually goes unsaid, so let’s say it clearly. A great deal can wait.
Do now, because it’s cheap now and expensive or irreversible later
- Incorporate, in a jurisdiction chosen for reasons you can articulate.
- Understand the regulatory and tax consequences of your structure before you build it.
- Assign all IP to the company, from every contributor, in writing.
- Sign a founders agreement covering equity and tokens, with vesting.
- Decide the shape of your raise before you take money.
- Sanity-check whether your product performs a regulated activity, and where.
- Sincerely assess whether you should have a token.
Do soon, around your first meaningful raise, your first users, or your first hires
- Proper classification analysis for any token you actually intend to issue.
- Raise documents.
- Jurisdiction-by-jurisdiction assessment of high-impact markets: where you are, and where your key target markets are.
- Terms of service, privacy policy, and a real data-protection position, before launch.
- Employment and contractor documentation that matches how the team works.
Do later, when there’s funding, headcount, and a product that justifies it
- License applications and authorizations, where appropriate, before launching any regulated product.
- Full AML/CFT programs, policies, and a compliance function, where appropriate, before launching any regulated product.
- Multi-jurisdiction legal opinions.
- Listing opinions, which are usually requested late and needed fast, and which go much smoother when the classification work above was done properly at design stage.
One carve-out on that last group: it assumes you are not yet live in a regulated market. If you are already onboarding users somewhere with an authorization regime, or the product is one where authorization is a precondition to operating at all, such as stablecoin issuance, custody or running an exchange, then licensing is not a “later” item and treating it as one is the risk.
The distinguishing test is the one we started with. Not cost, not seniority. Reversibility. Something you can buy later at the same price is deferrable. Something that gets welded into your cap table, your token supply, your corporate structure, or your deployed code is not.
On cost
Two things drive the cost of early-stage crypto legal work, and neither is billable hours.
The first is how much of the picture is undecided. Advice on a settled business model is a bounded piece of work. Advice on a business model that might pivot into payments, or might issue a token, or might target the EU, has to cover every branch, and costs accordingly. Founders who arrive with a clear description of what the product does spend materially less than founders who arrive with a range.
The second is how much has already been built. Analysis before deployment is design work. The same analysis after deployment is remediation, and remediation is where the numbers get unpleasant, because it involves undoing things other people are relying on.
Which means the way to spend less overall is usually to spend a little earlier, on a narrow scope. A minimum-viable legal framework for a pre-seed team is a real deliverable: entity, IP, founders agreement, and a scoped read on whether the product is regulated and where. That is a defined, fixed-scope project, not an open-ended retainer.
The short version
Crypto founders do not need to solve every legal question on day one.
They do need to solve the handful of questions that shape every decision that follows.
That’s the purpose of the Legal Stack: not to tell you to do everything now, but to help you recognize what becomes exponentially harder to change later.
Get those foundations right, and almost everything else becomes easier. Get them wrong, and you spend your Series A cleaning up your pre-seed.
Working through any of this? DLT Law works with early-stage crypto teams on exactly this scope, and initial consultations are free. Get in touch.
This article provides general information only. It does not constitute legal, tax or financial advice, and it does not create a lawyer-client relationship. Every situation is different; regulation of digital assets changes frequently. For advice on your circumstances, contact DLT Law directly.
Last reviewed: July 2026
