Intent Pay — intent-driven payments on Monad

Intent Pay is an intent-based payment layer for the Monad blockchain. A user expresses an outcome — a recipient, an amount, and the token the recipient should receive — and the application determines the rest: which of the user's balances to spend, how much of it is required, the conversion route, the bounds that protect the swap, the transaction to construct, and how to prove the recipient actually received the funds.

The product is deliberately not a swap interface. The interface says “Pay”, not “Swap”. The user reviews a payment — recipient, amount, fee, route — and authorizes it once in their own wallet. Routing, liquidity, fee tiers and calldata never surface in the primary flow.

The system runs on Monad mainnet (chain id 143) and executes through the user's own injected wallet. Gas is always paid in native MON. Routing uses live Uniswap V3 pools on Monad. Tokens are discovered from real chain state rather than a fixed allow-list. Every step is built to fail honestly: an unavailable route is reported, not fabricated; a token that exists is not presented as tradable unless a real route and price exist.

Making a crypto payment is unreasonably hard for anyone who is not a trader. The recipient usually wants a specific token. The sender usually holds a different one. Bridging that gap by hand forces the sender to understand swapping, liquidity pools, routing, fee tiers, slippage, gas, token approvals and transaction construction.

• The recipient's need (“I need USDC”) and the sender's holdings (“I have MON”) are different problems.
• Swap interfaces optimise for trading, not for paying a specific person a specific value.
• A raw token list or hardcoded allow-list cannot represent the long tail of tokens deployed on a chain.
• Honest failure is rare: interfaces often imply a capability (any token, no gas, automatic conversion) that is not actually available.
• Users cannot tell whether a transaction will do what it claims until after they sign — and sometimes not even then.

The result is a payment experience with the complexity of a trading desk and the confidence of a guess.

Intent Pay inverts the flow. Instead of asking the user to construct a transaction, it asks what the user wants to happen and then does the engineering. Concretely:

1. Capture the intent. The user states a recipient, an amount, and the asset the recipient should receive — by form or in plain English.
2. Resolve reality. The app reads the wallet's real balances, prices the assets, and finds executable routes from the assets the user holds to the asset the recipient wants.
3. Choose the source deterministically. A deterministic engine picks the asset to spend, with a human-readable reason, and refuses when nothing is executable.
4. Prepare one protected transaction. The plan is constructed with an on-chain minimum output (or maximum input) so the recipient cannot be short-changed.
5. Review and authorize. The user sees the key numbers, expands advanced details only if they want to, and signs.
6. Verify delivery. After confirmation, the app proves the recipient's on-chain transfer against the bound the transaction enforced.

The guiding constraint is honesty. A feature is described as operational only when it has been implemented and, where the repository can demonstrate it, verified. Everything else is labelled as in progress or planned.

An intent is a statement of desired outcome, not a set of instructions. Intent Pay's intent captures:

• the recipient address;
• the asset the recipient should receive;
• the amount, and whether it is expressed in dollars or in token units;
• whether the amount describes what the recipient receives or what the sender spends;
• an optional explicit source asset, when the user genuinely chooses to spend a specific one.

The canonical intent is a single source of truth shared by the chat interface, the payment composer, the quote, the plan and the signing guard. There is no second copy of payment state, so the “top says one thing, composer says another” class of bug is structurally prevented.

Natural language is an additional interface, not a second payment system. A deterministic, offline parser is the authority: it must work with no AI provider configured, and it distinguishes the three amount forms on purpose —

• $10 → a dollar value, no asset chosen;
• 10 MON → a token quantity of MON the recipient should receive;
• $10 worth of MON → a dollar value denominated in MON.

An optional language model may only fill gaps the rules missed. It can never supply a price, a route, an address or a transaction, and its output is sanitized so unknown keys, addresses and prices are dropped. A name is never turned into an address: the address is only ever an explicit, validated 0x… value. When a critical field is missing, the engine asks one concise question at a time.

The user journey is intentionally short and Web2-shaped:

1. Connect a wallet.
2. Enter a payment request (form or natural language).
3. Review the interpreted request — recipient, asset, amount.
4. Confirm the recipient and amounts, and see the network fee.
5. Review the applicable route summary and any warnings.
6. Confirm and send.
7. Follow the real transaction status, ending in verified delivery.

