One reward asset class (real tokenized stock), one funding source (ScanHood's own real trading fees), one state machine (Pending → Funded → Claimed), one rule: never credit more than real, already-collected revenue can back.
Because the treasury can't lie about what it actually holds.
StockBack is a rewards rail with one asset class (real tokenized stock, sourced from ScanHood's live Stock Deck), one funding source (ScanHood's own real trading fee revenue), one state machine per reward (Pending → Funded → Claimed), and one governing rule: never credit a balance for more than real, already-collected revenue can back.
You trade on ScanHood, like you already do. ScanHood earns its usual real fee. StockBack verifies that fee happened on-chain, sets a slice of it aside for you in stock, and — only once a real purchase has actually confirmed — lets you claim it into your own wallet. Nothing about this asks you to learn a new mechanism; it pays you for the one you're already using.
Every reward remains Pending until backed by a confirmed on-chain purchase, becomes Funded once that backing genuinely exists, and only leaves the treasury when the earning wallet successfully claims it. There is no path where a balance is credited ahead of the money that backs it — and no state is skipped: Funded-but-unclaimed is a real, often long-lived condition, not a transient one.
Six pieces. Everything in the system is a relationship between them.
| Entity | What it is | TLDR |
|---|---|---|
| User | The wallet that traded | Identity IS the wallet — no login, no Telegram, no separate account |
| The adapter | Verifies one real fee event on-chain | Anchored to known contract addresses, never a caller-supplied number |
| The ledger | Append-only, hash-chained record | Pending → Funded → Claimed, tamper-evident by construction |
| The treasury | Holds real, swept fee revenue | Spend is capped to what's genuinely been swept in, ever |
| The Stock Deck | Which real tokens are earnable | NVDA, AAPL today — AAPL auto-routes into a real yield vault |
| The claim path | Wallet-signature verified withdrawal | Claims always go to the wallet that earned them, no exceptions |
Every step either moves real capital forward or refuses to move state forward at all — there is no step that only updates a number without a real transaction behind it.
"Pending" is a promise denominated in USD, locked at the moment the fee is verified — not a promise of a fixed token amount. The stock conversion happens once, at settlement (section 05), using the real price at that moment. This avoids a specific ambiguity: promising "30% in NVDA" would leave open whether that means 30% of the fee's dollar value, or 30% of a token amount fixed early and exposed to price drift until settlement. StockBack always means the former.
A fee event is trusted only if all of the following hold, checked directly against the transaction receipt:
| Check | Why |
|---|---|
| Receipt status succeeded | A reverted transaction moved nothing |
| ≥3 block confirmations | A fee event just barely mined could still be reorged out |
receipt.to is ScanHood's real swap contract | Anchors trust to one specific, already-read contract (self-reviewed, not yet third-party audited) rather than to who received a transfer — a forged event from any other contract fails this outright. Corrected mid-build, 2026-08-29: the contract originally checked here has never actually charged a fee on its deployed instance; the real fee-generating contract, confirmed by reading what /swap itself calls, is a different one, verified for real against a live trade before this was trusted. |
Exactly one Buy/Sell event from that contract | The real contract emits a typed event carrying the trader's address and the exact fee amount directly — more than one in a single tx is an ambiguous shape the adapter refuses to guess about |
| Fee is paid in native ETH, priced live | The real contract's fee is always native ETH, not a token — priced via a live on-chain ETH/USD read at verification time, not a caller-supplied number |
| Revenue ID not previously consumed | The same real transaction can never be recorded as revenue twice |
Trusted contract: 0x8ebF0E2076E116A83204A552973Ed78FA98d5D6c (ScanHoodSwapV2, the contract /swap's own client-side code calls) — real 1% fee, read live off the deployed contract.
Settlement buys real stock before it credits anything — buy-first, credit-second. A Funded balance can never exceed what was actually, verifiably purchased.
Where totalWeightUsd is the full promised total across every Pending entry in the batch, and availableRevenueBackedUsd is real swept revenue minus real prior spend (section 06). Spend is never sized above real revenue unless a subsidy is explicitly, loudly authorized — never silently.
The scaling itself needs no special-case code: each entry's token payout is tokenAmountReceived × (rewardUsdi ÷ totalWeightUsd), so funding less than the full promise automatically shrinks every entry proportionally to what it was originally promised. A user who earned twice another's reward still receives exactly twice as much, at any funding level.
Every swap enforces a live 3% slippage tolerance against the pool's own current price (read on-chain, not assumed), and every purchase amount is computed as a real balance delta — after minus before — never a raw snapshot that could include unrelated funds already sitting in the treasury.
The treasury periodically sweeps ScanHood's real fee-recipient wallet into its own balance, and records every real settlement spend against it. This running total is what settlement's spendUsd is capped to. A subsidy beyond real revenue is possible but never silent: it's a named, explicit parameter, logged distinctly in both the console output and the permanent spend record.
Both revenue recognition (section 04) and treasury asset accounting price the same way now: a real, live on-chain ETH/USD read at the moment it matters, never a caller-supplied number. That wasn't always true in an earlier build — revenue recognition briefly only trusted USDG-denominated fees, back when verification pointed at a different contract. Corrected once the real fee-generating contract (native-ETH fees, always) was identified and verified against a live trade.
Claiming is wallet-native and self-custodial after withdrawal: the earning wallet authorizes the claim with a real EIP-712 structured signature — the wallet shows labeled fields (wallet, asset, timestamp) inside a domain scoped to StockBack specifically, not an opaque string to trust blindly — and the asset is transferred directly to that same wallet. Before that moment, a Funded balance is held by a dedicated reserve wallet, isolated from general treasury operations, not the user; claiming is what ends that, not a description of the whole system. There is no "claim to a different address" field — that entire phishing shape is closed by construction, not by a warning label.
What's actually transferred depends on how the reward was funded: a plain-stock balance sends the stock token itself; a balance that was auto-routed into the AAPL yield vault (section 05's Stock Deck) sends the vault's own share token instead, real and directly-owned, not redeemed back into raw AAPL first. That matters for three real questions: yield the shares have earned since being Funded belongs to whoever holds the shares — the user, immediately after claiming, same as any other vault depositor. The vault's own deposit/withdraw functions are gated to when it's between epochs, but a plain share transfer is not — verified directly against the vault's Solidity source — so a claim is never blocked or delayed by the vault's epoch state. The user can later withdraw the underlying AAPL from the vault themselves, whenever it's open to do so, exactly as any other depositor would.
$0.01 and 3× are fixed configuration, not claims of precision — what's live is realGasCostUsd itself, recomputed from the real current gas price on every single claim call, so the floor tracks real cost instead of a number someone forgot to update.
A reward below that minimum is not lost — it stays Funded exactly as it was, and combines with a future batch until it clears the floor.
| Tamper-evident | Every ledger entry is chained to the one before it with a real cryptographic hash. A quiet edit to any single record breaks the chain and is detectable on replay. |
| Crash-retry guarded | A real transaction is marked in-flight before it sends, cleared only after the ledger genuinely reflects it. A crash mid-transaction leaves the marker standing, so the next attempt refuses to auto-retry rather than risk paying twice — it stops the damage, it doesn't yet auto-recover the stuck state; that still needs a human to check the chain (see section 10). |
| On-chain coverage checked | Funded-but-unclaimed liability, per asset, can be compared directly against the treasury's real on-chain balance at any time — a check that can be run, not a continuously-enforced guarantee, and more meaningful once the customer-facing reserve is segregated from general treasury operations (section 10). |
| Duplicate-proof | The same real fee transaction can never be recorded as revenue more than once — enforced inside the same lock as the write, not a best-effort check. |
Three structural loops, each following directly from the mechanics above — none of them need a new liquidity mechanism to keep turning.
More real trading on ScanHood means more real fee revenue, which means more real stock gets Funded, which is the actual reason to keep trading here rather than switching. Nobody has to be recruited into a separate reward game — the reward rides on the activity they were already doing.
The fee event, the settlement purchase, the treasury balance, and the final claim transfer are all independently checkable on-chain — nobody has to trust a number in a database for any of those. Reward entitlement and the Pending/Funded/Claimed state transitions themselves are still server-enforced in this preview (see section 10) — the same honest boundary the phase badge on the main page states directly.
The same engine — verify a real revenue event, credit proportionally, settle from real swept capital — extends to any future ScanHood action that generates real fee revenue, without inventing new infrastructure per action. One rule, applied to a growing list of things people were already doing.
Stated plainly, not buried. The five items originally listed here are done — real, tested, verified against real chain data, not just described. What's left is smaller and named honestly.
| Reference-price oracle | Done. Settlement now checks the pool's implied price against ScanHood's own real listed-market-price feed before trading, and refuses if they've diverged too far — an independent check, not just self-referential slippage. |
| Full transaction lifecycle | Done. A stale in-flight marker is now automatically reconciled against real chain state on restart — claims resolve fully automatically; a settlement that genuinely succeeded is surfaced for a quick human confirmation rather than left as an opaque stuck state, since re-deriving the exact purchased amount safely is the one piece still done by hand. |
| Separate customer reserve | Done. Real stock purchased for users now lands directly in a dedicated reserve wallet, never the operating treasury — visibly isolated from the moment it's bought, not just in bookkeeping. |
| EIP-712 claims | Done. Claiming is real structured signing now — your wallet shows labeled fields (wallet, asset, timestamp) inside a domain scoped to StockBack, not an opaque string. |
| On-chain vault contract | Deployed and tested, not yet the live path. A real, audited-by-test contract exists on-chain and has been proven with a real credit-and-withdraw cycle — but settlement and claiming still run through the reserve wallet directly, not through this contract. Wiring the live flow through it is the real remaining step toward not having to trust a server-held ledger at all. |
| Legal review | Not something code can close. The disclaimer in this document describes function, not legal or regulatory status, and hasn't had a lawyer's eyes on it. |
