Mechanics

How a caput contract works, end to end, in plain language.

What a contract is

A caput contract is a private bilateral agreement between two parties — a seller and a buyer — using the XRPL as the settlement venue.

The seller holds an asset (XRP or RLUSD) and is willing to lock it for a fixed term in exchange for premium income. The buyer wants directional exposure to the XRP/RLUSD pair and is willing to pay premium and lock margin for the chance to profit from rate movement during the term.

The bot creates a 2-of-2 multisig wallet (M) that both parties co-control. The seller's asset is deposited and immediately swapped through the on-ledger AMM into its opposite. That opposite asset sits locked in escrow with destination M for the term. At settlement, it swaps back. The seller is made whole. The buyer takes whatever surplus or shortfall came out of the round-trip swap, against their margin.

There is no oracle. There is no synthetic settlement formula. The AMM is both the venue and the price discovery. What you get is what the AMM gives.

Calls and puts

Call: the buyer profits if XRP rises against RLUSD. Seller deposits RLUSD, it swaps to XRP at deploy, and if XRP is worth more RLUSD at swap-back the surplus goes to the buyer.

Put: the buyer profits if XRP falls against RLUSD. Seller deposits XRP, it swaps to RLUSD at deploy, and if RLUSD buys more XRP at swap-back the surplus goes to the buyer.

What gets locked

The locked asset is always the opposite of what the seller deposited.

Premium and margin

Premium. Paid by the buyer into Escrow P at deploy with destination M. It belongs to the seller from the moment the contract opens. Premium is consolidated into M at settlement and paid to the seller as part of the live-signed distribution.

If the bot dies permanently and escrows hit CancelAfter (term + 30 days), premium reverts to the buyer. This is a documented edge case — sellers running reliable bots never see this.

Margin. Locked by the buyer in Escrow B at deploy with destination M. The buyer's risk capital. At settlement, if the locked asset's swap-back proceeds fall short of the seller's deposit amount, the shortfall is covered from the buyer's margin. Whatever margin remains returns to the buyer.

The buyer's maximum loss is premium plus their full margin (at hard liquidation, 100% consumed).

Escrow structure

Three escrows per contract, all with destination M:

Each escrow has:

• FinishAfter = deploy time + 5 minutes (grace for deploy completion)
• CancelAfter = deploy time + term + 30 days (failsafe refund if bot dies)
• Condition = PREIMAGE-SHA-256 with fulfillment held by the bot

Liquidation — two tiers

Soft liquidation at 90% — both wallets required

When the locked asset's value (at the current AMM rate) has fallen enough that 90% of the buyer's margin would be consumed to make the seller whole, the bot announces "settlement pending." Both parties co-sign live. Buyer keeps a 10% margin buffer.

Neither the seller's wallet nor the bot can fire soft liquidation unilaterally. Both wallets must sign. If the buyer believes the rate doesn't warrant liquidation, they can refuse to sign and wait.

Hard liquidation at 100% — automatic

When margin is fully consumed, the bot fires a pre-signed swap-back transaction automatically. No buyer cooperation needed.

The pre-signed swap-back delivers a fixed amount — the seller's deposit minus the buyer's full margin — to the seller. This amount is baked into the signed transaction blob at deploy.

Why early firing is irrational for the seller: at any rate better than the 100% threshold, the AMM needs less of the locked asset to produce the fixed delivery amount. The surplus stays in M, not in the seller's pocket. The seller gets the same reduced amount regardless of when the pre-signed swap-back fires. Waiting for honest settlement at expiry always yields more for the seller.

A second pre-signed variant (Variant B) covers tail crashes where the primary transaction can't execute at all. Variant B uses partial payment with a lower delivery floor.

Settlement sequence

Settlement is a sequence of on-chain steps, not an atomic release. In order:

1. EscrowFinish on S, B, P — the bot uses the fulfillment to consolidate locked asset, margin, and premium into M.
2. Swap-back through the AMM — the locked asset swaps back, delivering the seller's deposit-equivalent to the seller. For voluntary close, expiry, and soft liquidation this is signed live by both parties. For hard liquidation this is the pre-signed transaction.
3. Distribution from M — live-signed by both parties: any surplus to the buyer, margin remainder to the buyer, premium to the seller.
4. Cleanup — consume unused Tickets, remove trust line, clear signer list, delete M.

Resolution paths

A contract ends in one of four ways:

Expiry

The term ends. The bot fires EscrowFinish and announces "settlement pending." Both parties co-sign the swap-back and distribution live.

Voluntary close

The buyer requests close at any time during the term. The bot fires EscrowFinish. Both parties co-sign the swap-back and distribution live.

Soft liquidation

The bot detects that 90% of the buyer's margin is consumed. The bot fires EscrowFinish and announces "soft liquidation — settlement pending." Both parties co-sign live. Buyer keeps 10% margin buffer.

Hard liquidation

The bot detects full (100%) margin consumption. The bot fires EscrowFinish, then fires the pre-signed swap-back automatically. When the buyer is next online, both parties co-sign the distribution of remaining funds in M.

