PROTOCOL NOTES

What follows describes how this interface obtains every figure it displays, so that any number on the board can be traced back to something verifiable.

1 · Hook permissions

Uniswap v4 packs a hook's callback permissions into the low 14 bits of its address. The board masks the configured hook address with 0x3fff and decodes the flags using the same constants as v4-core's Hooks library. No RPC call is needed and no trust is involved: the PoolManager enforces those same bits.

Where the deployment also exposes getHookPermissions(), that answer is read and displayed alongside. If the two disagree, the board says so rather than choosing.

2 · Pool identity

A v4 pool id is keccak256(abi.encode(PoolKey)). Given the pool key components in the environment — the two currencies, the fee, the tick spacing and the hook — the board derives the id locally and shows the same value the PoolManager uses. Without those components it shows POOL KEY NOT CONFIGURED.

3 · Fees

The only fee figures shown are the pool key's own: the static fee, or DYNAMIC when the key carries v4's dynamic-fee sentinel, together with the tick spacing. Buy, sell and burn rates are shown as NOT CONFIGURED unless the deployment publishes them through events named in the environment.

4 · Events

Hook events are decoded with the deployment ABI in src/lib/contracts/hookAbi.ts. While that array is empty, the board reports HOOK ABI NOT CONFIGURED and decodes nothing. Which decoded event counts as fee capture, buyback or burn is declared explicitly by NEXT_PUBLIC_EVENT_FUEL, NEXT_PUBLIC_EVENT_BUYBACK and NEXT_PUBLIC_EVENT_BURN. An event with no declared role is left unclassified.

5 · Burn accounting

Two models are supported and the deployment declares which applies through NEXT_PUBLIC_BURN_MODEL:

• sink — tokens are transferred to an address nobody controls. Removed supply is that address's ERC-20 balance; total supply is unchanged.
• supply — tokens are destroyed. Removed supply is NEXT_PUBLIC_BASELINE_SUPPLY minus the current totalSupply().

Where neither is configured, the board reports NOT CONFIGURED instead of picking one.

6 · Where history comes from

Burn history resolves in order: Supabase if an indexer is running, then Alchemy transfer history if a key covers the network, then a bounded eth_getLogs scan back from head. If none can answer, the board says INDEXER UNAVAILABLE. The supply curve is reconstructed from those observed burns by adding each one back to the current figure — it is derived from readings already shown, not from a separate history.

7 · Live updates

Block height is watched on a twelve-second interval. Contract reads are cached by React Query and refetched on a slower cadence. When Supabase is configured, new rows arrive over Realtime and are merged into the running record without polling.

8 · This deployment

THEORY →