A failed callback should not give an onchain game a second roll

Security explainer | Documentation reviewed September 17, 2026.

A randomness service can accept a valid proof even when the game's receiving function fails. Treating that failure as permission to request a different result can introduce a new problem: an application may end up selecting among outcomes instead of honoring the original draw.

Chainlink's VRF security guidance warns against cancellation or re-request patterns that allow randomness to be discarded. The broader design principle also matters when evaluating other providers.

D20DAO documents a useful separation between proof acceptance and callback delivery. Once a proof is accepted, its retry mechanism sends the same stored result again. It does not generate a replacement draw, and delivery retry does not earn another service fee. A failed callback alone does not qualify for the unfulfilled-request refund.

Requests without an accepted proof instead become eligible for a refund transaction after the 60-second deadline. The refund uses the ratio fixed when the request was created; gas and application payments are outside that refund. Game developers must therefore define what happens to a player's stake or purchase separately.

This is a constructive recovery pattern, not a security certification. D20DAO remains dependent on its operator and trusted upgrade authority, and its contracts have not received an external audit.

Sources: Chainlink VRF security considerations, D20DAO service rules, security model, SDK audit statement.