What Is a Token Cap Table? Allocation, Vesting, Dilution

A token cap table is the document that tells everyone with a stake in your project, your lawyers, your investors, your exchange partners, exactly who holds what, when it unlocks, and how much dilution each future event creates. If you have started building one in a spreadsheet and it already feels wrong, that instinct is correct. It probably is.

None of that matters if the underlying business is not creating real value. A cap table tracks how ownership and dilution move through a project; it does not answer whether the venture behind the token is building something worth owning a piece of. That is the question your lawyers, your investors, and your exchange partners are actually testing when they check the numbers against reality, and it is why a clean allocation table sitting on top of a business that does not work is still worth nothing. This is a plain-language walkthrough of what a token cap table actually needs to contain, why the equity cap table format your lawyer already knows breaks the moment tokens enter the picture, and where founders most often find out the hard way that a column was missing.

#What a token cap table actually is

A token cap table is a living record of every token allocation, its vesting schedule, and its dilution effect on circulating and fully diluted supply. Unlike an equity cap table, it cannot be a single snapshot. It has to move with the project, because token ownership changes shape continuously as unlocks happen, not only when a new financing round closes.

The reason this matters goes beyond spreadsheet hygiene. The cap table exists to protect the underlying business's credibility with the people who will scrutinize it: investors modeling their own dilution, lawyers confirming distribution matches what the SAFT or token warrant disclosed, and exchanges reconciling circulating supply against what gets reported publicly. A cap table with gaps is not a clerical problem. It is a diligence problem that surfaces at the worst possible moment, usually right when someone outside the founding team starts asking questions the document cannot answer.

#The equity cap table your lawyer already knows

An equity cap table answers one question well: who owns what percentage of the company right now. Rounds close, the table updates, and between rounds the ownership picture is static. Your lawyer and your accountant both know this format cold, and most founders reach for it first because it is the only cap table format they have ever seen.

#Why token cap tables need more columns, not just different labels

The gap is not cosmetic. Equity cap tables track ownership percentage at a point in time. Token cap tables must also track unlock timing and circulating supply over time, because a holder's share of the outstanding supply shifts every time another allocation vests, even when their own token count never changes. A format with no place to record cliff length, vesting duration, or unlock cadence cannot represent that movement. It can only represent a snapshot, and a snapshot is the wrong tool for a number that changes every week.

See the token allocation strategy framework for the benchmark percentages behind each category above.

#The stakeholders reading your cap table (and what each one needs from it)

A cap table gets read by more people than the founding team, and each one is looking for something different.

#Legal, investors, exchanges, and your own team

Legal needs the cap table to confirm the distribution plan matches what the SAFT or token warrant disclosed, and it needs to be reviewable by counsel without a rewrite first. That is a different bar than calling something compliant, which is a legal determination, not a spreadsheet property.

Investors need it to model their own dilution across future rounds and unlock events, since their effective ownership share moves independently of any decision they make. Exchanges and market makers need circulating supply figures that reconcile cleanly with what gets reported publicly, because a mismatch there gets noticed fast and is hard to explain away.

Your own team needs the cap table for a quieter reason: to avoid promising the same tokens twice across advisor grants, ecosystem funds, and community incentives that different people set up at different times. A cap table with gaps or inconsistencies reads as a compliance-review and diligence red flag before a single follow-up question ever gets asked.

#The columns a complete token cap table needs

This is the section to bookmark, because it gives you something concrete to check your own spreadsheet against.

#Allocation categories and percentages

At minimum, a complete cap table needs rows for team, investors, advisors, treasury, community and ecosystem, and liquidity. Each row needs both an allocation percentage and an absolute token count, because percentages alone hide the dilution math that actually matters once unlocks start.

#Vesting schedule fields (cliff, duration, unlock cadence)

Every stakeholder category needs its own vesting fields: cliff length, vesting duration, and unlock cadence, whether that is linear, milestone-based, or cliff-then-linear. A single blanket schedule applied across every category is a simplification that will not survive contact with legal review or investor questions, since different categories almost always vest on different terms for good reason.

