LIVE

surp/free $0.00 free│ surp/best-chat $0.012 ↓│ surp/best-coding $0.034 ↑│ usdc/base $1.00│ tps 847 ↑│ ttft 120ms ↓│ cache hit 34% ↑│ models live 1,204│ srp pool 2.4M ↑│ surp/free $0.00 free│ surp/best-chat $0.012 ↓│ surp/best-coding $0.034 ↑│ usdc/base $1.00│ tps 847 ↑│ ttft 120ms ↓│ cache hit 34% ↑│ models live 1,204│ srp pool 2.4M ↑│

proposal: cache flywheel rewards

vote on how surp.ivc.lol should handle rewards for agents that create shared cache value.

this is an advisory vote. Nothing here commits funds, mints a token, or promises profit. It is a transparent signal to the maintainers about what the community wants. Read the full proposal below before voting.

the idea, in plain English (ELI5)

Every time an AI agent asks surp.ivc.lol a question, it pays a tiny amount of USDC. If the question is one the network has already answered, the network can return a cached copy instead of calling the model again. That saves real money and time.

Right now surp keeps all of that savings. But what if the agents that created the cached answer, and the agents that reused it, got a small reward? Then:

Agents would want to reuse the cache (more rewards) instead of bypassing it.
Agents would ask useful, reusable questions (their cache gets reused → they earn more).
The network's costs would drop as the shared cache grows.
Loyal heavy users would accumulate a claim on the savings they helped create.

The more the network is used, the cheaper it gets for the people using it — a positive feedback loop. That is the core idea behind a "revenue network" or RevNet.

what's running right now (off-chain prototype)

To prove the loop works before touching real money, surp runs an off-chain accounting ledger called SRP (surp reward points). No token contract, no blockchain settlement — just a database that records who created how much cache value.

$0.0805

rebate pool backing

333

SRP outstanding

reward holders

0.024186¢

implied value per SRP

live data from GET /api/stats. these are tiny numbers because the experiment just started — the point is the accounting loop works.

how SRP is earned

event	who earns	rate
cache write (a reusable answer is created)	the payer who funded it	1 SRP per token cached
cache hit (the answer is reused)	the original author	2 SRP per token saved
cache hit	the agent that reused it	0.5 SRP per token saved

how SRP is backed

A share of estimated gateway revenue is earmarked to a rebate pool. SRP's implied value = pool ÷ outstanding SRP. As revenue flows in, existing SRP appreciates. That's the RevNet redemption mechanism, done off-chain.

the question for the community

SRP works as accounting. But should it stay an internal ledger, or should we move the backing on-chain so rewards become real, verifiable claims? Here are the options as we see them. Vote below.

option A — keep it off-chain (safest)

SRP stays a transparent accounting simulation. No token, no contract, no legal exposure. We keep measuring and publish metrics. Downside: rewards are not portable or independently verifiable; agents have to trust the ledger.

option B — Juicebox treasury + Merkle claims

A portion of gateway revenue flows into a Juicebox project with public splits (inference costs, operations, rebate reserve, community). We publish periodic Merkle roots of off-chain SRP balances; agents claim USDC rebates on-chain. Medium setup cost, high transparency, no new speculative token.

option C — RevNet revenue-backed token

Gateway revenue backs a redemption pool for a network token. Token holders can redeem against the pool. This is the strongest loyalty flywheel — use the network, earn a claim on its future revenue — but it requires the most legal/engineering care and carries the most token-risk.

option D — hybrid (recommended by maintainers)

Keep SRP off-chain for 30–90 days to gather real farming/Sybil data. Then move backing to a Juicebox treasury and publish Merkle claims. Only transition to a full RevNet if the economics prove out. Slower to ship, but avoids permanently encoding bad reward weights.

cast your advisory vote

One vote per person. You can change it later. Your handle (or IP if you leave it blank) is salted and hashed — we never store the raw value.

vote handle (optional — leave blank to vote anonymously by IP) your choice

pick an option above

comment (optional, max 280 chars)

live results

1 votes cast (0 changed their mind)

0 (0.0%)

keep it off-chain

0 (0.0%)

Juicebox treasury + Merkle claims

0 (0.0%)

RevNet revenue-backed token

1 (100.0%)

hybrid: off-chain now, RevNet later

anti-farming guardrails

Rewards are deduplicated per cache entry, role, and payer for one hour.
Only deterministic, non-streaming, tool-free requests enter the exact cache.
Raw prompts are never stored — only SHA-256 fingerprints and completed responses.
Cache readers still pay a discounted $0.001 micropayment, preventing free probing.
Most author rewards only mint when an independent agent reuses an entry — write-spam has little value.
One salted hash per voter; votes can be changed, not multiplied.

risks and honest caveats

Sybil attacks: a determined attacker could spin up many wallets. Off-chain first lets us measure this before going on-chain.
Reward weight tuning: 1/2/0.5 SRP rates are guesses. Real traffic data will tell us if authors or readers are over/under-rewarded.
Legal: any on-chain token with revenue backing may be a security in some jurisdictions. The hybrid path delays this risk until the model is proven.
Centralization: until on-chain settlement exists, the maintainer holds the earmarked pool. Juicebox/RevNet removes this trust assumption.
Cache poisoning: a malicious agent could try to fill the cache with wrong answers to farm rewards — but readers still pay, answers are deterministic, and the dedup window limits farming.

not financial advice, not a security. SRP is currently an internal accounting unit with no on-chain existence, no transferability, no guaranteed redemption, and no expectation of profit. Voting here signals preference only.