Contribution Blocks Guide

The system works best when teams spend 15 minutes agreeing rather than 2 hours optimizing. Perfect allocations don’t exist - good enough allocations that everyone supports do.

“We’re not tracking hours or assigning labor points. We’re recognizing completed value creation by contributors building something meaningful together.”

Everything below serves that. The Golden Rules at the end are the whole guide in fourteen lines.

The founders’ starting position is a block, sized like every other block. There is no separate founding allocation, no starting balance, and no magic number.

Estimate the same contractor-equivalent scope proxy used for any milestone: what might an outside contractor charge to deliver what was brought to the starting line? The proxy does not claim to measure the work’s actual or complete value.

• Pre-existing IP or a working prototype
• Work completed before adopting the framework
• Customer, partner, or hiring relationships already in hand
• A brand, a design system, a body of research

Itemize it as several blocks rather than one lump - one per distinct thing you’re claiming. It’s easier to agree on, and far easier to defend later.

If You Brought an Idea and Nothing Else, It’s a Small Block#

That is the correct answer, not a harsh one. An idea that hasn’t been built, tested, or sold is worth very little of what a contractor would charge, because almost none of the work has happened yet. A framework whose whole premise is that ownership should track contribution cannot then exempt the founders from it.

Anti-Dilution Is Participation#

Founders don’t hold their position through a structural advantage. They hold it by continuing to contribute.

A founder who keeps working keeps delivering blocks and earning accepted units, at every stage the company passes through. A founder who stops dilutes because other people continue delivering work.

That’s not a flaw to be patched. The framework’s opening complaint is about people who “walk away with more than their share for showing up first” - and a protected founding balance would rebuild exactly that.

Why There’s No Starting Balance#

It’s tempting to give founders an opening balance so the ledger doesn’t start at zero. Don’t.

It smuggles in a valuation. The rate prices work in dollars; a starting balance is denominated in units. Put both in one system and the rate stops cancelling - it becomes a forced exchange rate between “the founding position” and “labor,” which is a valuation of the company at the exact moment nobody can know one.

And it solves a problem that sizing already solves. The failure it appears to prevent - first block 100%, second 75%, third 60% - only happens if each block is bigger than everything before it, which is what you get by walking up the size catalog in order. Size against real work instead and a steady team’s shares settle on their own, as the dilution table below shows.

Yes, the first block is 100% of the ledger. At that moment it is 100% of the work anyone has done. That’s arithmetic being correct, not a bug.

When This Framework Is the Wrong Tool#

If your venture’s value genuinely sits in novel, defensible IP rather than in execution, this is not your framework. Use conventional founder equity with a proper IP assignment. Most ventures aren’t that, and honest founders know which one they’re in.

Block size is not a gut call. It uses the documented cost of comparable outside delivery as a shared scope proxy.

The Unit Rate#

Pick the size whose estimated outside-delivery cost matches what the team would have paid an outside party for comparable scope.

Default rate: $5,000 per size point. Set this once at adoption and document it. Contractor rates vary enormously by geography and domain, so this is a starting point, not a law of the framework.

The size number is an input, not a holding. Nobody owns a 10. A size-10 block at Stage 0 mints 10 × 5 = 50 units, and those 50 units are what enters the ledger.

Rounding into a bounded catalog is approximate, so splitting or merging work can change the point count near a boundary. Don’t choose block boundaries to optimize units: each block must be an independently deliverable milestone, and its outside-cost estimate must be documented before work begins.

The Conservation Law#

size          = contractor-equivalent scope proxy ÷ rate   (rounded to the catalog)
base units    = size × stage multiplier

This is what anchors the denominator. Sizing means agreeing on a comparable outside-delivery cost - a proxy everyone can check and challenge before work begins. Without a shared proxy, whoever sizes blocks quietly controls the denominator.

Hours are still not counted. The proxy sizes the scope; delivery and team judgment determine acceptance and final allocation.

Cash Paid for the Work#

When the company pays a contributor in cash for part of a block’s scope, the team takes it into account when it agrees the block: a smaller scope proxy, or a smaller planned share for the paid contributor. How much a payment should count is a team judgment, not a formula. Record the reasoning with the block’s sizing, so the reduction can be checked later rather than remembered.

The payment itself is the company’s expense. It is not a cash-ledger entry.

The Rate Is a Yardstick, Not a Valuation#

The rate maps a scope proxy onto the bounded catalog. That is all it does.

It prices block size, not a ledger unit - and a ledger unit has no fixed dollar value anyway, because the multiplier changes what one unit represents at each stage. Catalog rounding and stage weighting are deliberate parts of the result, not claims about what the company or a person’s complete contribution is worth.

Use one documented rate consistently. Changing it moves the boundaries between catalog sizes, so a rate change is a governance decision rather than a harmless recalibration.

Fairly Exact defines an allocation calculation, not the legal or tax characterization of an associated interest. See the Legal and Tax Review guide.

Once the block is sized, splitting it should be quick:

1. List the key outcomes needed for this milestone (2 min)
2. Match people to outcomes based on roles (1 min)
3. Propose rough percentages (1 min)
4. Quick gut check - does this feel right? (1 min)
5. Document and confirm (done!)

Your company stage determines the multiplier - no per-block decisions needed:

Base units price the work. The multiplier prices the risk of having done that work when the outcome was still uncertain. They do different jobs and don’t double-count.

