Security from Monero work
Chainjump’s security rests on Monero-equivalent RandomX proof of work. An honest solver sends XMR and reuses work already performed by Monero miners. It does no new mining, although witness construction and proof generation consume computation.
Honest and dishonest work
Section titled “Honest and dishonest work”A dishonest solver fabricating payment and block commitments must produce a qualifying RandomX result for that data. Changing the payment commitment changes the hashing input.
Under the RandomX hardness assumption, difficulty D requires approximately D trials on average. At D = m × D_network, this is the expected work needed to mine m real Monero blocks at that network difficulty, providing the protocol’s computational security barrier. Mining remains probabilistic. Choosing the RandomX key does not reduce the required target or expected work under this assumption.
Verified statement
Section titled “Verified statement”The guest verifies the recipient, swap-bound outgoing proof, selected output and amount, payment/miner transaction inclusion, minimum payment height, up to 64 block links, and full RandomX computation. The contract binds these checks to the live award and immutable program key. See the payment predicate for exact formats.
The guest does not verify input ring signatures, range proofs, balance, or key-image state. The supplied key is not authenticated against an epoch seed; height is bound to the miner transaction rather than an independent clock. Users should check receipt and maturity in their Monero wallets.
Replay protection
Section titled “Replay protection”Each deployment gives intents unique swap IDs. The outgoing proof binds to that ID; settlement consumes both the transaction ID and the hash of the exact recipient bytes plus selected output key.
A transaction cannot settle another swap in the same deployment, even through a different output. Markers are written only after successful settlement; expiry and reverted settlement consume neither. They do not span deployments or prevent shared work. Exact constructions appear in the contract reference.
Economic and operational assumptions
Section titled “Economic and operational assumptions”One work result can cover several distinct payments. Difficulty targets are not summed, and aggregate value is not capped against work. Successful settlement returns the winner’s bond; the bond penalizes missed settlement rather than an accepted attack. See economics.
Security also depends on SP1 soundness, the verifier and cryptographic implementations. Solver operation requires trusted reads, private transaction delivery, available proving services, and durable state. Its supported reorganization model covers a tip replacement. These services must finish before the immutable deadline; a successful settlement has no reversal or administrator recovery path.