Fourmate docs

Your liquidity companion for Uniswap v4 on Robinhood Chain.

What Fourmate is

Inspect pool mechanics, understand hook permissions, and add liquidity through a guided, wallet-controlled flow. Fourmate helps you see what you’re signing and follow what happens next.

• Inspect — pool state from StateView, core reserves from ReservesLens, hook permission bits decoded from the address, verification status from Sourcify and the explorer, admin probes that only count when the contract answers.
• Add Liquidity — a guided, wallet-controlled flow that mints or increases a Uniswap v4 position with your own tokens.
• Manage — positions owned by your wallet with range status, composition and uncollected fees; increase, remove, collect, burn.
• Ask Fourmate — an assistant grounded in the same tool results, with sources and explicit unknowns.

“Liquidity Assist” means helping you deploy your own capital. Fourmate supplies no capital, guarantees no liquidity depth, moves no token price and promises no return. There is no Fourmate token, no fee mechanism in this build, no audit claim and no partnership claim.

Networks

This deployment serves Robinhood Chain (chain id 4663, Mainnet). Network facts come from docs.robinhood.com/chain/connecting and were cross-checked with eth_chainId on three public endpoints.

• Mainnet (4663) — verified Uniswap v4 deployment; every flow is enabled.
• Testnet (46630) — developers.uniswap.org/deployments.json lists no Uniswap v4 contract for this chain; the app shows an honest shell with every transaction path disabled. To enable it, a verified deployment must be published and added to src/config/integrations.ts, then pnpm verify:integrations must pass.
• Local fork (31337) — an Anvil fork of mainnet used by the execution tests (pnpm chain:fork, pnpm flow:fork); labelled as development everywhere.

Support policy

Fourmate prepares liquidity transactions only for pools whose hook cannot intercept deposits or withdrawals: pools without a hook, and pools whose hook only acts on swaps, donations or initialisation.

Pools whose hook runs on add/remove liquidity, or that use custom accounting (return-delta flags), are shown for inspection but their transaction paths stay disabled until that behaviour is integrated and tested.

Inspection decodes declared permissions and verification status. It is not a security audit and never a safety verdict.

How a deposit works

1. Connect an injected wallet (EIP-6963). Fourmate reads through its own relay and never holds keys.
2. Confirm the network; a wallet on another chain is blocked from every write.
3. Choose a supported pool (search by symbol, token address or pool id).
4. Review the pool and hook inspection.
5. Enter amounts. The other side follows the range at the current price; nothing is swapped.
6. Choose a range: presets (not recommendations), price inputs in either direction, ± tick steps. Ticks snap to the pool’s spacing; invalid ranges are rejected with the protocol’s own rules.
7. Review the composition: liquidity obtained, exact amounts charged (rounded up as the PoolManager does), what stays in your wallet.
8. Preview: the server reads balances and both allowance layers, builds the steps, binds them to your account and chain, and the preview expires after 2 minutes.
9. Simulate: every step runs through eth_simulateV1 from your account (fallback: per-step eth_call); reverts are decoded against the verified ABIs.
10. Approve and submit: ERC-20 → Permit2 approval (exact by default), Permit2 → PositionManager allowance (time-boxed, 1 h by default), then modifyLiquidities. Each step is re-validated in the browser (chain, account, expiry, allow-list) right before the wallet is asked. Native ETH is sent as msg.value and the unused part returned by SWEEP.
11. Receipts are polled every second; a hash is persisted the moment the wallet returns it; replaced and reverted transactions are told apart; an approval that confirmed while the deposit did not is shown exactly like that.
12. The minted token id is read from the receipt and the position opens in Manage.

Slippage (0.5% default, 0.01–5%) bounds the amounts the PositionManager may take or must pay; the deadline (20 min default) reverts late transactions. Service fee: none; no fee mechanism exists in this build, every preview shows 0 and no transaction carries one.

Positions and fees

Positions are read from the PositionManager (getPoolAndPositionInfo, getPositionLiquidity, ownerOf) and StateView (getSlot0, getFeeGrowthInside, getPositionInfo with the PositionManager as owner and the token id as salt). Uncollected fees are liquidity × Δ feeGrowthInside / 2¹²⁸, exactly as Position.update settles them. Token amounts are the amounts a full withdrawal would pay at the current price (rounded down). Nothing is estimated from wallet balances.

