Oryn relies on contracts to enforce settlement, and services to coordinate the correct parameters.
Core guarantees
| Guarantee | Enforced by |
|---|
| Only the secret holder can claim before expiry | Vault checks sha256(preimage) == commitmentHash. |
| Funds can be cancelled after expiry | Vault checks block.number >= depositedAt + expiryBlocks. |
| A vault settles once | s_settled blocks claim-after-cancel and cancel-after-claim. |
| Vault addresses are parameter-bound | Factory salt includes chain ID and escrow parameters. |
| Hop destinations cannot be redirected | claimHop verifies recipient-signed hop authorization. |
What the contracts do not guarantee
Contracts cannot guarantee:
- quote quality
- solver availability
- RPC uptime
- watcher latency
- frontend correctness
- that a user chose the intended destination address
That is why integrators should display clear order state and give users transaction hashes.
Service-level checks
| Service | Important checks |
|---|
| Orderbook | quote exists, quote is not expired, quote is not consumed, amounts match exactly, commitment hash is unique |
| Relayer | secret length, preimage hash, vault deployment, settled state, hop route fields, hop signature, dedupe lock |
| Watcher | event source, block number, transaction hash, matching vault address |
Integration rules
- Generate secrets with secure randomness.
- Never reuse a commitment hash.
- Do not reveal the secret until the destination side is ready to claim.
- Treat orderbook state as indexed chain state, not a replacement for transaction verification.
- For hop routes, sign the exact hop payload the vault verifies.
If your app handles secrets, logs are part of your threat model. Avoid logging raw preimages in client analytics, server traces, crash reports, or support tools.
