caput.dev configure your bot →

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:

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.

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:

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:

Venue risk

XRPL itself, the AMM, RLUSD as an issued token — these are the venue. They have failure modes you do not control:

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:

If any of that is not true for you, do not deploy.