Presentation layer
The redesigned home page also includes a read-only live demo: LiveExperience.tsx retrieves capabilities through the existing proxy and live-demo.ts validates the response before exposing supported job/workflow/oracle requirements. The visitor's example balance is not a wallet read. Data is cleared after 60 seconds or on request failure; refreshing never requests a quote, signature, swap, or paid submission. A separate planned Stockereum project token has no runtime or contract integration in V1. See VISUAL_REDESIGN.md.
IMD Flow is the English launch identity. / explains the product, /preview calculates illustrative shortfalls using visitor-entered amounts without wallet access, and /docs exposes a fixed catalog of English documents. The English Checkout.tsx view is mounted by /checkout even in safe mode. Swap authorization requires the operator release flag, valid address, reviewed runtime code hash, configuration checks and simulation. A separate server flag enables signed payment submission. No flag creates an automatic transaction. Providers are loaded only for checkout, not for the presentation pages.
Boundary
sequenceDiagram
participant U as User wallet
participant F as Next.js UI
participant A as Same-origin API proxy
participant I as IdentityMD
participant R as IMD router
participant P as PoolManager + POOL4 hook
F->>A: capabilities / check / quote
A->>I: Fixed allowlisted API routes
I-->>F: Current quote and prepared input
F->>U: Read IMD balance
F->>P: Simulate exact-output quote
U->>R: Explicit ETH purchase confirmation
R->>P: unlock / swap exact output / settle ETH
P->>U: Take exact IMD directly to wallet
R->>U: Refund unused ETH
F->>I: Empty submit through proxy; 402 challenge
U->>U: Exact allowance if needed, Permit2 + QuoteApproval
F->>I: Same-origin proxy submits signed payment
I-->>F: Settlement / admission status
The frontend fetches amounts; the contract handles amounts only. No direct payTo transfer. Next.js is required for same-origin pass-through because official paid endpoints restrict browser CORS. The server has no wallet signer, wallet key, token custody, signing method or broadcast method.
Router decisions
Direct IPoolManager integration avoids generic Universal Router commands. amountSpecified > 0 is v4 exact output. Fixed zeroForOne=true, fixed verified PoolKey, empty hookData. TickMath.MIN_SQRT_PRICE+1 permits the swap to traverse liquidity; output equality and maximum ETH enforce the economic constraints even if the price boundary stops a partial fill. There is no WETH leg.
The callback is bound to a hash of this operation, the fixed PoolManager and an active ReentrancyGuard. Its authorization is consumed before swap. Input delta must be negative and output delta positive and exactly requested. Settlement's returned amount must equal the sent ETH. PoolManager transfers directly to recipient. A second independent recipient balance check detects discrepancies in actual delivery.
Only this call's msg.value funds settlement and refund. Prior ETH is ignored. Refund uses empty calldata to caller and failure reverts everything. The public purchase guard remains active throughout refund. External Uniswap errors bubble with their original diagnostic content.
SafeERC20 is unnecessary in this router: it never calls ERC20 transfer/approve. The official PoolManager handles token delivery; IERC20 is used solely for balance reads. This reduces token-custody and allowance surfaces.
Frontend decisions
Next.js 16.3.8 / TypeScript / wagmi 3.7.7 / viem 2.57.3. Exact-output official Quoter simulation; integer-only amount arithmetic and upward rounding for ETH tolerance. The displayed estimate expires after 30 seconds. Recheck current balance and configured contract, simulate purchase, then ask wallet to transact. Wait for two confirmations and verify the balance increase.
State is tied to account and saved quote; account/network changes invalidate estimates. Prepared IdentityMD input is shown for review before payment. Only job.open is supported, initially an explicit research-report input. The entire saved quote and prepared input hash are validated. Existing IMD bypasses purchase.
All transaction/signature paths start from an explicit button. The wallet itself confirms each operation. Status checks are manual and read-only; timers never submit or re-sign payments. A page reload can recover the order and already signed bytes within the same browser session.
Fixed configuration
See EXEC_PLAN.md, src/libraries/MainnetConfig.sol and evidence/chain.json. The latter binds values to block 26125254 and records block hash, code hashes and matching explorer-verified bytecode for IMD and hook. PoolKey hash is recomputed independently. These observations are a snapshot, not a promise of future liquidity.
Explicit job state machine
job-flow.ts centralizes transitions and account-bound recovery. imd-client.ts verifies live schemas and job-only requests. job-wallet.ts supplies connected-wallet transactions; payment-window.ts validates the full SDK window. A successful swap stops at imd_acquired; preparing the challenge reaches awaiting_payment_signature; signing stops there too. A separate confirmation submits the exact signed bytes. See JOB_OPEN_MILESTONE.md for the complete graph and executed local integration evidence.
ETH-first checkout presentation
The checkout presents “Pay with ETH” as funding a job. ETH estimates, maximum input and slippage stay visible; IMD balances and settlement details are available in expandable sections. Existing IMD reduces the required purchase, potentially to zero. The purchase still requires wallet confirmation, and a separate payment authorization and submission starts the job. This wording does not introduce native-ETH IdentityMD settlement, gas subsidies or automatic signatures. Safe-mode restrictions remain unchanged.
Confirmed job admission now permits an explicit new order with a fresh request key and cleared payment signatures. Unresolved submitted payments still block reset. A status refresh after admission is supported. These controls do not activate mainnet deployment or spending.
Mainnet deployment update — 2026-10-05
The user confirmed deployment from 0xFC2D201c44b18E85eD39fbF9FD098B4c3D7BaD14. Router: 0xf476a72f0e4d31f1cbaaa629a550cd982bab8d26, Ethereum chain 1, block 26128548. Transaction: 0x87123526b82e77b89d95850807696df2690b6aa59a7f2aac0108deb571ee97bf. Gas paid: 0.000255657297530583 ETH.
Creation input matches the compiled artifact exactly. Runtime instructions and all immutable values match the compiled router and expected market configuration. Runtime hash: 0x50eb37a199fe108bdd0dc0ae8f37d0cc82ea0a62eb8d84f16d5219a060bc66ee. A fork-only simulated purchase using the deployed address passed at block 26128559. Evidence: deployment/mainnet-verification.json. This supersedes earlier statements that the router is undeployed. It is not explorer source verification or an independent audit.
Production configuration is being connected to this deployment with the runtime hash pinned. Wallet confirmation and separate payment submission remain mandatory. No live swap or paid job acceptance has been verified. The next step is a user-confirmed first transaction and settlement, following docs/LIVE_IMD_TEST.md. Deployment alone does not establish successful end-to-end job payment.
Wallet account-code restriction removed — 2026-10-05
The checkout no longer rejects a payer solely because eth_getCode returns contract code, including EIP-7702 delegation. Ethereum chain and connected-payer checks remain mandatory. Router runtime hash, amount, recipient, expiry, allowance and both signature validations are unchanged. This removes the observed local blocker; it does not certify every smart wallet or guarantee IdentityMD acceptance. Current payment validation still requires recoverable 65-byte signatures for the same payer. Arbitrary ERC-1271-only or counterfactual account signatures are not newly implemented. Reuse existing IMD: obtain a fresh quote and refresh the balance before any additional purchase.
Checkout permission clarity
The checkout shows the live quoted IMD amount, Permit2 approval address and x402 spender. Approval is shown only when the allowance is insufficient; signing is shown when sufficient. Final submission remains a separate explicit action. Provider rejection code 4001 now gives cancellation and order-recovery advice without automatic retries. Wallet risk alerts are not suppressed. The reported Blockaid risky-spender classification remains unresolved; matching a canonical address does not prove an alert incorrect.
Visible job progress
Accepted orders display a JobResult card with manual read-only refresh, objective, execution state and available artifact links. Payment controls are hidden after admission. /jobs/{id} supports bookmarking a public job. The proxy permits only GET jobs/{id} and jobs/{id}/result and does not forward order bearer credentials to those public routes. Result links are restricted to HTTPS api.imd.fun/artifacts/{64-hex-hash}. Completion is distinct from admission and does not imply independent factual verification. Failed reads never trigger payment or job creation.
Reports open inline through a read-only, fixed-origin /api/report/{hash} proxy (64 KiB limit, no redirects or credentials). Markdown is rendered without raw HTML or remote images; citation links permit HTTPS only. This view does not download files or initiate payments.
Job work selection
The checkout supports research-report, build-contract-project and template audit through job.open. Audit requires a public GitHub repository and a pinned 40-character commit. Live check/quote validation remains required. No deployment or GitHub publishing is requested. A strict input union prevents mixing job types or injecting unsupported model fields. Existing research drafts remain compatible. The live documentation does not expose model selection for paid jobs: the AI model control accurately shows Automatic, managed by IdentityMD. Code and audit execution have not been paid or verified end-to-end; free prechecks validated research/code and rejected an invalid audit revision. Code source browsing and the separate audit report endpoint are not yet implemented in the result reader.