**## Why** Zycord Mercato (testnet: https://zycord.dcafrevolution.com/app/, code: https://gitlab.com/dario/zycord-mercato) is an exchange on the cEVM whose pool and order book are served by a registered sequencer. Every operation that reads the pool or the book exactly is an intent. Site connections sign \`transfer\`, \`call\` and \`deploy\`, so the page can read everything but has to hand the user a \`zcd wallet intent …\` command to paste into a terminal. This issue proposes an \`intent\` kind so a connected page can ask the wallet to quote, sign and hand an intent to the contract's sequencer, with the person approving on the wallet's own screen. **## Proposed request body** Same envelope as today (\`kind\`, \`origin\`, \`id\`, \`expires\`, \`mode\`), with \`kind: "intent"\` and \`mode\` restricted to \`submit\`: | field | meaning | checks | |---|---|---| | \`target\` | the sequenced contract | must have a registered sequencer key (\`/sequencer\`); refused otherwise | | \`calldata\`, \`enters\`, \`blobs\` | as for \`call\` | same checks as \`checkCall\` | | \`bounds\` | list of \`{kind, cell, amount}\` (\`delta-at-least\`, \`delta-at-most\`, \`final-at-least\`, \`final-at-most\`; cell \`storage:CONTRACT:KEY\`, \`balance:ADDR\`, \`cell:ADDR:WORD\`) | same parser as \`zcd wallet intent --bound\`; at least one must name a cell the call writes, as the CLI already requires | | \`max_payment\` | the most the person agrees to pay all sequencers, in drops | required; the quote must be ≤ it | | \`window\` | blocks, optional | capped at \`MaxIntentLead\` | | \`fallback\` | optional \`{max_payment}\` | if present, the wallet may take the forced path with the same payers, as \`--fallback\` does | \ No \`value\` (an intent carries none). No \`sequencer_url\` field in the first version: the wallet finds the sequencer only through the on-chain directory entry of the key registered on \`target\`, exactly as \`zcd wallet intent\` does without \`--sequencer-url\`. A page cannot point the wallet at an endpoint of its choosing. **## What the approval screen shows** Everything comes from the wallet's own derivation against its own node and from the quote the wallet itself fetched: \- origin and connection (as for \`call\`); \- target, the function selector and, when the contract is in the compiled-in table, its name; \- the bounds, in words ("your cell X at Mercato rises by at least N"); \- the sequencer: address, display name and URL from its signed manifest, the directory entry the URL came from, the key registered on the contract; \- the quote: leader price, each co-sequencer's payment, the total, \`valid_until\`; \- the payers: how many one-shot cells are spent, their total, the change and the fresh one-shot it goes to; \- the maximum spend: the total in drops and \`max_payment\` side by side, refused if the total is above; \- the window (not before / TTL) and, if requested, the forced-path fallback and its cap. Approval binds to what was shown, like \`ErrPreviewChanged\` for certificates: the wallet keeps the quote id and the total from the preview; at signing time \`Session.Intent\` re-quotes, and a different quote id or a total above the shown one refuses with a "changed since you approved" error. The person approves again. **## Sequencer URL and netguard** The URL is never taken from the page. It is read from the directory (\`/directory?keys=…\`) for the key registered on \`target\`, and before any connection it goes through the same checks as an \`src=\` fetch: https only, ASCII host, a \`.onion\` host only with a configured Tor proxy, \`HostAllowed\` before dialling and on the resolved address, no redirects, \`netguard.Transport\` for the request. Unlike \`secureEndpoint\` for the CLI, a request coming from a page does not get the plain-http-on-loopback exception: a sequencer announced on loopback or on a private address is refused. Co-sequencer endpoints named by a quote get the same treatment. Today \`zsi.NewClient\` uses a plain \`http.Client\` and \`ResolveSequencer\` only checks the scheme; this change would route both through netguard, which also hardens the CLI path. **## What a hostile page can and cannot do** Can: \- put an intent in front of the person, like it can put a \`call\` today; the person sees the target, the bounds, the sequencer and the price, and decides; \- learn the outcome of a request it made (\`signed\`/\`rejected\`/\`expired\`, the intent id), as for \`call\`; \- make the wallet contact the sequencer registered on a contract the page names (a directory lookup and a quote), once per request, within the existing rate limit (one pending request, ten a minute). Cannot: \- choose the sequencer endpoint (directory only), nor make the wallet dial a private or loopback address; \- learn the wallet's addresses: the answer carries the intent id, not the payers or the change address (the intent itself reveals its payers on chain once applied, as any intent does); \- spend more than \`max_payment\`, or have the wallet sign a quote different from the one approved; \- sign without the screen: no auto-approve, same as \`call\`; \- pick which one-shots pay. Open points we would like your view on: whether the answer should include the payers (useful for a page that follows the intent) or keep them private; whether \`fallback\` belongs in the first version; whether a page should be allowed to name a co-sequencer set or only take the one in the quote. **## Tests we would add** \`request\` (shape, mode, bounds parsing, refused fields), \`webui/request\` (preview with a quote from a fake sequencer, binding on quote id and total, approval and held answer), \`webui/connect\` (intent over \`/v1/sign\`), guard tests for a directory URL on a private address (pattern of \`request/guard_test.go\`), and a CLI regression for \`ResolveSequencer\` through netguard. Docs: a paragraph in OPERATING "Site connections". Estimated size: 700-800 lines across \`wallet/request\`, \`wallet/webui\`, \`wallet/zsi\`, \`wallet/session\`, docs and tests. Written with Claude (Anthropic); I review it and will maintain the MR.