Capture
Ask AI
Capture copies a committed week's beacon randomness into the draw.
IT IS NO LONGER A SAFETY MECHANISM, AND SAYING SO IS THE POINT OF THIS COMMENT. What it used to say: "the beacon keeps signatures for beacon.PruneWindow = 2016 rounds, about seven days at a five-minute cadence; this raffle is WEEKLY, so a draw settled late can find its round already pruned and the pot would have no way to name a winner. Capture preserves the value while it is still there." Every clause of that is now false. r/splash/beacon has no retention window and no Prune, drand serves every round for ever from at least three public relays, and Publish is permissionless — SO THERE IS NOTHING TO PRESERVE THE VALUE FROM. There is no capture window either; the old paragraph computed one, and it does not exist.
WHAT IT STILL DOES, which is why it is kept rather than removed:
- it copies a public value into the draw's own state, so Resolve needs no beacon read later and the settled draw is self-contained;
- it makes the value visible through CapturedRandomness and the Capture event before the week is settled, which a front end and an auditor can both use.
A CONVENIENCE, then. Removing it would delete an exported realm function and a large block of correct, tested behaviour in order to retire a comment; retiring the comment is enough. Nothing in this realm's safety now depends on anyone calling it — see resolvable()'s removal and Refund's gate.
PERMISSIONLESS, deliberately. Its only effect is to store a value that is already public — the round's randomness, readable by anyone the moment it is published. Gating it on an operator would buy nothing and would put a liveness dependency for the whole pot back onto one key.
WHAT IS STORED IS THE 64-CHARACTER HEX RANDOMNESS — sha256 of the signature, a hash, not the signature itself — and it is NOT re-verified here. The pairing check happened once already inside beacon.Publish on the way in; redoing it would be expensive duplicated work on an input that is already known good, and the beacon has no route by which a published round's randomness can change afterwards.
A SECOND Capture NEVER OVERWRITES THE FIRST, and is a silent no-op rather than a panic: two callers racing to perform a permissionless public good should not make one of them fail.
Capturing before the round is published PANICS. There is nothing to preserve yet, and storing anything else — least of all some already-published value — would hand the draw a randomness for a round nobody pinned, which is the exact attack the pin exists to prevent.
COMMIT DOES NOT CAPTURE, AND MUST NOT START. Since the round is pinned at record creation, a week's round may well be published by the time it is committed, so a capture there would often succeed — and it would put a beacon read back inside the one function whose job is to choose nothing. Capture staying separate and permissionless is what keeps the commit path free of any beacon dependency at all; see Commit's note on why there is no publication check there either.
Command
# WARNING: This command is running in an INSECURE mode.
# It is strongly recommended to use a hardware device for signing
# and avoid trusting any computer connected to the internet,
# as your private keys could be exposed.
gnokey maketx call -pkgpath "gno.land/r/g1r4aw43kagaaquhegxw6xr346h9f2qu2ezf0jar/arcade/raffle/v3" -func "Capture" -args $'' -gas-fee 1000000ugnot -gas-wanted 1_000_000_000 -send "" -chainid "onyx-1" -remote "https://rpc.onyx.testnets.gno.land" ADDRESSgnokey query -remote "https://rpc.onyx.testnets.gno.land" auth/accounts/ADDRESS
gnokey maketx call -pkgpath "gno.land/r/g1r4aw43kagaaquhegxw6xr346h9f2qu2ezf0jar/arcade/raffle/v3" -func "Capture" -args $'' -gas-fee 1000000ugnot -gas-wanted 1_000_000_000 -send "" -broadcast=false ADDRESS > call.tx
gnokey sign -tx-path call.tx -chainid "onyx-1" -account-number ACCOUNTNUMBER -account-sequence SEQUENCENUMBER ADDRESS
gnokey broadcast -remote "https://rpc.onyx.testnets.gno.land" call.tx