# Torinox Protocol security and integration assumptions

Torinox Protocol v10 is a two-party commit-reveal oracle on Robinhood Chain. It is not a cryptographic VRF and it is not trustless.

## Contributions and visibility

The provider commits a Keccak256 hash-chain root before requests use its values. The provider's future preimages must remain secret. A requester supplies a fresh 32-byte contribution to `requestV2`.

The request contribution is public when the request transaction enters public transaction propagation and is permanently public once included onchain. Hashing transaction fields, block values, timestamps, addresses, or other public inputs does not create secret entropy. Generate the contribution locally with a cryptographically secure random number generator before submitting the request.

The completed random word is:

```text
keccak256(abi.encodePacked(userContribution, providerContribution, bytes32(0)))
```

The third input is zero because v10 explicit `requestV2(address,bytes32,uint32)` requests set `useBlockhash = false`.

## What each party can do

Before the request is public, the provider is committed to its hash-chain value and does not know a fresh requester contribution. After the request is public, the provider learns that contribution and can compute the output for its committed preimage before revealing it. The provider cannot replace the committed preimage with another valid value, but it can withhold service.

A requester who does not know the provider preimage cannot predict the completed word from its own contribution. Applications should commit game state and payout rules before requesting randomness so they cannot reinterpret the result afterward.

## Withholding and refunds

A provider can selectively withhold after learning the would-be output. The refund path restores the exact request fee after 6 L1 blocks, but does not produce randomness, restore request/refund transaction gas, or undo application-level consequences of a missing result. Applications must define what happens when no reveal arrives.

Only the onchain `requester` may call `refundRequest`. If an application contract made the request on behalf of a user, the oracle refunds that application contract. The application must record the user for each sequence number and route the received ETH to that user if that is its policy. See the runnable `MyGame` example in `/docs/quickstart/`.

## Operational and review boundaries

The live deployment has one designated provider. Provider seed secrecy and keeper liveness are operational assumptions. TorinoxEntropy v10 is immutable and source-verified on Blockscout. Internal and automated review exist; no independent third-party audit report has been published for v10.