Amounts are shown USD-first, with token amounts as secondary detail. The primary review shows only what a person needs to decide safely: recipient, what they receive, what the sender spends, the estimated network fee, any applicable fee, the exchange rate where a conversion occurs, and slippage or price-impact warnings. Advanced routing information — pools, fee tiers, intermediate tokens, the exact route — lives in an optional expandable section. Material fees and risks are never hidden behind that section.

The experience preserves the user's intent across recoverable errors. A moved price, a drained balance or an account switch produces a specific message and a retry, not a forced restart. Loading states are explicit while balances, prices and quotes are fetched, and duplicate submissions are prevented.

The system is layered so each concern can be reasoned about and tested in isolation. Layers are pure where possible; network access is confined to the server or the wallet client.

• Intent layer — lib/domain/intent.ts, lib/domain/validation.ts, lib/domain/canonicalIntent.ts. Defines the payment intent, its validation, and the single canonical state.
• Natural-language layer — lib/nlp/*. A deterministic parser, a state machine derived only from the structured draft, a question generator, an optional gap-filling LLM, and a handoff to the composer.
• Wallet / balances layer — lib/hooks/useWallet.ts, app/api/balances/route.ts. Reads the connected account and its real, on-chain-confirmed balances.
• Quote / routing layer — lib/providers/*, lib/server/quote.ts. Behind one interface (getRoutingProvider), a demo provider and the live Uniswap V3 provider. The UI never branches on which is active beyond the demo/live label.
• Construction layer — lib/execution/plan.ts, lib/execution/abis.ts. Turns a quote into explicit steps carrying real on-chain bounds.
• Execution layer — lib/execution/execute.ts. Submits the plan through the user's wallet and tracks step results.
• Verification layer — lib/execution/verify.ts. Proves the recipient's on-chain transfer from the confirmed receipt.
• Signing guard — lib/execution/signGuard.ts. The only path to a signature; re-validates everything from fresh data immediately before signing.

Tokens, chains and Uniswap deployments are configuration-driven (lib/config/tokens.ts, lib/config/chains.ts, lib/providers/constants.ts). No component or route hardcodes a token symbol.

Monad is the target network. Intent Pay is configured for Monad mainnet, chain id 143, and reads and writes real chain state through an RPC transport (an Alchemy Monad endpoint when a key is configured, otherwise the public Monad RPC).

Monad-specific properties the implementation accounts for:

• Fast finality. Monad reaches full finality after two blocks. Execution waits for full finality before verifying delivery, so the receipt it verifies from cannot be reorged.
• Deployed router shape. The Monad deployment of Uniswap SwapRouter02 exposes the deadline-less selectors — it has no deadline parameter. The implementation does not add one, because doing so changes the function selector and the call would revert. Quote freshness is enforced off-chain instead.
• No live private order flow. Monad has no globally available private mempool and no dapp-controllable private submission path. MEV protection is therefore reported as unavailable, and the app relies on on-chain slippage bounds, a price-impact guard and delivery verification instead of a cosmetic badge.

Token usability is modelled as a sequence of honest states rather than a boolean. A token that merely resolves is not presented as payable:

• UNKNOWN — could not be identified (no contract code, bad address).
• DISCOVERED — the contract exists and metadata resolved.
• PRICE_AVAILABLE / PRICE_UNAVAILABLE — a trustworthy USD price exists, or it does not (never shown as $0.00).
• ROUTE_AVAILABLE / ROUTE_UNAVAILABLE — a real route was probed and exists, or does not.
• PAYABLE — discovered, priced and routable.

A user can search by symbol, name, or contract address. An address is validated, its contract code is verified on Monad mainnet, and its metadata (decimals, symbol) is re-read from the contract before it can be spent. External metadata is never authoritative over what the contract reports. Two tokens sharing a symbol are kept distinct, and a name is only resolved when it maps unambiguously to a ticker.

Discoverability and executability are separate. A discovered token may support a direct transfer while having no swap route; in that case a direct transfer is allowed and a conversion is refused with a clear explanation. A direct transfer is never presented as a swap, and a swap is never presented as a direct transfer.

Routing uses live Uniswap V3 pools on Monad. The router supports exact-output and exact-input modes, discovers pools across fee tiers, and evaluates multi-hop candidates through basis tokens (including the native MON, pooled as WMON). The route chosen is the best available among the quotes actually evaluated — the app does not claim it is the globally optimal route. Selection weighs expected output, network cost, price impact, slippage and execution feasibility, and prefers the best net outcome rather than the largest gross number before fees.

Tokens are also assessed for execution risk using measurable facts — pool liquidity, a real transfer simulation, a live quote, and the route's price impact. A fact that could not be measured is reported as unknown, never as a failure, so a transient RPC error cannot present itself as a bad token.

Execution is the standard path through the user's own injected wallet (an externally owned account). The flow is:

1. Detect the connected wallet and the active network.
2. Confirm the wallet is on Monad mainnet.
3. Read the actual token balances.
4. Prepare the proposed transaction(s).
5. Estimate gas.
6. Display the required payment and network-fee information.
7. Validate recipient, token, amount and transaction details.
8. Request authorization from the wallet.
9. Submit through the supported wallet flow.
10. Verify the actual transaction receipt.
11. Show success only after successful execution is confirmed.

A payment is a single prepared transaction for a normal swap-or-transfer, or two protected legs when the user holds part of a requested token quantity and another funded asset covers the shortfall. Each swap leg carries its own on-chain bound.

Signing is gated by the signing guard, which is the only path to a signature. Immediately before signing it fetches fresh balances and a fresh quote, re-reads the canonical intent and the wallet account, re-checks freshness, price impact and balance/gas coverage, rebuilds the calldata from the fresh quote, and asserts the output bound. Any change aborts with a specific reason; calldata is never reused from an earlier build.

After confirmation, delivery is verified from the receipt against the minimum the transaction enforced. A reverted transaction is failed; an unprovable delivery is shown as unverified, never as success. The interface does not claim success merely because a wallet prompt closed, and it never automatically resubmits a transaction that may already have been broadcast.

Gas is always paid in native MON by the user's own wallet. There is no sponsored, ERC-20, or account-abstracted gas path in this application. An earlier EIP-7702 / paymaster-based ERC-20 gas experiment was removed because it could not be demonstrated to complete a real end-to-end payment with the target wallets on Monad.

A swap payment is several sequential transactions — typically an ERC-20 approval, the swap, and, when the output is native MON, an unwrap and a delivery transfer. Each transaction charges its own fee, so the app sums the network cost across the whole plan and checks the wallet covers that total before signing. Validating only one transaction's fee is what previously let a small payment be approved on a green fee and then fail at the next step with the node's "insufficient funds for gas". This is a fee affordability check, not a minimum transfer amount.

The review screen separates, where each is available:

• the amount delivered to the recipient;
• the amount spent by the sender;
• the swap or protocol fee embedded in the route (if any);
• the estimated network gas cost.

Intent Pay does not currently charge a service fee, and does not claim a guaranteed profit or that any fee would cover gas. Service-fee collection is a planned capability, not an operational one, and would be displayed before authorization if it were added.

The security model is that the transaction, not the interface, enforces the outcome. The product goal — an attacker cannot make the recipient receive drastically less while the app still reports success — is met by the following measures.

• On-chain output bound. Every swap step carries a real amountOutMinimum (exact-input) or amountInMaximum (exact-output), derived from a clamped slippage tolerance (default 0.5%, hard ceiling 5%). The signing guard refuses to sign a swap without a bound. The UI's “minimum received” figure is never the protection — the calldata is.
• Price-impact guard. A route whose live price impact exceeds the configured ceiling (default 3%) is blocked before signing. Slippage is never widened to rescue a bad route; an unmeasurable impact does not fabricate a number.
• Quote freshness. A quote is a live, perishable value (hard limit 20 seconds). A stale quote disables confirmation and is refreshed; a failed refresh keeps a last-known-good quote while it is still usable, so a transient provider error does not destroy the payment, and a definitive failure clears it honestly.
• Signing-time re-validation. The guard rebuilds everything from fresh data immediately before the wallet is asked to sign, and re-reads the intent a final time so a change during preparation aborts.
• Delivery verification. Success is reported only after the recipient's transfer is proven from the confirmed receipt against the enforced minimum.
• No fabricated state. The app never manufactures a quote, a liquidity figure, a price or a transaction hash. Demo mode is labelled and never produces a hash.

The user remains in control throughout: the wallet authorizes every transaction, the app never holds a key or a seed phrase, and no transaction is signed without the user's explicit approval of the exact prepared details.

This demonstrates Intent Pay's ability to execute a real payment using its on-chain payment flow.

This section separates what is covered by automated tests, what is implemented, and what is genuinely limited or still planned. It reflects the repository, not an aspiration.

Limitations. Gas is not abstracted. Cross-chain delivery is not supported. A route must exist and have liquidity; a token can be discovered without being tradable. MEV-protected submission is unavailable on Monad. A private submission endpoint cannot be forced onto an injected wallet, so the app does not fake an “active” badge.

In progress / planned. A service fee and its on-screen disclosure; broader live-network verification; and further UX refinement are planned (see section 13). None of these are presented as operational today.

The roadmap distinguishes work that is done from work that is planned. Dates are not promised here.

• Built. Intent model and canonical state; deterministic natural-language parsing; live Uniswap V3 routing and quoting; token discovery by symbol/name/address; token state and risk models; deterministic source selection; partial-balance split; protected plan construction; signing guard; delivery verification; the payment composer and review flow.
• In progress. Expanding live-network verification coverage; refining copy and error surfaces; and hardening mobile layouts.
• Planned. Transparent service-fee collection and disclosure; richer route comparison where more quote sources become available; and continued accessibility work.
• Explicitly out of scope. Reintroducing speculative gas-abstraction paths that cannot be demonstrated end-to-end.

• Paying a vendor who invoices in a stablecoin while holding a different asset.
• Sending a fixed value where the sender holds several assets and wants the best available one to be chosen automatically.
• Paying a specific token quantity (for example, “send 100 NEWCOIN”) where the wallet holds part of it and another asset covers the shortfall.
• Treasury-style outflows where predictable, reviewable transaction preparation and receipt verification matter more than trading.
• Any payment where the recipient's need should be authoritative and the sender's asset choice should be the app's problem.

These describe intended uses of the implemented capability. They are not claims about liquidity, safety, or commercial adoption of any particular token or counterparty.

Is Intent Pay a DEX or a swap interface? No. It is a payment application. Routing is machinery underneath; the user reviews and authorizes a payment.

Can I pay with any token? Any compatible token on Monad can be discovered and used when the wallet balance and a real execution path support the operation. A discovered token with no liquidity cannot be converted; a direct transfer may still work.

Do I need MON for gas? Yes. Gas is always paid in native MON by your wallet. There is no gasless or ERC-20 gas option.

Does Intent Pay charge a fee? No service fee is currently charged. Service-fee collection is planned and would be shown before authorization.

Can it send to another chain? No. Intent Pay is Monad-only. It is not a bridge.

How do I know the recipient got the funds? After the transaction confirms, the app verifies the recipient's transfer from the receipt against the on-chain minimum the transaction enforced.

Does the AI move my money? No. The deterministic engine and the signing guard govern execution. The AI only interprets a sentence, and can never supply a price, route, address or transaction.

Is the best route guaranteed? No. The app selects the best available route among the quotes it evaluated and says so.

Intent Pay demonstrates that an onchain payment can be as simple as a Web2 payment in the way it is described and reviewed, while remaining ruthlessly honest about what happens underneath. The hard part is not the interface; it is wiring real balances, real prices, real routes, real bounds and real receipt verification into a flow that never fabricates a result and never overstate a capability.

The current implementation delivers intent-driven payments on Monad with deterministic validation, protected execution, verified delivery, dynamic token discovery and honest failure. Gas is paid in MON; cross-chain delivery is out of scope; and features that are not finished are documented as such rather than implied to work.

For announcements and updates, follow the official Intent Pay account on X. For support, questions, or to report an issue, contact the team by email.