An M block (size 10) mints 50 units at Stage 0, 30 at Stage 2, and 10 at Stage 4.

The multiplier tracks the company’s stage, not individual timing. A new engineer joining during Stage 0 gets the same ×5 as the founders. Everyone contributing during a high-risk stage shares that stage’s multiplier.

Pre-Commit Your Stage Triggers#

A stage change makes all future work worth 20-25% less. If nobody agrees in advance what triggers it, you’ve built a standing argument into the framework - and two people doing identical work a week apart get different multipliers for no defensible reason.

Write down the observable event for each transition at adoption time, before anyone has a stake in the answer. Examples teams have used:

• 0 → 1: a working prototype in the hands of someone outside the team
• 1 → 2: first paying customer
• 2 → 3: a revenue or profitability threshold the team picks now
• 3 → 4: a ledger-weighted member vote

Pick triggers you can point at, not ones you’d have to argue about.

Stage-Timing Rules#

1. A block carries the multiplier in effect on its activation date, recorded when the block moves from open to active. It never changes retroactively, even if the stage shifts mid-block.
2. Stage changes take effect on the date the trigger is met, recorded by the approval the operating agreement requires.
3. Stage changes are never backdated.

These rules depend on honest scoping. A block has started only when its scope is approved and substantive work has begun; opening paperwork early does not preserve a multiplier. If a block is deliberately scoped to straddle a known upcoming trigger, split it into independently deliverable pre- and post-trigger blocks.

dilution = minted units ÷ (existing ledger + minted units)

Dilution is never a property of block size alone. The same block dilutes differently depending on how big the ledger already is. Any percentage quoted without its denominator is meaningless - that’s true here and in every cap table you’ll ever read.

The Same Block, Three Different Answers#

An M block at Stage 2 mints 10 × 3 = 30 units. What does it dilute?

Same size, same stage, twenty times the spread - because the denominator moved. This is why the framework refuses to publish a table of “what each block size dilutes.” No such table can exist.

The Ledger Grows, So Blocks Dilute Less#

A steady team contributing steadily sees each block’s impact shrink on its own:

Everyone’s share converges toward their share of catalog-sized, risk-weighted contribution, which is exactly what the framework is for.

Prefer Short Blocks#

XL (size 21) is the maximum. If a body of work exceeds XL, decompose it before work begins into independently deliverable milestones, each with its own acceptance criteria and allocation. Do not invent a custom size above the catalog.

This is a limit on the guess horizon, not a claim that the total work is worth only $105,000. Shorter blocks mean tighter delivery loops, smaller exposure if someone doesn’t deliver, and more chances to correct an allocation that turned out wrong. The framework’s error correction only runs as often as you close blocks.

So set a review cycle and close blocks on it. Default: 90 days. A block should fit inside one cycle, which sharpens the sizing question: would an outside firm have quoted this scope, for this money, on this schedule?

The cycle paces review, not sizing. Run as many concurrent blocks as the work needs, and let a quiet cycle mint a Micro or nothing. A block that isn’t delivered isn’t accepted - it carries to the next retro at its original activation multiplier.

Units Enter the Ledger Only at Acceptance#

Opening a block records planned allocations; it does not mint units. Units enter the member ledger only after the milestone is delivered, reviewed at retro, and accepted. Pause acceptance whenever qualified professionals require review of a ledger change.

The ±10-20% Band Is for Delivered Work#

At retro, allocations can move by ±10-20% to reflect how the work actually landed. Someone carried more than expected; someone else less. That’s normal, and the band handles it.

The band applies to variance in work that was delivered. It does not apply to work that wasn’t.

Non-Delivery Is Not an Adjustment#

A participant who doesn’t deliver their committed scope may be allocated zero accepted units for that block. This isn’t a penalty or clawback - unaccepted work never entered the ledger.

Without this, someone could take 60% of a large block, deliver half, get trimmed to 48% by the band, and keep it permanently. That’s the “showing up first” problem this framework exists to solve, reproduced one level down.

Leaving Mid-Block#

An in-flight block receives zero or partial accepted units at retro, depending on what was actually delivered. Accepted blocks are untouched.

An upward retro adjustment changes accepted units under the same operating-agreement rules as any acceptance. Record the final allocation and its rationale, then recalculate the hypothetical final allocation.

1. The ledger is nothing but blocks - including the founders’ starting position
2. Document the contractor-equivalent scope proxy - estimate comparable outside delivery and divide by the team-set rate
3. Use triangular sizes - 1/3/6/10/15/21; minted units = size × multiplier
4. Weigh cash paid for the work when sizing - a team judgment, recorded with the block, not a formula
5. Stage sets multiplier - not a per-block negotiation
6. Pre-commit stage triggers - decide them before they’re worth arguing about
7. Pre-allocate percentages - split blocks by role contribution
8. ±10-20% adjustment band - for delivered work only; non-delivery goes to zero
9. Prefer short blocks - break big milestones up to fit one review cycle; error correction happens at retro
10. Block size stays fixed - once chosen, don’t change it
11. Define roles upfront - Build, Sell, Manage, Maintain
12. Spend minutes, not hours - 15-minute allocations beat 2-hour debates
13. Never quote a percentage without its ledger size - dilution has a denominator, always
14. Anti-dilution is participation - keep contributing, keep minting

Remember: the triangular catalog is memorable, but the ledger is what’s real. Trust the process over multiple blocks.