#Supply-state fields (circulating vs. fully diluted, per date)

A complete cap table projects circulating supply and fully diluted supply at multiple future dates, not only at token generation. That forward projection is what investors and exchanges actually model against, and a cap table that only shows the day-one picture cannot answer the question everyone asks next: what does this look like six months from now.

For the cliff, duration, and cadence mechanics behind each category, see how to design token vesting schedules.

#Where founders' spreadsheets break

Most founder-built cap tables fail in one of three predictable places.

#Reusing an equity template

Equity templates have no native concept of unlock cadence, so founders bolt vesting dates onto a format built for one-time ownership percentages. The dilution math breaks quietly, because the template has no way to represent supply changing shape over time.

#Missing the treasury and ecosystem-fund lines

Treasury and ecosystem-fund allocations often get left off entirely, because they feel like the company's own tokens rather than a line item that needs tracking. Investors and auditors expect them tracked with the same rigor as team allocation, and their absence is one of the first gaps a careful reviewer notices.

#Static snapshots instead of a live unlock timeline

A cap table built as a single static snapshot cannot answer what circulating supply looks like six months after launch, which is the exact question exchanges and investors ask first. A snapshot answers where things stand today. It cannot answer where they are headed.

#How dilution actually works across token unlocks

Dilution in a token cap table works differently than most founders expect coming from an equity background, and the difference trips people up in ways that create real disputes later.

#Percentage-based thinking versus supply-based thinking

Dilution is a function of circulating supply growth, not just new allocation percentage. Unlocking existing allocations dilutes every holder even without a new financing round, because circulating supply expands while any individual holder's absolute token count stays exactly the same. This is structural, not a judgment about whether the dilution is good or bad for any given holder.

#Modeling a new round or airdrop against an existing cap table

Walk through what happens when you add a new investor tranche or a community airdrop against an existing schedule: every existing holder's share of circulating supply shifts, even though their absolute token count never moves. This mechanic is the single most common source of post-launch investor disputes, and a maintained cap table is what prevents the dispute from happening in the first place, rather than something that resolves it after the fact.

New investor tranches trace back to specific deal terms, and private token sale structure covers what those terms need to say before they hit the cap table.

#Building versus commissioning a token cap table

Whether a founder can build this alone or needs it built as part of a professional engagement depends almost entirely on structural complexity, not on how much crypto experience the founder has.

#What a founder can build in a spreadsheet

Early-stage founders with a simple allocation structure, team, investors, community, treasury, and a single vesting standard per category can often build a workable first draft in a spreadsheet. The structure described above is not complicated to lay out when there is only one vesting rule per category and no cross-referencing required against other documents.

#When the complexity outgrows a spreadsheet

Complexity outgrows a spreadsheet once multiple investor tranches, milestone-based unlocks, or cross-referencing against a SAFT or token warrant enter the picture. At that point, manual dilution math becomes error-prone at exactly the moment legal and investors are scrutinizing it most closely. A complete tokenomics engagement delivers a professionally built cap table alongside the documentation legal and finance need, rather than handing over a standalone spreadsheet.

That is the deliverable our Token Allocation Vesting service builds alongside the allocation plan itself, not after it.

#Keeping the cap table current after launch

A cap table is only useful if it stays current, and staying current requires a trigger and an owner, not a quarterly habit.

#What triggers an update

Every unlock event, new grant, treasury disbursement, or governance-approved allocation change should trigger an update to the cap table, not wait for a batch review. Treating updates as event-driven rather than calendar-driven is what keeps the document matching reality.

#Who owns the update

Assign ownership internally, usually finance or the founder directly, so the cap table does not silently drift out of sync with what the smart contracts and multisig actually show on-chain. A stale cap table is worse than no cap table at all, because it creates false confidence during diligence exactly when accuracy matters most.

Book a strategy call before those numbers get locked into contracts.

If your allocation and vesting structure is still on a spreadsheet and you want a second set of eyes before it gets locked into contracts, that is a conversation worth having before token generation, not after. The cap table only tracks the value a business creates. It never substitutes for building that value in the first place.