Partial reverts
One leg reverts on gas or on a destination contract check while the rest of the payout confirms normally. The aggregate status stays green because the first transfer landed.
Multi-leg settlement verification
Proof that every leg cleared.
Settle Protocol follows each transfer in a multi-part payout along its own path to finality, and reports the payout as complete only once all of them have confirmed.
A single payout rarely moves once. It splits into a creator share, a referral share, a treasury share and a liquidity share, and each of those is an independent transfer with its own nonce, its own gas estimate and its own way to fail. Settle Protocol treats them that way from the first block to the last.
- Per leg receipts Each transfer is tracked as its own object, start to finality.
- Confirmation policy Depth is set per asset and per counterparty, not globally.
- Read only by design No custody, no signing keys, no authority to move funds.
- Native chain access Settlement data read directly from Robinhood Chain.
01 . The settlement gap
The distance between fired and cleared
Most payout systems report submission. A transaction is built, signed, broadcast, and the interface turns green. That green state answers one narrow question: did the first call leave the wallet. It says nothing about the transfers queued behind it, and it is the definition of success that most reconciliation tooling quietly inherits.
A multi-part payout is a set of independent transfers that happen to share a trigger. Each one carries its own nonce, its own gas estimate, its own destination contract and its own failure surface. A creator share can confirm in the next block while a treasury share reverts on an underfunded gas estimate two seconds later. Nothing in the first confirmation predicts the second. Nothing in a submission log records the difference.
The cost of that gap is rarely a loud failure. It is a slow one. A counterparty ends up short by one leg, the discrepancy surfaces weeks later during an accounting review, and an engineer reconstructs the run by hand from block explorers, because the only durable record anyone kept was a timestamp that said sent.
Settle Protocol closes that gap by refusing to collapse a payout into a single boolean. A payout has as many outcomes as it has legs, and the protocol keeps all of them visible until every one resolves.
Finality out of order
Legs broadcast together do not confirm together. A referral share can sit in the mempool for minutes after the treasury share is already final, and a naive watcher reads that silence as completion.
Reorg exposure
A leg marked settled at one confirmation can be unwound by a short reorg. Without a depth policy, the record and the chain disagree and only the chain is authoritative.
Silent retries
An automated retry fires against a leg that was already inflight. Either the payout pays twice or the retry is dropped with no record, and neither outcome appears in a submission log.
02 . Anatomy
One trigger, four independent paths
The diagram below is the shape Settle Protocol models. A payout intent enters once and fans out into separate transfers. Each lane runs its own broadcast, inclusion and finality checkpoints, and each lane can stop at any of them without affecting the others.
Payout intent
One trigger, four obligations
- Creator share Broadcast . Included . Final
- Referral share Broadcast . Included . Final
- Treasury share Broadcast . Included . Final
- Liquidity share Broadcast . Included . Final
Twelve checkpoints for one payout. A status field that holds a single value cannot describe twelve outcomes, which is why the protocol stores a receipt per leg and derives the payout status from them rather than the other way around.
03 . Live checklist
Step a settlement through, leg by leg
This is a working model of the settlement engine running against one payout. Pick a scenario, run it, and watch each leg accumulate confirmations on its own before the payout verdict is written. The second scenario is the case the whole product exists for.
Scenario
Awaiting settlement run
- Creator share 0x4A1C . . . 9E02 32.0% 0 / 12 Pending
- Referral share 0xB73F . . . 1D88 8.0% 0 / 12 Pending
- Treasury share 0x20E9 . . . 7C45 35.0% 0 / 12 Pending
- Liquidity share 0x8F56 . . . 3A11 25.0% 0 / 12 Pending
Payout verdict
Not yet determined. No legs have been observed.
Engine log
- Engine idle. Select a scenario and run the settlement.
04 . How it works
From payout intent to a closed record
Four stages, each with a defined input and a defined exit condition. Nothing advances on an assumption and nothing is marked resolved on a timer.
Ingest the intent
A payout intent arrives over the API or is picked up from an onchain event. It declares what is owed, to whom, and under what split. At this point nothing has moved and nothing is claimed.
Exit condition: intent accepted and assigned an idempotency key.
Decompose into legs
The intent is expanded into one leg per obligation. Each leg gets a receipt object with its own destination, amount, expected asset and confirmation policy, and is queued for observation independently of its siblings.
Exit condition: every obligation has exactly one receipt.
Watch each leg to finality
Every receipt is followed from broadcast through inclusion to the configured confirmation depth. A leg that stalls, reverts or is unwound by a reorg stays open and visibly unresolved rather than being rounded toward completion.
Exit condition: the leg is final, failed or explicitly held.
Resolve the payout
The payout status is derived from the set of receipts, never set directly. It flips to settled only when every leg is final, and any other combination produces a named partial state with the specific legs attached to it.
Exit condition: all receipts terminal, record sealed and emitted.
05 . Infrastructure
Built to be boring under load
A verification layer is only worth running if it is more reliable than the thing it is verifying. Settle Protocol holds no funds, signs nothing and cannot move a balance, which keeps the blast radius of any failure to a stale reading rather than a lost payout.
Observation is idempotent end to end. Replaying a block range produces the same receipts it produced the first time, so a restarted worker, a backfill and a live stream all converge on one record instead of three competing ones. When the chain disagrees with a stored receipt after a reorg, the receipt is reopened and re-observed rather than patched.
Every state transition is appended to a run record with the block height that justified it. A settled leg can always be traced back to the exact confirmation that closed it, which is the difference between a dashboard and an audit trail.
- Confirmation depth
- Set per asset and per counterparty. A high value obligation can require more depth than a routine one without slowing the rest of the payout.
- Reorg handling
- A receipt that loses its inclusion block is reopened automatically and re-observed from the new canonical head.
- Retry semantics
- Idempotency keys are carried from intent to receipt, so a retried submission resolves to the existing leg instead of creating a second one.
- Backfill and replay
- Any historical range can be replayed against the current policy to rebuild receipts without touching live observation.
- Run record
- Append only. Each transition stores the block height and the policy version that justified it.
- Alerting
- A held or failed leg raises on its own, without waiting for the payout as a whole to reach a terminal state.
06 . Integration
Three events, one contract with your system
Settle Protocol emits per leg, not per payout. Your system learns that a treasury share is held at the moment it is held, not at the end of a batch window.
- settlement.leg.final A single leg reached the configured confirmation depth and is now terminal.
- settlement.leg.held A leg stopped advancing before finality. The payout stays open and the leg is named.
- settlement.payout.resolved Every receipt is terminal. The payload carries the outcome of each leg, not a single flag.
POST /webhooks/settle
{
"event": "settlement.payout.resolved",
"payout_id": "pyt_9E21c4a7",
"status": "partially_settled",
"legs_final": 3,
"legs_total": 4,
"receipts": [
{ "leg": "creator", "state": "final", "confirmations": 12 },
{ "leg": "referral", "state": "final", "confirmations": 12 },
{ "leg": "treasury", "state": "held", "confirmations": 4 },
{ "leg": "liquidity", "state": "final", "confirmations": 12 }
],
"sealed_at_block": 21904776
}Stop reading submission logs as if they were receipts.
Settle Protocol is the settlement record for payouts that move in more than one piece. Every leg carries its own proof, and the payout closes only when all of them do.