A token purchase agreement (TPA) is the private, bilateral contract that fixes price, delivery, vesting and compliance terms for a token investment. It is the single document founders, investors and counsel must get right before any consideration changes hands.
Before drafting or signing one, scan this checklist. A properly built TPA addresses every item below, and regulators including the SEC increasingly expect to see all of them documented, not implied.
- Purchase price and token quantity, with the pricing formula stated if payment is in cryptocurrency
- Delivery mechanics, including the wallet address, network, and delivery timing
- Escrow agent identity and the conditions under which funds are released or returned
- Vesting schedules and lock-ups, whether contractual, smart-contract enforced, or both
- Representations and warranties from both issuer and purchaser, including sanctions and AML status
- Compliance and KYC obligations, typically tied to accredited investor status under Regulation D
- Governing law and dispute resolution mechanism
- Termination rights and remedies if closing conditions fail or a party breaches
Miss any one of these and you are left with a document that looks like a contract but performs like a handshake.
What is a token purchase agreement and how does it differ from other sale documents?
A TPA is a signed contract between an issuer, a purchaser and, in most structured deals, an escrow agent. It sets binding terms for a specific token allocation rather than a general offer to the public. That distinction matters legally: a TPA is negotiated privately, whereas an initial coin offering or public crowdsale solicits an undefined pool of buyers under standard terms nobody negotiates individually.
The private nature of a TPA is precisely what lets many issuers rely on registration exemptions. A TPA built for Regulation D reliance targets accredited investors specifically and documents that status in the agreement itself, something a public sale page never does. Compare that to a simple purchase receipt, which records that money changed hands but says nothing about vesting, warranties, or what happens if the tokens never get delivered.
Payment structures vary. Some TPAs fix a price in US dollars and accept payment in stablecoins or fiat; others price in crypto and lock an exchange rate at signing or at a defined settlement window, similar to the mechanics seen in commercial cryptocurrency purchase agreements used between institutional counterparties.
Quick contrast for choosing the right instrument:
- Public ICO or crowdsale: standard terms, no negotiation, broad distribution, minimal individual documentation
- Simple purchase receipt: records payment only, no warranties, no delivery guarantees
- Token purchase agreement: negotiated terms, accredited investor targeting, full representations, vesting and compliance built in
When should founders or investors insist on a TPA?
Not every token transfer needs this level of documentary rigour. A TPA becomes necessary once the transaction carries real legal or financial exposure. Use this sequence to decide:
- Check the offering structure. Private placements, Regulation D offerings, and any deal targeting institutional anchor investors need a TPA as a baseline, not an option.
- Assess materiality of funds. A five-figure allocation from a family office or fund almost always warrants a full TPA with escrow and warranties; a nominal community allocation may not.
- Confirm whether vesting or lock-ups apply. Strategic allocations to founders, advisors or early backers with cliffs or multi-year vesting require a TPA to make the schedule enforceable.
- Test investor sophistication. Retail-facing sales carry different disclosure obligations than sales restricted to accredited or institutional buyers.
- Map jurisdictional risk. Cross-border purchasers introduce sanctions, tax and enforceability questions that only a properly governed contract addresses.
- Decide on the custody model. If tokens carry governance rights or on-chain voting power, the TPA must state what those rights are and when they attach.
If two or more of these apply, treat a lightweight document as a liability, not a shortcut.
What clauses does every token purchase agreement need?
This is where most TPAs succeed or fail. A vague clause here is not a stylistic weakness, it is an enforcement risk. Work through each provision methodically.
Subject matter and definitions. State the exact token name, the technical standard (ERC-20, BEP-20, or a native chain asset), the network it runs on, and whether fractional units are permitted. Ambiguity here has sunk more disputes than pricing arguments ever have.

