Trust
Security model
Who is trusted with what, what holds regardless of anyone's behaviour, and where the design is weak. Written to be checked, not believed.
Roles#
| Role | Can | Cannot |
|---|---|---|
| Upgrade authority | Replace the program code. | Nothing is beyond it. See below. |
| Admin | Bind the mint before activation, rotate roles, change the settlement delay, pause. | Move vault tokens; change the schedule or mint after activation. |
| Oracle | Publish epoch roots. | Exceed the emission schedule, shrink allocations, skip the settlement delay, move tokens directly. |
| Guardian | Pause; cancel a root during its delay. | Publish roots; move tokens. |
| Anyone | Activate once funded; settle a matured root; pay for someone else's claim. |
Enforced by the program#
- Custody. The vault is owned by a program-derived address. The only outflow is a claim to the wallet named in a proven leaf.
- Reserve. Activation needs the full reserve and leaves exactly that.
- Mint. Fixed supply, no mint or freeze authority, no transfer fee, hook or permanent delegate.
- Emission cap. A root's total cannot exceed the cumulative schedule, and the schedule is frozen at activation.
- Monotonicity. Epochs increase; totals never decrease; an open epoch cannot be published.
- Delay. A root is not claimable until its delay passes, and can be cancelled until then.
- Payout ceiling. Total claimed never exceeds the settled root's declared total, even if its leaves sum to more.
- Initialization. Only the upgrade authority can initialize, so a deployment cannot be front-run.
Trusted, and why#
| Trusted party | Trusted for | Mitigation |
|---|---|---|
| Operator / oracle | Computing Goon Power honestly. Scoring happens off-chain. | Public distribution files with on-chain hashes; emission cap; settlement delay; guardian. |
| Whoever watches roots | Noticing a bad root before it settles. | A 12-hour window per epoch. It only works if someone looks. |
| Upgrade authority | Not replacing the rules. | To be moved to a multisig before mainnet; the program can be made immutable later. |
| Reviewers | Scoring contributions fairly. | Category ceilings, weekly limits, no self-review, audit log. |
| Issuers | Attesting only to things that happened. | Allowlist, per-proof and per-wallet caps, revocation, suspension. |
A settled root is final. A later root cannot take back what was paid; it can only stop further payment. That is the price of claims that cannot be censored.
Abuse resistance#
A browser cannot prove a human is present. The games are generated and verified on the server, so a result cannot be forged, but a script that reads the parameters can play them. The design does not pretend otherwise. It makes automation unprofitable rather than impossible.
| Control | Effect |
|---|---|
| Only time spent landing hits counts | The server runs the fight. An idle or background tab earns nothing. |
| Front-loaded session curve | The second hour is worth an eighth of the first. |
| Per-source caps and a global cap | Effort past the cap earns exactly nothing. |
| Pro rata rewards | Emission is fixed. More fake wallets dilute each other. |
| Network Goon Power floor | A thin epoch does not hand its whole pool to a few wallets. |
| Cluster trust | Wallets sharing a network fingerprint beyond the allowance split a fixed share. |
| Minimum answer time, precision flags | Instant answers fail; machine-precise ones are flagged for review. |
| Unique ledger keys | One reward per challenge, per link, per proof, enforced by the database. |
| Server-side combat | Damage, position, cooldowns and loot are decided by the server, never reported by the client. |
| Exclusion before settlement | An admin can zero a wallet's unsettled Goon Power. |
| Optional bot check and minimum balance | Per-session and per-wallet friction the operator can switch on. |
Privacy#
- No account, email, name or identity. A wallet address is the only identifier.
- No sexual or intimate content is requested, collected, inferred or stored, anywhere in the system.
- IP addresses and user agents are kept only as salted hashes, for abuse detection.
- On-chain: wallet addresses and cumulative token amounts. In distribution files: per-epoch Goon Power totals. No activity detail is published.
- Integration proofs carry an opaque activity label and a score. Nothing else about what a person did leaves the issuer.
Key handling#
- The oracle key is the only hot key. It can publish roots within the cap and nothing else.
- The guardian key should be held separately and offline; it exists to stop the oracle.
- Solana RPC credentials stay on the server. The browser reaches the chain through a same-origin proxy that allows only the JSON-RPC methods the app uses.
- Sign-in tokens are short-lived bearer tokens. They authorise game actions; they cannot move funds. Claims are ordinary transactions signed by the wallet.
Assurance status#
The program has a 29-test suite and has been run end to end against Meteora's mainnet bytecode on a local validator. It has not been independently audited. See the risk disclosures.