Proof · read by your browser

Don't take our word for it. Ask the chain.

As this page opened, your browser started asking the chain the questions on the right: is this the chain config names, is there code at every address, does the router name the factory and the pool we say it does, and does that pool have the 30 minutes of price history a harvest needs. Each row turns over into what came back, and when.

A row says match only when this visit's read returned the expected value. No answer is unreachable, never a tick. No STASH contract exists yet, so nothing here says STASH is on chain: these are the pieces a vault will stand on.

Check it in a terminal
8
checks on every visit
9
addresses in config, each asked for code
4
pools, dated and read again
0/3
launch steps with a hash

Chain checks

reading 8 checks · 0 back

RPC—

  1. 1

    Reading config/addresses.json…

each row: what was asked · what came back · when (UTC)timeout 6 s · never a cached value

Where the reads go

From your browser to the chain and back. Nothing in between is ours.

The page reads one file from this site, config/addresses.json, and from then on talks only to the chain's public RPC. Every dot below is a real request this visit made, and every dot that comes back is a real answer. There is no server of ours in the path to agree with itself.

config/addresses.json addresses, chain id, RPC, pools read once, from this site your browser request · JSON-RPC over https answer · or nothing within 6 s RPC the chain
this visit

0 requests sent

answered

0 answers, a revert counts as one

no answer

0 timed out or refused

drawing the dots are this visit's requests

Claims ledger

If it's not a hash, it's not a claim.

STASH exists on chain after three transactions, in this order. Each one either has a hash you can open on Blockscout, or this page says not yet. The rows are filled from config/addresses.json, the same file the app reads; nobody writes "done" by hand.

Reading config/addresses.json…

  1. 1

    Factory deployed

    One contract that creates vaults, and refuses a vault unless admin, guardian, treasury and keeper are four different non-zero addresses and the pair has a pool.

    deploy transaction

    64 places, all empty: no transaction yet

  2. 2

    Vault #1 created

    The factory's createVault call. From then on the coin, reward, router and pool fee of that vault are fixed; the vault is seeded before it opens.

    create transaction

    64 places, all empty: no transaction yet

  3. 3

    Yield source signed

    Source A: the coin's creator points its fee recipient at the vault and signs it. Source B: twenty real payouts to a vault-shaped test account. Buybacks do not count.

    source transaction

    64 places, all empty: no transaction yet

launch checklist · derived from config/addresses.json
  1. Factory deployed—
  2. Vault #1 created—
  3. Yield source signed—
every claim, row by row · a link or "not yet"

Reading the ledger…

A vault adds three rows here the moment config names it: its contract, its create transaction and its yield-source transaction.

Chain constants

Every address, asked for its code in this visit.

A contract address with no code behind it is just a number. Each bar is the size of the code your browser found at that address, drawn as it arrives. The addresses were not copied from documentation: the router was asked to name its own factory and its own WETH (checks 3 and 4 above).

    used STASH's contracts or its keeper script call this address.

    An address config records but the contracts never call is shown by its address only, without a name.

    Full scale is 24,576 bytes, the most code the EVM lets one contract hold (EIP-170), so a bar never rescales.

    Harvest liquidity

    The pools a harvest would sell into, then and now.

    A harvest sells what the coin paid for more of the coin, in one Uniswap v3 pool fixed per vault. How deep those pools are is not a constant, so it is shown twice: as config recorded it, with its block and date, and as your browser reads it now.

    WETH / USDG · balance each pool holds
    recorded · — reading balances…

    Balances are balanceOf() on each token for each pool address. They say how much sits in the pool, not how much a trade can take at a given price.

    the price floor, on this visit's read

    A harvest that sells below this line is refused.

    30-min average (TWAP)
    —
    price now (slot0)
    —
    floor · defaults
    —
    room above the floor
    —

    USDG per WETH · reading…

    floor = TWAP30 min × (1 − pool fee) × (1 − 1%)

    With the defaults and the 0.01% pool, a harvest that sells 1 WETH must get at least the floor in USDG, or the swap reverts. The keeper can make the tolerance stricter, never looser. A pool without 30 minutes of history gives no average, and then no harvest runs at all.

    the same rule under attack
    2,477.780.9 WETH quote before
    2,369.67after a 1,500 WETH same-block dump
    2,450.62floor, unchanged · harvest reverted

    fork test against live state, 22 Sep 2026 · USDG · more on Security

    Run it yourself

    The same eight questions, in a terminal.

    A page can be written to agree with itself. These commands are generated from the same config file the checks read, for Foundry's cast. Point $RPC at any node you trust and compare the answers with the rows above.

    cast · generated from config/addresses.jsonread-only calls
    Reading config/addresses.json…

    Checked, not believed.

    One share. A rate that never falls.

    Reading config/addresses.json…