The position token is not enumerable. Discovery uses the explorer’s NFT index, the PositionManager’s Transfer events to your address (adaptive, time-budgeted, newest first) and ids the browser remembers from its own mints; every candidate is confirmed with ownerOf. Coverage is stated with each list. Removing all liquidity does not burn the token; burning is a separate, explicit action.

Pool discovery

Robinhood Chain holds over a million Uniswap v4 pools (1,079,019 Initialize events were counted on 2026-10-25 UTC, about 707,000 of them without a hook), so no complete listing is served. The index is the union of verified-pair candidates (registry tokens × the four standard fee tiers, hookless), pools initialised in the recent window (an adaptive log scan with a time budget) and pools opened on demand. Any pool opens by id (PositionManager key store, then an Initialize lookup) or by token address (Initialize events on both currency slots). Every listing says what it covers and never claims completeness.

Ask Fourmate

The assistant is a server-side Anthropic Claude integration (the key never reaches the browser). It can call the same functions the pages use (network status, pool inspection, pool search, position reads, history, range explanation, deposit planning, the preview on screen) and must cite tool results with their block or timestamp, label observations versus explanations versus estimates, and name what it could not verify. Token names and contract names are wrapped as untrusted data. It cannot build calldata, sign, submit or ask for keys; its only actions are buttons that open deterministic flows you review in your wallet. Without ANTHROPIC_API_KEY it shows an honest unavailable state and the deterministic explanations still run — no canned “AI” replies.

The $4MATE token

$4MATE is the Fourmate token on Robinhood Chain (chain 4663). Its contract address is published on the landing page and announced first on @fourmaterh_; until then the site says Soon and no address claiming to be $4MATE is ours. Publishing is a verified step: pnpm token:set 0x… checks the EIP-55 checksum, the chain id, bytecode and the ERC-20 reads (symbol, name, decimals, total supply) before writing the address into src/config/token.ts; the page then shows the address with a copy button, an explorer link and the facts that were read. The site never shows a price, market cap or holder count for the token, and Fourmate never asks anyone to buy it. Current address: 0xd47760937E8BE87222F0ffcDE0006Eb3bCF7D393 (published 2026-10-26).

Data honesty

• Liquidity (L) is a pool unit and is never labelled TVL or dollars.
• USD values appear only with a dated price (Chainlink ETH/USD and USDG/USD on chain, DefiLlama by address) and say when one side is unpriced.
• Token identity is verified only for the hand-checked registry; everything else is “unverified metadata”, with look-alike symbols flagged.
• Hook permissions are facts; their economic meaning is interpretation; unreadable behaviour is unknown. No safety score, audit badge or verdict exists in the product.
• Every figure carries the block it was read at; stale data is labelled.

Capability matrix

Verified integrations

Every address below is pinned in src/config/integrations.ts and re-checked by pnpm verify:integrations (bytecode, wiring, Sourcify, deployments.json). Primary source: https://developers.uniswap.org/deployments.json (v1.0.0, generated 2026-10-16; records filtered by chainId 4663, tier labs-supported, status active; no record exists for chain 46630).

Configuration

See .env.example. Public variables (NEXT_PUBLIC_*) are baked into the client at build time: the network, the canonical site URL and project links (links that are not configured are not rendered). Server variables: the upstream RPC override, the log-scan endpoint, DoH pinning for blocked resolvers, index budgets and the Anthropic key, model and effort.

Limitations

• Pools whose hook runs on liquidity callbacks or uses custom accounting are view only until that behaviour is modelled and tested.
• No swap-assisted deposits: amounts are deposited as entered; the remainder stays in your wallet.
• Injected wallets only (no WalletConnect in this build); Permit2 allowances are set with transactions, not signatures.
• The pool index covers verified pairs, the recent window and on-demand lookups, not the full history.
• USD figures depend on third-party price sources and are shown with their age; many tokens have none.
• Testnet has no verified Uniswap v4 deployment; the fork-based execution tests stand in for a test environment.