Launch website boundary
The home page additionally reads official capabilities for a demonstration, with an explicitly illustrative user-entered balance. It validates the existing canonical schema, shows only supported returned actions, expires its data after 60 seconds, cancels overlapping requests, and fails closed on errors. No action price, real wallet balance, ETH quote, signature, or settlement is fabricated. Public IMD/Stockereum links do not imply an endorsed integration or authorize a token launch. The planned project token is not IMD and has no contract or tokenomics implementation here.
The public launch pages do not request wallet access or signatures. The preview uses visitor-entered illustrative amounts, never a fixed action price. /checkout is gated on the server by an explicit release flag and a nonzero configured address. This is a release safeguard rather than an audit attestation or authentication boundary; the existing proxy endpoints retain their own restrictions. Only an operator who has completed deployment, independent review, live acceptance, and hosting checks should enable it. English document pages use a fixed file catalog and server-rendered react-markdown with raw HTML skipped and the default URL safety transform retained. User-controlled file paths and executable Markdown/MDX are not supported.
Trust and custody
Fixed mainnet PoolManager, verified native ETH/IMD pool and token semantics are trusted dependencies. Hook and token bytecode match explorer-verified sources at the recorded block. Token is a non-proxy LayerZero OFT with inherited standard ERC20 transfers, no custom transfer tax/rebase override in inspected sources. Bridge mint/burn and owner-managed peer configuration remain external economic risks.
No router owner/admin, no upgrades, no generic execution or approvals. Mainnet addresses cannot be changed after compilation/deployment. Contract takes ETH only through purchase; no receive/fallback. IMD passes directly from PoolManager to recipient. Accidental ERC20 deposits / externally forced ETH cannot be recovered. Do not send them.
Non-trusted inputs
All public purchase arguments, caller/refund receiver and frontend API/RPC data are checked. Fixed chain and market; zero/self/manager recipient refused. Positive amount constrained to int128 maximum before signed conversion. msg.value must equal max input. Deadline inclusive. Negative input and exact positive output deltas required; settle amount and actual recipient delivery independently checked.
The router cannot guarantee that a recipient contract retains IMD forever after receipt. A caller contract receiving its refund may independently move its own tokens. Guaranteed delivery is measured before the caller refund; the router cannot prevent subsequent wallet actions. Standard IMD transfer itself has no receiver callback.
Refund and reentrancy
refund = msg.value - verifiedEthSpent, never address(this).balance. Caller-only empty-data transfer; revert on rejection. OpenZeppelin guard covers the entire purchase including refund. Callback requires fixed manager, active guard and the current context hash; delete authorization before external swap. Replay, altered context, outside-operation callback and refund reentry are tested.
Slippage, deadline and MEV
The max input caps exchange expenditure, including POOL4 fee, excluding gas. No partial success: deficient output or excess cost reverts swap/hook/transfers. Minimum sqrt limit is not a price guarantee; output and max-input conditions are. An attacker can worsen execution within allowed tolerance. Use a modest tolerance and short deadline; private submission may reduce public-mempool exposure but is not implemented. Block timestamps are used only for expiry.
External availability
POOL4 owner may close the market and withdraw liquidity; cannot be repaired by this ownerless router. The hook may revert. Token/bridge, RPC, API or frontend outage can prevent completion. Buying IMD and paying IdentityMD are separate transactions; quote expiry after a successful purchase leaves IMD in the user's wallet, not stranded in this router. A reverted real transaction still costs gas.
Static analysis
Slither 0.11.3 ran all 100 detectors without exclusions, analyzing 21 contracts. Initial 66 results; its medium unused settlement return was fixed with a matching-value check and regression test. Final: 65 results: 3 High, 22 Medium, 1 Low, 39 Informational. These are analyzer classifications, not confirmed exploit severities.
Every result and disposition appears in STATIC_ANALYSIS.md, with unmodified JSON and logs in evidence. The High caller-refund warning is a false positive: target is caller, value is its own unused funding, reentrancy is blocked. The two High shift warnings are in imported Uniswap BitMath assembly not reachable from the router. The 22 Medium arithmetic warnings are upstream fixed-point/tick/ABI-buffer rounding routines not called by this router. Only TickMath's constant and BalanceDelta accessors are used. We did not alter upstream math to silence warnings.
Accepted Low timestamp warning: expiry necessarily uses block time; equality/expiration tests cover boundaries. Informational warnings cover upstream assembly/constants, unused helpers, compatible pragma ranges, complexity and the deliberate empty-data refund call. Actual compiler is pinned to 0.8.26. Review current compiler advisories again before deployment.
Foundry lint additionally flags casts, refund call, event placement, temporary callback authorization and guard-related external calls. Signed casts are bounded/checked before conversion; input negation is widened to int256 to handle int128 minimum. The guard is entered by the modifier before any external call and remains entered until after refund/event. Callback authorization is per-call state, not an administrative permission requiring a governance event. No warnings were silently suppressed.
Web deployment
Server proxy has fixed destinations, method/path allowlists, size limits, timeouts and a bounded per-process request budget. The latter limits resource abuse, not distributed denial of service; configure edge limits for public hosting. No private key, seed phrase or server signing function. Production operator must verify deployed bytecode, not merely trust getters or a frontend environment address; a malicious contract can imitate getters.
No independent audit or funded end-to-end acceptance was performed. No live readiness claim is made.
job.open milestone safety
Checkout defaults to safe preparation. IMD_PAYMENT_SUBMISSION_ENABLED must be explicitly true on the server, alongside the swap release gate, to forward any signed payment. The backend never signs. Each wallet operation checks Ethereum, the selected original payer and the original payer identity. The swap additionally requires the reviewed runtime code hash. Payment preparation, exact allowance, two signatures and final submission are separate commands. Full quotes, canonical input hashes, Permit2 fields and both stored signatures are validated. The SDK window is not shortened to fit an old quote.
A cancelled pre-submission payment leaves acquired IMD in the wallet, but gas and market fees remain spent. A response lost after signed submission is ambiguous; never promise that no payment occurred. Saved bytes/order IDs are retained, no new permit is automatically generated, and the operator must reconcile status. Receipt timeouts retain hashes; confirmed reverts clear the pending transaction. Account changes invalidate progression. Session storage is not a secure vault against XSS; do not expose bearer credentials or signed payloads.
Slither was rerun for this milestone: 65 identical findings (3 High, 22 Medium, 1 Low, 39 Informational), compared by detector, severity and full description. Existing dispositions were reviewed against unchanged router code and refreshed tests. The refund-to-caller High is constrained by exact accounting and nonReentrant; dependency assembly/math findings are documented in STATIC_ANALYSIS.md. No independent audit or live paid acceptance has occurred.
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.