How to verify a result

Verifiable randomness means a third party can recompute the same outcome from public data. Torinox does not ask you to trust a tweet, an agent reply, or a UI label. Recompute the word, then recompute your mapping.

What verifiable randomness means here

After a reveal, the contract has checked that the provider preimage hashes to the stored commitment and has combined it with the consumer user-randomness. Anyone can open the transactions and repeat those checks. The app result is only as verifiable as the published mapping from that bytes32.

Steps

1. Open the request and reveal transactions on Blockscout.
2. Confirm oracle, provider, sequence, and that the request was not refunded.
3. Recompute the commitment relation: hashing the revealed preimage must match the stored commitment path.
4. Recompute Keccak256(userRandomness ‖ providerContribution ‖ bytes32(0)) and compare it to the emitted random word.
5. Apply the same deterministic mapping your app published, for example (uint256(random) % 100) + 1.

Mapping example

// Torinox returns the full bytes32 only.
// Inclusive 1..100 in the consumer:
uint256 roll = (uint256(randomNumber) % 100) + 1;

If two viewers apply different mappings, they will disagree even when the oracle word is correct. Publish the formula before the request.

Checked evidence

These dated, machine-readable references separate verified observations from first-party statements and document the protocol's integration assumptions:

• Claim register
• Deployment verification
• Security and integration assumptions

Social and agent proofs

Torinox Agent proof pages expose request, transactions, random word, and mapping. That is a convenience surface over the same onchain facts. See /agent/ and /docs/use-cases/ai-agents/.

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