Eighty-one counterparties, one week.

The engagement

A secondary sale with 75 early investors and employees on the sell side, and six buyers acquiring through ten separate entities. Eighty-plus transactions to execute at the same time. Multiple details and documents to collect from every counterparty. Allocations that would keep changing until the last moment. And 150+ agreements and compliance filings to generate — inside seven days.

The arithmetic of that is the point. Seventy-five sellers times "email me your bank details and a tax ID" is not a week of work; it is a week of work if nothing goes wrong, which at eighty-one counterparties it will.

Why multi-party secondaries break

Because a single change propagates. A seller reduces their quantity by 800 units on day four. That changes one allocation, which changes a buying entity's total, which changes the advisor fee on that entity, which changes two agreements — one of which has already gone out for signature.

Run that on a spreadsheet with an email thread beside it and the failure mode isn't confusion. It's confident wrongness: a document that was correct when generated, sent after it stopped being correct.

Step one — one venue, with the rules set in advance

The sale is created with a submission window, a price basis and a cap. Percent allowed limits how much of their holding any seller may offer — the single most useful guardrail in an employee liquidity event. The price basis is either a fixed price, where everything trades at one number and there is nothing to negotiate, or a price range, where buyers bid inside a band and the system computes where supply and demand meet.

Large transactions can run as a tranche sale — allocation and verification repeated across rounds rather than settled once.

Access is granted per participant, marked Buyer or Seller. An investor can hold both roles in the same sale, selling part of a position while bidding for more. Only participants with the right access can see or submit anything.

Step two — collection, from both sides, in a structured shape

A seller offer carries the quantity, the price, the seller's tax ID, and the bank account and routing code that settlement will use. Optionally a pre-agreed buyer, and a flag for whether the offer participates in automatic matching. Sellers submit through their own portal, or the manager submits on their behalf where the sale is configured to allow it.

A buyer interest carries the buying entity, the quantity, the bid — inside the band for a price-range sale — the tax ID, and whether escrow has been deposited.

Two mechanics keep this honest at scale:

• Offers are approved, and changing the quantity sends an offer back for re-approval. Only approved offers count toward total supply. A seller cannot quietly resize their position after the manager has built an allocation on it.
• Interests are shortlisted. Only shortlisted interests count toward demand and take part in clearing and allocation. Everything else stays visible but inert.

Step three — the clearing price, computed not negotiated

For a price-range sale, the clearing price is derived from the shortlisted book:

• If demand is at or below supply, everyone fills and the clearing price is the lowest accepted bid.
• If demand exceeds supply, the highest bidders are filled first and the clearing price is the marginal bid — the one at which supply runs out.

Bids below that price stay shortlisted but unallocated, so if more supply appears they are still in the book. The result becomes the sale's final price, and every allocation prices from it.

Book	Quantity	Bid	Outcome
Supply (approved offers)	600	—	—
Buyer X	400	120	Filled — 400
Buyer Y	200	115	Filled — 200, supply exhausted
Buyer Z	300	110	Unfilled, stays shortlisted

Step four — allocations, manual where judgement matters

An allocation links one offer to one interest with a quantity and a price. The manager can create them by hand, or let the automatic matching engine pair offers marked auto-match by price compatibility. Custom matching rules can be configured on the sale to enforce specific pairings — by geography, by investor category, by whatever the transaction requires.

Allocations remain changeable until either side is verified. That is the mechanism that made a moving allocation survivable here: the state is explicit, and the point at which it stops moving is a deliberate act rather than the passage of time.

Step five — verification, then the agreements

Verifying an offer confirms the seller's details — full name, address, tax ID, bank account — and identity and bank checks run in the background. Verifying an interest does the same for the buyer. Confirming an allocation marks both sides verified together.

Then the documents. The SPA is generated automatically when an offer is verified, provided the sale carries an Offer Template. It pulls the seller's details from the offer, the buyer's from the matched interest, and the signatory emails from each side, and files itself in the offer's folder. A separate buyer-side agreement comes from a Buyer Template, and an Allocation Template covers the allocation confirmation.

From there they go for e-signature: signers get a link, sign from a phone, and the executed copy files itself back, locked and approved. The provider is a setting on the firm rather than a fixture of the product — DocuSign or a regional equivalent, same envelope, same filing behaviour either way. Where a jurisdiction attaches something statutory to execution, that rides on the template too: a stamping configuration carries the stamp values, the signature page, and the note and its placement, so the stamping request goes out with the signature request and the agreement comes back stamped. Where a jurisdiction attaches nothing, that configuration is simply absent. A whole folder can be sent at once, queued with a small delay between documents so the signing provider isn't overwhelmed.

That is how 150+ documents happen in a week. Not by generating faster — by generating on the event that makes the document correct, from the record that makes it correct.

⚙️ Under the hood: the three things that scale to eighty-one parties

Advisor fees are computed per offer and totalled per buying entity. Per share (allocated quantity × rate), percentage (allocated amount × rate), or flat. When an allocation moves, the fee moves with it, because it is derived rather than recorded.

Escrow is tracked, not moved. Buyers mark escrow deposited on their interest; the platform records it for operations and makes no claim to have touched the money. Being explicit about what the software does not do is what lets an ops team trust the part it does.

Notifications go to groups, not to a distribution list someone maintains. Ad-hoc messages can be sent to All Sellers, All Buyers, Approved Sellers, Verified Sellers or Shortlisted Buyers — categories defined by current state, so the message reaches whoever is in that state today. Status changes notify the employees configured on the sale, the investor's relationship managers, and their approved contacts.

📊 The impact

Eighty-plus transactions executed simultaneously, 150+ agreements and compliance documents produced, and the whole thing completed within the week — with the company keeping control of how its cap table was realigned rather than discovering the shape afterwards.

The structural win is that every party saw one venue and one state. Sellers submitted against a cap they could see. Buyers bid into a band. The clearing price was computed from the book rather than argued into existence. And each document was created by the event that made it true, so nothing had to be checked for staleness before it was sent.

What to take from this

Where this goes next

The same document generation and e-signature mechanics run the fund side — see onboarding 200+ LPs. To talk through a transaction of your own, book a walkthrough.

Client name withheld. The workflow, platform mechanics and behaviour described are exactly as CapHive runs them; the worked book above is illustrative, and supporting detail reflects how engagements of this shape run.