Referred Value, Recorded Once
The referral ledger is the quiet backbone of the human economy: who introduced whom, when, and what that introduction was worth. Every business that runs on referrals — recruiters, real estate, B2B sales, studios — depends on a ledger that nobody formally maintains. The share-pool discipline fixes this: the referral is a contribution to a pool, and the ledger is the pool’s source of truth.
This article defines the referral ledger as pool infrastructure: what gets recorded, the attribution rules, the payout schedule, and why the ledger must be shared between both sides of the referral.
What Gets Recorded
A referral ledger records four facts per event: the referrer, the referred, the introduction moment, and the outcome. The first two are identity; the third is timestamp; the fourth is the part humans skip. The outcome — the referred party became a client, signed a contract, closed a deal — is what converts the referral from social gesture to pool contribution.
The outcome must be recorded by the party who received the referral, not the referrer, because the receiver is the one who knows what actually happened. This creates a trust asymmetry the ledger must manage: the receiver could quietly under-report. The fix is a simple contract — the referral credit is defined in advance (“a 10% first-year commission on any client introduced”), and the receiver’s reporting is auditable against their own books.
Attribution Rules
Attribution is the ledger’s hard problem. Two referrals introduce the same client within a week — who gets the credit? The rules must be written before the question arises: first-touch wins, last-touch wins, or the split model (both get a share). For referrals, first-touch is usually right — the person who opened the door deserves the credit — with a carve-out for a second referrer who materially advanced the deal.
The rules must also cover the boundary cases: self-referrals, referrals of entities that later become clients under a different name, referrals that expire. Every boundary case the ledger doesn’t pre-define becomes a dispute, and every dispute is a tax on the pool’s trust.
The Shared Ledger
A referral ledger that lives on one side is a weapon, not a system. The referrer’s copy says “I introduced them”; the receiver’s copy says “I don’t recall.” The ledger must be shared — both sides see the same events, the same attribution, the same pending payouts. This is the auditability principle from the LucidHive audit layer applied to human commerce: both parties can read the records, and neither can edit the other’s view.
The shared ledger does not need blockchain. It needs a neutral host, write-once events, and read access for both parties. A simple shared spreadsheet with append-only discipline beats a secret database every time, because the trust property comes from visibility, not from cryptography.
The Payout Schedule
The ledger records; the payout schedule distributes. Referral payouts have a timing problem: the referrer wants money at introduction, the receiver wants to pay after the client pays them. The pool answer is a schedule tied to actual received revenue: the referral commission is a percentage of payments received, paid when received, with a clear window (first year, lifetime) and a clear termination (the referred client stops paying).
This schedule aligns the pool: the referrer’s payout mirrors the receiver’s actual cash flow, so both are motivated to keep the referred client happy and paying. A referrer paid on received revenue becomes a retention ally, which is the best possible outcome for the pool.
The Referral Ledger as a Product
Referral ledgers are the most underserved pool infrastructure in the human economy. Every business wants referrals; almost none run them as a system. The share-pool product line has a natural wedge here: a referral ledger that both sides share, with attribution rules, payout schedules, and an audit trail. It is simple enough for a two-person studio and general enough for a national sales network.
And like every pool tool built for humans, it transfers to the agent economy: when agents refer work to other agents — a specialist agent recommending a payment-rail agent to a client — the referral ledger records the introduction and splits the finder’s fee the same way. The human version is the rehearsal; the agent version is the scale.
Grounded in wiki concepts referral-ledger, share-pool, attribution, audit-layer, referral-loop, and the Sovereign-stack business series. Design notes on a running system.
