Add an options guide for randomness in Soroban contracts

[briwylde08]

Soroban has no native randomness primitive and the docs don't discuss it. Builders who need it (games, raffles, fair ordering) each invent a workaround. Meanwhile the landscape is moving: CAP-0089 proposes VRF-based protocol randomness with a stellar-core PR implementing ECVRF, a community drand relay exists, and an SCF-funded Soroban VRF project is in flight.

Please add a guide covering:

• what randomness a contract can and cannot get today;
• the options (oracle/relay such as drand, an on-chain VRF contract, commit-reveal) with trust and cost tradeoffs;
• a note on CAP-0089 so builders can plan for it.

Surfaced by Frontier Lab's ecosystem crawl.

[nema1502]

Hi! I'm building Tinkazo, verifiable community draws on Soroban. Its contract checks a drand quicknet round's BLS signature on chain with the BLS12-381 host functions (CAP-0059), so there's no oracle or relay to run, and anyone can finalize a draw once the target round is published.

I'd be glad to write this guide. What I have in mind:

• What a contract can get today and where it falls short: ledger values, and env.prng(), whose seed is public and can be biased by a validator, plus the blind-rerun risk described in The PRNG docs should emphasize potential risks from blind-rerunning rs-soroban-sdk#1748.
• The stronger options and their trade-offs: commit-reveal with a future round, verifying a drand round on demand inside the contract, a drand relay like Drand-Relay, and a VRF like the SCF-funded VRF-Soroban.
• Costs measured on testnet and the trust assumptions of each, with a small example contract.
• A short note on CAP-0089.

I'd add it as a new page under Build → Guides, cross-linked with the PRNG docs update in stellar/rs-soroban-sdk#1748 and the planned commit-reveal example in stellar/soroban-examples#255, so the three fit together. Does that scope work for you?