All four count as one completed cycle for usage tracking.

Worked example: a put

A seller holds 1 XRP and is bullish on XRP. They want premium income on top of their hold. They write a put.

Configuration:

• Side: put
• Notional: 1 XRP
• Term: 15 days
• Premium: 3%
• Minimum buyer margin accepted: 10%
• Deploy AMM rate (R₀): 0.5421 RLUSD/XRP

Deploy:

1. Bot creates a 2-of-2 multisig wallet M between seller and buyer (master key disabled).
2. Seller's 1 XRP swaps via AMM into 0.5421 RLUSD. 0.5421 RLUSD locked in Escrow S.
3. Buyer deposits 0.0163 RLUSD premium (3% of 0.5421) into Escrow P.
4. Buyer deposits 0.0542 RLUSD margin (10% of 0.5421) into Escrow B.
5. Both parties pre-sign two hard liquidation variants.

Hold: for 15 days the position sits. The bot polls the AMM every ~12 seconds. It tracks margin consumption as a percentage.

Settle — XRP fell, buyer profits. At expiry, R = 0.4500. The 0.5421 RLUSD swaps back to 1.2047 XRP.

• Seller receives 1 XRP back. Made whole.
• Remaining 0.2047 XRP goes to the buyer as profit.
• Buyer's 0.0542 RLUSD margin returned untouched.
• Premium (0.0163 RLUSD) releases to the seller.

Settle — XRP rose modestly, margin partially consumed. R = 0.5800. The swap-back gives 0.9347 XRP. Shortfall of 0.0653 XRP.

• Shortfall covered from buyer's margin. Seller receives 1 XRP total.
• Buyer's remaining margin returned (minus shortfall).
• Premium releases to the seller.

Soft liquidation at 90%. During the term, the rate moves enough that 90% of margin is consumed. Bot announces settlement. Both sign live. Buyer keeps 0.0054 RLUSD (10% buffer). Seller made whole.

Hard liquidation at 100%. Rate moves further. Pre-signed Variant A fires: delivers 0.9 XRP to seller. Buyer's margin and premium distribute to seller when buyer comes online. Buyer receives nothing back.

What the seller risks

The seller has no directional risk on their asset. They get their deposit back, in the same asset, in the same amount, regardless of which way the rate moved.

What the seller does risk:

Liquidity cost during the term. Their asset is locked. They cannot deploy it elsewhere. Premium compensates, but the opportunity cost is real.

Operational risk on the bot. The bot must remain online and polling. If the bot goes offline during a rapid rate move, the position can degrade past where the buyer's margin covers it. The pre-signed hard liquidation provides a backstop at 100%, but there is a real gap between soft (90%) and hard (100%) where the bot's uptime matters.

Venue risk. XRPL outage, AMM exploit, RLUSD issuer freeze, governance changes affecting AMM behavior.

What the buyer risks

Premium. Paid at deploy. Released to seller at settlement. Gone regardless of direction. Returns to buyer only if the bot dies permanently (CancelAfter failsafe, term + 30 days).

Margin. Drawn down at settlement to cover shortfall. At soft liquidation, buyer keeps 10% buffer. At hard liquidation, margin is fully consumed. Maximum buyer loss: premium + full margin.

Bot trust. The seller controls the bot. The bot coordinates liquidation timing. The pre-signed hard liquidation is parameterized so early firing is economically irrational for the seller (they receive less than their deposit). But for soft liquidation and general coordination, the buyer trusts the seller's bot to operate honestly. This product is designed for bilateral relationships where trust exists between the parties.

The buyer's upside comes from the AMM round-trip. If the rate moved their way during the term, the swap-back gives more than the seller's deposit, and the surplus is theirs. There is no cap on the buyer's upside.

What the bot does

The bot is the seller's tool. The seller runs it. The buyer never installs anything; they interact via wallet signing on a public URL the seller's bot exposes.

The bot:

• Generates and serves invitations.
• Constructs the multisig wallet M at deploy (master key disabled after setup).
• Constructs and submits the AMM swap at deploy.
• Stores the pre-signed hard liquidation variants and escrow fulfillments in encrypted flat-file storage.
• Polls the AMM every ~12 seconds for each open position.
• Computes mark-to-market against margin.
• Announces soft liquidation at 90% and coordinates live co-signing.
• Fires hard liquidation automatically at 100% via the pre-signed swap-back.
• Submits EscrowFinish at settlement.
• Handles voluntary close requests from buyers.
• Tracks usage: a use is consumed only when a contract completes.

The bot does not:

• Pick the price source. There is no oracle. The AMM is the venue.
• Hold private keys. Every signing event uses the user's wallet.
• Have unilateral signing authority over M. It's a 2-of-2 multisig.
• Match buyers and sellers. Invitations are shared peer-to-peer.

Locked enums

Sellers cannot set values outside these enums. Buyers must accept terms in these enums or decline.