Purchase mechanics. Fix the purchase price and total token quantity. If payment is in cryptocurrency, specify the pricing formula, the reference exchange or price feed, the exchange-rate window, and rounding rules for fractional amounts. A formula referencing a live market feed, similar to the pricing data shown on platforms like Handy, avoids disputes over which price applied on which day.
Payment and escrow. Name the escrow agent explicitly and describe release conditions in full. Public TPAs illustrate this well: the INX agreement authorises an escrow agent to hold funds and sets multi-currency payment options in USD, BTC and ETH alongside defined acceptance and rejection mechanics. Refund triggers belong here too, not buried in a general remedies clause.
Closing and delivery. Specify delivery to a named wallet address, whether a test transfer precedes the full transaction, and what documentary evidence of delivery looks like. A transaction ID and a signed acceptance certificate are now standard practice, and drafting guidance from Lawrange recommends exactly this pairing for any transfer of meaningful size.
One of the starkest clauses in a real-world TPA sits in the Blockstack agreement filed with the SEC: purchase amounts can be non-refundable even though the token distribution event "may never occur." Purchasers explicitly acknowledge they might lose the full amount paid with no tokens delivered in return.
Vesting and lock-ups. Set out cliffs, vesting cadence, and any acceleration triggers tied to acquisition or termination events. Decide whether the lock-up is enforced by smart contract, by contractual covenant, or both, and say so.
Representations and warranties. The issuer typically warrants good title to the tokens and corporate authority to sell them. The purchaser typically warrants accredited investor status, absence of sanctions exposure, and completion of AML/KYC checks, a structure the INX agreement builds directly into its subscription and eligibility mechanics.
Restrictive covenants. Transfer restrictions and resale conditions tied to securities exemptions need their own clause, separate from general vesting language, so counsel can amend one without disturbing the other.
Indemnities and liability caps. State a liability cap, carve out consequential loss where commercially sensible, and confirm which party indemnifies which for breach of representations.
Governing law and dispute resolution. Choose arbitration or courts deliberately, not by default template language, and consider enforceability of that choice against a purchaser in a different jurisdiction.
Termination and remedies. Address rejection of subscription, refund triggers, and consequences of a failure to close by a stated deadline.
Audit and inspection rights. Grant the purchaser reasonable rights to request records, escrow statements, and blockchain evidence such as explorer screenshots confirming delivery.
Ancillary clauses. Confidentiality, data protection where personal data is processed, tax reporting obligations, and a notices clause round out a complete agreement.
Pro Tip: Never let a "form" TPA sit unamended for a deal with different economics than the one it was drafted for. The clause most often left stale after a template reuse is the pricing formula, and that is the clause most likely to trigger a dispute.
What securities risks apply to token sales in the United States?
Most token sales in the United States sit under the shadow of the Howey test, the Supreme Court framework that asks whether an arrangement involves an investment of money in a common enterprise with an expectation of profit from others' efforts. A TPA does not settle that classification question by itself. No amount of contractual disclaimer language converts a security into something else if the underlying economic reality says otherwise.
What a well-drafted TPA does is support a documented attempt to fit within a recognised exemption, most commonly Regulation D. That means accredited investor representations, verification procedures, and disclosure of risk factors written into the contract itself rather than left to a separate memorandum nobody reads closely.
Fair market value for an early-stage token is inherently subjective and volatile. Boards that fail to document their valuation methodology in minutes or a formal valuation report leave themselves with no defensible answer when a regulator or a disgruntled investor later asks how the price was set.
Practical compliance steps that reduce enforcement exposure:
- Verify accredited investor status through a qualified third-party verifier, not a self-certification checkbox alone
- Run AML/KYC screening and sanctions checks before funds are accepted, mirroring the eligibility gating built into agreements like INX's subscription terms
- Tie closing conditions to defined regulatory milestones, such as a minimum offering amount or a qualification deadline
- Hold funds in escrow until closing conditions are objectively satisfied, not at the issuer's informal discretion
- Record the pricing rationale in board minutes or an independent valuation exhibit, not just in the TPA's recitals
SEC enforcement in this sector tends to focus less on the wording of any single clause and more on whether the substance of the transaction matched the disclosures made to the purchaser. A TPA cannot outrun bad substance, but it can create the paper trail that shows an issuer took the exemption seriously. Founders operating across jurisdictions should also weigh how tokenisation laws diverge internationally before assuming a US-focused TPA structure transfers cleanly elsewhere.
What should a drafting checklist and sample clauses include?
Before signature, work through this operational checklist rather than relying on the TPA's text alone:
- Confirm the purchaser's wallet address and network compatibility
- Execute a small test transfer before the full transaction, particularly for high-value allocations
- Confirm the escrow account is open and funded rails are tested
- Complete KYC and, where applicable, collect tax forms
- Capture the transaction ID and issue a signed acceptance certificate at closing
Sample purchase mechanics clause (annotated): "The Purchaser agrees to acquire [number] Tokens at a price of $[X] per Token, payable in [currency], with the total Purchase Price fixed as of the Effective Date." Annotation: if payment is in crypto rather than fiat, add a defined exchange-rate window and name the reference price source rather than leaving "market price" undefined.
Sample escrow clause (annotated): "Funds shall be held by [Escrow Agent] and released to the Issuer only upon satisfaction of the Minimum Offering Amount, or returned to the Purchaser if such condition is not met by [date]." Annotation: name the escrow agent explicitly. A clause referencing "a qualified escrow agent" with no name attached is a red flag, not a placeholder.
Sample vesting clause (annotated): "Tokens shall vest over [period] with a [X]-month cliff, subject to acceleration upon [defined event]." Annotation: decide upfront whether vesting is enforced by smart contract, contractual covenant, or both. If a smart-contract lock-up could fail or be bypassed, include fallback contractual language obligating the purchaser not to transfer regardless of on-chain enforceability, a separation of concerns visible in open-source crowdsale contract design that deliberately splits delivery logic from fund handling.
Sample refund and termination clause (annotated): "In the event the Token Distribution Event does not occur by [date], the Purchase Price shall be refunded in full within [X] business days." Annotation: without this clause, silence favours the issuer, not the purchaser.
The safest evidentiary posture at closing pairs three things: the transaction ID, a written escrow confirmation, and a signed acceptance certificate. Missing any one of the three weakens a purchaser's position if delivery is later disputed.
Pro Tip: Draft the acceptance certificate as a standalone exhibit, not a paragraph buried inside the main agreement. It is the document most likely to be produced as evidence months or years later, and it should be legible on its own.
What negotiation points and red flags should you watch for?
Founders typically push for flexibility on delivery timing and broad discretion to reject subscriptions. Investors typically push back with pricing floors, defined escrow periods, and firm acceptance deadlines. Where the negotiation lands usually signals how seriously the issuer takes its own compliance posture.
Watch for these red flags before signing anything:
- Vague token description that omits the network or technical standard
- Indefinite or open-ended delivery timing with no outside date
- Issuer reserving unrestricted, unilateral acceptance rights with no objective criteria
- No named escrow agent or bank account details disclosed anywhere in the document
- Pricing formula that references "market rate" without naming a source or window
Negotiation tips worth insisting on: require a test transaction before full transfer, demand written escrow confirmation once funds are received, and capture objective valuation support as a signed exhibit rather than a verbal assurance.
Pro Tip: Push for narrowly drafted transfer restrictions paired with a clear acceleration regime triggered by founder misconduct or insolvency. Broad, one-sided lock-ups without a corresponding protection for the purchaser rarely survive serious negotiation.
How does closing actually work from start to finish?
A TPA closing is an operational sequence, not a single signature moment. Treat it as a checklist with clear ownership at each stage.
- Pre-closing: complete KYC/AML screening, verify accredited investor status, open the escrow account, and test both bank and crypto payment rails.
- At closing: execute payment, run a test transfer where the allocation size justifies it, capture the transaction ID, confirm escrow release conditions are met, and issue the signed acceptance certificate.
- Post-closing: record the transaction in the cap table or token ledger, meet tax reporting obligations, enforce transfer restrictions going forward, and maintain ongoing compliance monitoring.
Timing varies by deal, but sample SEC filings and commercial agreements offer useful benchmarks. Escrow is commonly held until a Minimum Offering Amount is met, and some commercial settlement structures set tight windows, such as a one-hour settlement window from the settlement summary in institutional crypto purchase agreements, with additional charges or close-out rights if that window is missed.
Where can you find public sample TPAs and templates?
Several publicly filed agreements are worth reading in full before drafting your own. Each demonstrates a different mechanic worth borrowing, carefully.
- The Blockstack Token Purchase Agreement, filed as an SEC exhibit, shows non-refundable purchase language and explicit delivery-risk disclosure.
- The INX Token Purchase Agreement, also an SEC exhibit, demonstrates online subscription flows, multi-currency payment and escrow authorisation.
- The Galaxy Digital Cryptocurrency Purchase & Sale Agreement, available via Justia's public contracts database, illustrates institutional settlement windows and default remedies.
- Generic FreshDox-style TPA templates offer a starting skeleton but rarely contain jurisdiction-specific representations or accredited investor mechanics tailored to your deal.
Before using any public exhibit as a starting point, check jurisdictional differences, tailor the representations and warranties to your actual investor base, and replace any sample escrow agent name with the one you have actually engaged. A public filing tells you what worked for another company's facts; it says nothing about whether the same clause protects you.
How Cryptoverselawyers approaches token purchase agreements
Cryptoverselawyers drafts TPAs regulator-first, not template-first. That means every pricing clause is built to withstand scrutiny, with valuation rationale recorded in board minutes rather than left implicit in the contract's recitals, and every escrow structure is stress-tested against custody and prudential expectations before a client signs anything.

