Two-factor on converts, payouts and the house

Instant Convert never invents its own second factor. It uses the platform's shared step-up engine under three separate domains, each with its own policy, its own codes and its own attempt counter, so a code minted to approve one kind of action can never approve another.

On a balance convert: optional

A balance convert moves nothing off the platform, so by default it asks for no second factor. Switch Require two-factor for converts on and every balance convert asks for one before it executes: the button reads Verify and convert and opens the dialog.

• A user with an authenticator app types the current six-digit code (or a recovery code) into the dialog; nothing is sent to them.
• A user whose factor is email or SMS has nothing to type until a code is sent. Opening the dialog sends one through POST /api/convert/verification/send, and Resend code offers another after 30 seconds.
• Either way the code is checked first, through POST /api/convert/verification/verify, and the convert then carries the single-use token that check minted.
• Five wrong codes in ten minutes lock the user out of this domain for the rest of the window. The counter belongs to the convert domain alone.

A code that arrives after the price

The dialog covers the review, so it repeats the price's countdown under the convert it confirms (Price held for 7 seconds). An emailed code often takes longer than the default ten-second hold. Once the price has run out, the dialog says This price has expired. You will confirm a new one after your code. The code is still checked; the dialog then fetches a new price for the same convert, shows it with Code verified. Confirm a new price to finish. and a fresh countdown, and Confirm new price executes it with the token the code already minted. The server refuses an expired price before it spends that token, and the dialog keeps the token for its ten-minute life, so no second code is sent. Once that life is over, the dialog says Your verification has expired. Enter a new code.

If the setting is on but two-factor is disabled platform-wide, or none of the accepted methods is available, the requirement is ignored rather than blocking every convert, and the backend log says so. A user who has not enrolled a factor at all is refused with Converting requires two-factor authentication. Enable … 2FA in your profile security settings, then convert.

On every payout: the withdrawal policy

A Convert & Send or a convert-and-withdraw moves value off the platform, so it runs the withdrawal two-factor policy (withdrawTwoFactorChallenge and the method switches beside it), exactly as a withdrawal does. The dialog is titled Confirm this payout, its button reads Verify and send (or Verify and withdraw), and its code comes from the withdrawal verification endpoints (POST /api/finance/withdraw/verification sends an email or SMS code, POST /api/finance/withdraw/verification/verify checks it). A late code works as above: the payout is re-quoted in the dialog for one Confirm new price.

One code is never asked for twice. When the withdrawal policy demands a code, that code covers the convert too. When it does not, the optional convert policy above applies to the payout like to any convert.

On the house page: mandatory

Every action on the Instant Convert house page needs a fresh second factor from the admin doing it: defunding the house, changing the kill switches, confirming or reversing a Send, resolving a hedge or a movement. The page is opened with House inventory on Finance → Transaction Management → Pool Backing (/admin/finance/pool-backing/house). The code is bound to one action on one target: a code confirmed for defunding 100 USDT cannot defund 101, or reverse a Send.

This domain does not fail open. With two-factor disabled platform-wide, the house page refuses every action until it is switched back on: house money is never moved on a password alone. An admin with no factor enrolled is told to enable one in their profile security settings first. See The house page.