Frontend engineers & reviewers
Implemented routes, data trust, transaction states, accessibility and release validation.
Frontend UX reference
The frontend is a statically exported Next.js application. It reads public chain state and constructs user transactions; it has no protocol authority or server-side custody.
Routes
| Route | Purpose | Writes |
|---|---|---|
/ | protocol model and participation paths | none |
/dashboard | backing, vault, markets, governance, modules, and oracle status | none |
/bonds | live markets and bounded deposits | approval, deposit, note redemption |
/stake | ERC-4626 vault deposit and redemption | STONK approval, deposit, redeem |
/governance | delegation, proposals, and voting | delegate, propose, vote, queue, execute |
/treasury | holdings, prices, haircuts, and backing | none |
/docs/* | canonical repository documentation | none |
/faucet | test assets outside mainnet | faucet calls |
Deployment trust
Addresses are generated from deployments/<chainId>.json. Missing contracts render an unavailable state. Writes require the selected chain, manifest, live RPC, connected wallet, and required reads to agree.
Production publishes only after the deploy script confirms a Privy application ID is embedded and verifies the live custom-domain bundle and commit marker.
Vault UX
The stake page has Deposit and Redeem modes:
- read STONK and stSTONK balances, decimals, allowance, and ERC-4626 preview;
- display the input, expected output, assets per share, total assets, and total shares;
- approve STONK only for deposits;
- submit the slippage-protected overload with a 0.5% minimum-output bound;
- refresh balances and previews after confirmation.
Copy must say stSTONK is non-rebasing. The balance remains fixed unless transferred, minted, or burned; STONK per share can rise when revenue enters the vault. The UI must not show epochs, an index, a wrapper, or promised APY.
Governance UX
The governance page reads stSTONK balance, current delegated votes, delegate address, proposal threshold, and proposal events. The same token is delegated and voted. There is no conversion step after staking.
Proposal actions must display decoded targets and calldata where possible, state, voting window, quorum progress, and Timelock readiness. Wallet simulation precedes submission.
Transaction safety
- Every bond deposit supplies maximum price and minimum payout.
- Every vault action supplies minimum output or maximum input.
- Approvals are exact to the current action where practical.
- Transaction simulation runs before wallet submission.
- Wrong chain, stale required reads, invalid oracle state, inactive modules, missing deployment, and insufficient balances disable writes with a reason.
- Confirmations link to the active chain explorer and trigger fresh reads.
Units and copy
- STONK and stSTONK: 9 decimals.
- PRICE and backing: USD18.
- Quote tokens: native token decimals.
- Backing is never labeled redeemable value, price floor, or peg.
- stSTONK is never described as guaranteed yield.
- Zero active markets means governance has not opened capacity, not that a new time period is pending.
Accessibility
All transaction paths must be keyboard reachable, have visible focus, labels independent of color, useful disabled reasons, reduced-motion support, responsive tables/cards, and screen-reader status for pending, confirmed, and failed transactions.
Release validation
cd app
pnpm abis
pnpm typecheck
pnpm build
pnpm test:e2e
cd ..
bash scripts/e2e-frontend-anvil.sh
Production smoke tests cover all routes, wallet connection on the allowed origin, wrong-chain rejection, STONK approval, vault deposit/redeem, direct delegation, bond limits, proposal voting, unavailable deployment, stale oracle, and emergency states. Verify DNS, TLS, CSP, frame restrictions, MIME protections, referrer policy, manifest addresses, bytecode, and served commit before launch.