The firm advises across VARA, SCA, DFSA and FSRA, giving founders and investors a single point of reference when a token sale touches more than one regulatory regime. Client engagements typically start with structuring the offering exemption, move through drafting and negotiation, and close with escrow and delivery support, producing a TPA built to hold up months or years after signature, not just at the moment of closing.
Get regulator-ready support drafting your token purchase agreement
Cryptoverselawyers is the alternative to relying on a borrowed SEC exhibit and hoping it fits your facts. Where a public template gives you generic language, a bespoke engagement gives you a TPA built around your actual investor base, your actual jurisdiction, and your actual escrow provider, drafted by lawyers who work inside VARA, SCA, DFSA and FSRA frameworks daily rather than reading about them.
Cryptoverselawyers supports the full lifecycle: TPA drafting and negotiation, regulatory alignment for digital asset transactions, and hands-on escrow and closing operations once terms are agreed. Founders raising through private placements benefit from tokenisation structuring support that treats the TPA as one part of a wider compliance architecture, not a standalone document. If you are preparing a token sale and want a contract that survives regulatory scrutiny rather than merely looking the part, book an advisory call through legal support for token launches and get your drafting checklist reviewed before terms are finalised.
Frequently asked questions
Is a token purchase agreement legally binding? Yes, once signed by both parties it functions as a standard contract enforceable under whichever governing law clause the parties selected, subject to the underlying transaction not being void for illegality.
Does a TPA guarantee the tokens will be delivered? No. Sample filings such as the Blockstack agreement explicitly warn purchasers that the token distribution event may never occur, even where the purchase amount is non-refundable.
Do I need a lawyer to adapt a public SEC exhibit template? Strongly advisable. Public exhibits reflect one company's facts, jurisdiction and investor base. Reusing the language without tailoring representations, escrow details and compliance mechanics to your own deal creates real legal exposure.
What is the difference between a TPA and a subscription agreement? The terms are often used interchangeably in practice, though "subscription agreement" is more common in securities-heavy contexts, while "token purchase agreement" is the standard term specifically for token or digital asset acquisitions.
Can a TPA include voting or governance rights? Yes, where the token itself carries governance features. The agreement should state explicitly when those rights attach, whether at closing or after a vesting condition is satisfied, since silence on this point invites disputes later.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.
Sources
- BLOCKSTACK TOKEN TOKEN PURCHASE AGREEMENT (SEC exhibit)
- INX token purchase agreement (SEC exhibit)
- Cryptocurrency Purchase & Sale Agreement with Galaxy Digital | Athena Bitcoin Global | Business Contracts | Justia
- How to Draft a Cryptocurrency Purchase Agreement | Lawrange Articles
- contracts/crowdsale/Crowdsale.sol at v1.7.0 · OpenZeppelin/openzeppelin-contracts

