How it works

Two mechanisms, drawn as they actually run.

The closing pipeline and term negotiation are the two places a raise is actually decided. Both are shown below exactly as they run in the product, not simplified for the page.

The closing pipeline

Six gates, and most of them need both sides to act — not one side declaring the other has agreed. The diagram below draws that distinction directly: where the two rails converge, both parties are required. Where they don’t, one side alone is.

Gate 3 is the one exception, deliberately: the founder sets the fee, and only the party paying it confirms. That’s a single rail acting, not a convergence, and the diagram shows it that way rather than pretending every gate is symmetric.

The closing pipeline · Two-party swimlane

A dashed line between rails marks a gate that needs both parties. Gate 1 is a shared decision made once, before work on the remaining gates begins. Gate 3 has no counterparty gate — the founder sets the fee, the designated payer alone confirms.

Term negotiation

A term doesn’t lock because one party says it’s agreed. Accepting a term sets only your own flag — the term finalizes only once both flags are true against the exact same value.

The rule a table can’t show cleanly: proposing a new value resets both flags to false, even if one side had already accepted the old one. There is no state where a stale acceptance carries forward onto a changed number.

Term negotiation · State machine

Every arrow is a real transition from the negotiation code, not an illustration of intent — including the reset path, which fires on any new proposed value regardless of which state the term was in when it changed.

See it on a real screen

The homepage shows the closing pipeline as a fee schedule and the term sheet negotiation view as a live screenshot.