Security

This page is the security reference for integrators. It is not a marketing page and it does not claim a third-party audit that does not exist.

What is verified onchain

• Reveals are checked with Keccak256 against the registered commitment.
• The fee must match getFeeV2() exactly.
• The consumer callback receives the combined bytes32.
• Unrevealed requests can be refunded after 6 L1 blocks.

Trust assumptions

• Single designated provider on the live deployment.
• The provider seed must stay private. If it leaks, future reveals can be predicted.
• Consumers must supply fresh user randomness. Predictable user entropy weakens the two-party model.
• Keeper liveness is operational. Missed reveals are handled by refund, not by inventing a result.
• Commit-reveal aims to stop either party from unilaterally choosing the final word when commitments hold. It is not a claim of perfect fairness under every operational failure.

What exists today

• Internal review of TorinoxEntropy v10 and operational keepers.
• Automated analysis (Slither and related tooling). Notes are review notes, not a formal audit report.
• Immutable contract. No proxy upgrade path.

What does not exist yet

• No independent third-party audit firm report has been published for TorinoxEntropy v10.
• Do not treat docs filenames or checklist lines as evidence of an external audit.

Operational history

A pre-v10 operational issue involved keeper credential exposure. It was mitigated before current public v10 surfaces. That was an ops incident, not an open bug in current v10 bytecode.

Live contracts

Oracle: 0xd8a0680e7699526b57140ed4eafdcc7219dc0a0c

Stake: 0xc091ce59cAC1112A30e4344ced039c25B6cfa174

Quota: 0x825AC2A5Ca8D8A6E56dF418C3227a72bD39830F3

Review notes: security-audit.md (internal + automated).

How to recompute a result: /docs/verification/.

Home · RNG for Robinhood Chain · Docs · Architecture · Security · SDK · x402 · GitHub