SURGE token design

Why a token at all

Surge is only as trustworthy as its policy: which addresses are canonical, which feed maps to which token, how old a reference may be, what band is the default, which pools are considered. Today that policy is code in this repository, changed by whoever maintains it. A registry contract governed by a token puts those decisions under shared, timelocked control that other builders on Robinhood Chain can read on-chain and rely on. The product works fully without the token; the token exists to decentralise the policy, not to fund the product through speculation.

Utility (in order of importance)

1. Registry governance. SurgeRegistry stores per-token entries: canonical address, Chainlink proxy, staleness thresholds, default band. Changes are proposed with a SURGE deposit, voted by token weight, and executed after a timelock. Proposals that fail lose part of the deposit to the treasury (anti-spam), not to voters.
2. Fee discount. If a guard-fee router is ever deployed, its fee is a capped share of routing surplus (the difference between the fill and the guarded minimum), never a cut of principal. Paying that fee in SURGE is discounted. No such fee exists today.
3. Credits. Alert delivery and higher API tiers, when they exist, are metered in SURGE credits.

Non-goals

• No emissions, no staking yield, no revenue share, no buyback promise.
• No admin mint. Supply is fixed at deployment in the draft contract.
• No influence over prices: SURGE cannot change what Robinhood or Chainlink publish, only which sources Surge trusts and how strictly.

Design parameters (the drafted contract in the repository)

See the roadmap in how Surge works for where this sits in the dependency order, and contracts/README.md in the repository for the current draft.