Risk
What you're accepting when you use caput. Read this before you deploy.
This is not a regulated market
caput is software you bought. It generates and manages contracts on the XRPL. We do not operate a market, exchange, clearinghouse, or platform.
That means:
- No suitability rules. Nobody verifies whether you can afford the position you're entering.
- No disclosure regime. No prospectus, no risk acknowledgment requirement, no cooling-off period.
- No recourse. No arbitration body, no insurance fund, no investor protection regime.
- No counterparty enforcement. If the on-chain transactions did what they did, that's the record. There is no entity that adjudicates disputes.
- No reporting. No tax forms, no trade reporting on our part. You and your counterparty are responsible for whatever your jurisdictions require.
This is a private bilateral contract between two parties, executed on a public ledger. Treat it that way.
Our role ends at download
You bought a binary. After it's on your machine, our role ends.
- We do not host the bot. You do.
- We do not custody funds. The XRPL does, in escrows and multisig wallets you co-control with your counterparty.
- We do not co-sign transactions. Every signing event uses your wallet.
- We do not have signing authority anywhere. We could not freeze, recover, or alter your contracts even if we wanted to.
- We do not provide support, SLA, account management, or any ongoing service.
If something goes wrong between you and your counterparty, that's between you, your counterparty, and the XRPL. We are not party to it.
Seller risks
If you sell contracts (write puts or calls), you have no directional risk on your locked asset — your deposit returns to you whole at settlement. But you do have these risks:
Liquidity cost during the term
Your asset is locked in escrow for the contract's full term (5, 10, 15, or 30 days). You cannot deploy it elsewhere during that time. If the market moves dramatically, you cannot react by selling, hedging, or rotating.
The premium you're paid compensates for this opportunity cost. Whether that compensation is adequate depends on what else you would have done with the asset.
Operational risk on the bot
This is the seller's most consequential risk and the one most often underestimated.
Your protection between the soft liquidation threshold (90% margin consumed) and hard liquidation (100%) depends on the bot being online and polling the AMM. The bot must be:
- Online and reachable
- Polling the AMM every ~12 seconds
- Able to fire EscrowFinish and submit the pre-signed hard liquidation swap-back
- Able to announce soft liquidation and coordinate live co-signing
If any of those fails at the wrong moment — host outage, network partition, software bug — the position can degrade past the 100% threshold before the hard liquidation fires. The pre-signed Variant B (tail backstop) provides a last-resort partial recovery, but the seller may receive less than their full deposit in extreme tail events.
Mitigations are operational, not architectural:
- Choose a host with strong uptime guarantees.
- Set up uptime monitoring on your bot's health endpoint.
- Use a process supervisor that auto-restarts the bot on crash.
- Back up the
.caput/directory regularly. Pre-signed blobs and fulfillments live there. - Test your deploy thoroughly before writing real contracts.
Venue risk
XRPL itself, the AMM, RLUSD as an issued token — these are the venue. They have failure modes you do not control:
- XRPL network outage. Rare but possible. If the chain is down, settlement is delayed.
- AMM liquidity collapse. If the XRP/RLUSD AMM pool is drained, swap-back may execute at worse rates than expected.
- RLUSD freeze. RLUSD is centrally issued by Ripple. They can freeze RLUSD globally or for specific accounts.
- Multi-transaction settlement. Settlement requires multiple sequential transactions. In edge cases, partial failure may require fresh co-signing from both parties.
These tail risks are inherent to operating on this chain. They are not specific to caput.
Buyer risks
If you accept invitations (buy puts or calls), you take directional risk on the rate movement during the term.
Premium
Paid at deploy, released to the seller at settlement. Gone regardless of which way the rate moves. The buyer's cost of entry.
The only case where premium returns to the buyer is if the bot dies permanently and escrows hit CancelAfter (term + 30 days).
Margin
Locked at deploy. Drawn down at settlement to cover any shortfall when the locked asset swaps back below the seller's deposit. At soft liquidation (90%), buyer keeps 10% buffer. At hard liquidation (100%), margin is fully consumed.
Your maximum loss is premium + your full margin.
If you cannot afford to lose that amount, do not enter the contract. The contract has no mechanism to forgive a buyer's loss.
Bot trust
The seller controls the bot. The bot controls when EscrowFinish fires and when the pre-signed hard liquidation is submitted.
For hard liquidation (100%): the pre-signed swap-back delivers a fixed amount (seller's deposit minus buyer's margin) to the seller. At any rate better than the 100% threshold, the seller receives less than they would by waiting. Early firing is economically irrational for the seller. This is game-theoretic protection — the chain doesn't prevent early firing, but the math makes it self-defeating.
For soft liquidation (90%): both wallets must co-sign. The buyer has veto power. If you believe the rate doesn't warrant liquidation, you can refuse to sign.
For general coordination: you are trusting the seller's bot to operate honestly — to fire EscrowFinish at the right time, to announce settlement accurately, to submit transactions correctly. This product is designed for bilateral relationships where trust exists between the parties. If you don't trust the seller, don't enter the contract.
No clawback if the seller's bot fails
If the seller's bot fails to fire liquidation when it should, the position can degrade past your margin's coverage. You will not be charged beyond your margin — but the seller may not be made whole. There is no contract mechanism to compensate either party for bot failures. The on-chain transactions that happen are the entire record.
Operational risks for both parties
Wallet compromise
The bot never holds your private keys. But you sign with your wallet. If your wallet is compromised — phishing, malware, lost device — your XRPL account is compromised, and any contracts you've signed into are at risk.
Phishing of buyers
Buyers receive invitation links from sellers. A phisher could send a fake link claiming to be a caput invitation. Buyers should verify the invitation domain matches the seller's known bot URL, inspect the invitation JSON before signing, and confirm the multisig wallet on an XRPL explorer before signing the deploy bundle.
Front-running and rate manipulation
The AMM is public. Transactions in the mempool are visible. Sophisticated actors could front-run deploy or settlement transactions to manipulate the rate they execute at. For thin AMM pools, manipulation is economically feasible. Sellers should consider liquidity depth when configuring contracts.
Multi-transaction settlement
Settlement requires multiple sequential transactions. Each transaction uses a Ticket on M. If a transaction fails (e.g., AMM slippage causes the swap-back to fail), the Ticket is consumed and the bot must retry with a spare Ticket. If all retries are exhausted, recovery requires fresh co-signing from both parties. Both parties have economic incentive to cooperate.
What we are not
× We are not a service. We are software you bought. × We are not custodial. The bot never holds your keys. × We are not a market. We do not match counterparties. × We are not regulated. There is no body overseeing this. × We are not advice. Read this; make your own call. × We are not your counterparty. Your counterparty is whoever signs the other side. × We are not no-risk. Real risks, named above.
Acknowledgment
By using caput, you acknowledge:
- You understand the contract mechanics (see MECHANICS.md).
- You understand the risks above, including the two-tier liquidation model and bot trust requirements.
- You are responsible for your own host, your own keys, your own wallet, and your own decisions.
- You are not relying on caput for support, recourse, or recovery.
- You have read or are responsible for reading the source before deploying.
If any of that is not true for you, do not deploy.