Bankr Console
Configure these at bankr.bot → Security. They apply to every surface — chat, agent, and API — because they're enforced at the broadcast chokepoint. Modifying them requires web (Privy) authentication; an API key cannot change them. If you've turned on MFA, a change that loosens a control also asks you to verify again with your passkey or authenticator app; one that only tightens (a lower limit, NFT transfers or contract calls off, pause) doesn't.
The Security page is split into three tabs — Transactions (the controls below), Response Channels, and MFA & Sessions.
Controls
These live on the Transactions tab. Response channels have their own tab and are covered separately.
| Control | Default | Effect |
|---|---|---|
| Pause all transactions | Off | Blocks every outbound transaction and signature until unpaused |
| Enable arbitrary contract calls | On | While off, blocks write_contract, submit_raw_transaction, deploy_contract, raw /wallet/submit, and signing typed data, transactions or 32-byte messages (/wallet/sign, sign_data). Named operations like swaps, and other messages such as logins, still work |
| Daily spending limit | $500 / 24h | Rejects any tx that pushes rolling-24h USD outflow past the limit |
| Per-transaction limit | $500 | Rejects any single tx priced above the limit |
| Permitted recipients | Off | Restricts transfers/swaps, a launch's fee recipient and fee-recipient hand-offs to an allowlist; new entries enter a cooldown. While on, signing (/wallet/sign, sign_data) accepts typed data only as a standard token permit or transfer authorization whose spender or recipient is on the list, and refuses transactions, 32-byte messages, orders, NFT listings and all other typed data, whose recipient can't be checked; plain messages still sign. Raw calls (/wallet/submit, write_contract, submit_raw_transaction) are checked on their to address only when they send native value; one that sends none isn't checked, because Bankr doesn't decode the recipient from calldata. Turn off arbitrary contract calls to block those |
| Price impact protection | On (15%) | Rejects swaps and order fills whose estimated price impact exceeds your max % — protects against thin pools that would fill far below market value |
| Allow NFT transfers | On, 5 / 24h | While off, blocks NFT sends, direct ERC-721/1155 transfer calls, operator approvals and NFT permits; while on, allows a set number (1 to 1,000) in any rolling 24 hours. Marketplace sales and revoked approvals aren't counted; NFTs moved inside a batch or smart-wallet call (multicall, Safe, ERC-7579) are |
USD limits accept 1 to 1,000,000. Setting 0 is rejected — disable the limit instead. Cooldown accepts 0 to 168 hours. Price impact accepts 1% to 100%.
Raw transactions and contract calls — /wallet/submit, write_contract, submit_raw_transaction — are valued by their native value only, and count toward the daily total like any other transaction. Tokens moved by calldata count as $0 and aren't checked against permitted recipients, which is what the arbitrary-contract-calls switch is for. A call that transfers an NFT (ERC-721 or ERC-1155), directly or inside a batch or smart-wallet call, or grants an operator approval over one (setApprovalForAll, an ERC-721 approve), still counts against Allow NFT transfers; approvals to the OpenSea conduits, Seaport 1.6 and Polymarket's CTF exchanges and adapters don't. Signing typed data, transactions or 32-byte messages (/wallet/sign, sign_data) is refused while arbitrary contract calls are off. While permitted recipients is on, signing refuses transactions, 32-byte messages and any typed data other than a standard token permit or transfer authorization (orders and NFT listings included), whose recipient can't be checked, and permits and authorizations to addresses not on the list.
Raw contract interactions work out of the box. If you don't use them, turning this off is a cheap way to shrink what a compromised session can do — named operations like swaps and transfers keep working either way.
Timers: turn a control off (or on) for a fixed window
Four of the controls above — plus response channels — take an optional timer, so a temporary loosening doesn't quietly become permanent. (Pause all transactions, permitted recipients and NFT transfers don't.) In every case the deadline is computed on the server — you pick a duration, not a timestamp — and the choices are 10 min, 30 min, 1 hour, 24 hours, or no timer at all.
The timer always runs on the less safe side of the toggle, and always resolves back toward the safe one:
| Control | Timer rides | When it lapses |
|---|---|---|
| Daily spending limit, per-transaction limit, price impact protection | turning the protection off | the protection turns itself back on |
| Enable arbitrary contract calls | turning the permission on | arbitrary contract calls switch back off |
| Response channels | turning a channel on | Bankr stops replying on that channel again |
Deadlines resolve at read time — there's no background sweeper and no delay. A lapsed timer can only restore a protection or revoke a permission; it can never turn a protection off or grant a permission you didn't ask for. Editing a control (toggling it, or changing its amount) replaces whatever timer was running, so you can't be left with a stale window you've forgotten about.
The Security page shows the running state inline — "Turns back on at …" while a protection is off on a timer, and "Turned back on at …" for a window that has already lapsed.
The toggle used to read "Disable arbitrary contract calls", off by default. It now reads "Enable arbitrary contract calls", on by default — the same behaviour (calls allowed until you say otherwise), stated the way round that matches the timer, which grants the permission for a window rather than suspending a protection. If you're calling the API, use PATCH /user/security/arbitrary-contract-calls with { enabled, durationMinutes? }.
Response channels
Response channels have their own tab on the Security page and control which platforms Bankr replies to you on. Every channel is on by default.
A row appears for each social account you've linked — X (Twitter), Farcaster, and Telegram. Turning one off stops Bankr replying to you there; your messages still land in chat history, so re-enabling the channel doesn't lose anything said in the meantime.
Telegram's /start and wallet-linking commands stay live regardless, so switching replies off can never lock you out of account management.
Pricing & fail-closed behavior
Bankr prices each transaction at submission time using on-chain quotes (0x for EVM, Jupiter for Solana). If pricing is unavailable and a USD limit is enabled, the transaction is rejected rather than waved through. Disable the limit if you need to proceed unpriced.
Recipient cooldown
Newly-added entries on the permitted-recipients list wait the configured cooldown (default 24h) before they're usable. Re-adding a previously-removed recipient restarts the cooldown. Your own EVM and Solana addresses are always implicitly allowed.
Spend tracking
Successful transactions are recorded in a per-wallet spend log, idempotent on transaction hash, so retries can't inflate the daily counter.
The limits cover every outflow, not only swaps and transfers: Polymarket bets (checked before any funding swap), x402 payments, LLM credit top-ups, Bankr Club sign-up, Hyperliquid deposits, Avantis opens (their USDC collateral), NFT collection offers, Glidepath deposits (from the token page or the agent), airdrops (whose total is checked against the limits before the first send, with every recipient held to Permitted recipients) and a launch's dev buy. A Club renewal counts toward the daily total but is never refused by a limit (a paused wallet still blocks it).
Limit, stop, DCA and TWAP orders are checked when you make them: an order whose every fill is above a limit is refused, and one whose fills won't all fit today gets a warning. Each fill's sell side is then priced and checked before it swaps. A fill refused for the daily limit waits until the rolling window has room (raising the limit releases it sooner); a limit or stop order refused for any other reason retries hourly, and a DCA or TWAP at its next scheduled run. Either way the order stays active, and Bankr tells you why, at most once a day per order and reason.
Example error messages
This transaction is $2,400.00, above your per-transaction limit of $500.
Adjust the limit or disable it in Security settings to proceed.
This transaction would push your 24-hour spending past the $500 limit you set in Security settings
(spent so far: $410.00, this transaction: $120.00).
Adjust the limit or disable it in Security settings to proceed.
0xabc... was added recently and is still in its safety cooldown period.
Available in ~12h. Adjust the cooldown in Security settings if needed.
Multi-factor authentication
Add a second factor to your account under bankr.bot → Security: a passkey (WebAuthn — Touch ID, Face ID, Windows Hello, or a hardware key), an authenticator app (Set up OTP, scan the QR code, then enter the app's 6-digit code), or both. An account can hold several passkeys and one authenticator app. Require MFA turns on by default when your first factor is a passkey — the passkey is verified as it's enabled, so you can't lock yourself out with a factor that doesn't work. An authenticator app doesn't turn it on; switch Require MFA on yourself once the app is set up (it asks for a code first). You can toggle it off anytime (this also asks you to verify).
Once MFA is on, it enforces two tiers:
- Login gate — signing in requires your passkey or a code from your authenticator app. A successful verification is remembered for 7 days per session, so you're not prompted on every visit. The Bankr CLI can't run a passkey in a terminal, so
bankr login emailhands you an approval link to verify in the browser instead; with an authenticator app you can also type its code in the terminal (CLI 0.3.45+). That approval is valid for five minutes only. - Per-operation step-up — loosening a Security setting, changing permitted recipients or response channels, adding or removing a factor, or disabling MFA each require a fresh verification (your passkey or a new authenticator code) at the moment you make the change.
Each authenticator code works once. Every five wrong codes lock the app's codes, for 15 minutes the first time and twice as long each time after, up to a day, until a right code resets the count; a passkey still works in the meantime.
Enforcement lives at the server, so it covers chat, the agent, and the API session alike — a leaked API key still can't touch these settings. You can manage your factors from the same Security page: name, add and remove passkeys, and set up or remove the authenticator app.
Bankr MFA is independent of your social login's MFA. Turn on both — see Secure Your Account. Even if your X account is compromised, an attacker without your second factor can't sign in to Bankr or loosen these settings.
Active sessions
The Security page lists every device signed in to your account — OS and browser, approximate location, IP, and last-seen time, with the current session marked. Log out any session you don't recognize; the logout takes effect server-side immediately, and if MFA is on, revoking another session asks you to verify with your passkey or authenticator app. Sessions drop off the list after 60 days of inactivity.
With MFA on, each session also shows whether it holds a login gate verification: MFA verified until the date it lapses, or No active MFA verification. A device shows the latter until it completes the MFA check and again once its verification lapses. A CLI login shows it once its five-minute approval ends, since the CLI then works from its API key.
Email logins from the Bankr CLI (bankr login email) are listed here alongside browser sessions and can be logged out the same way. Run bankr update first if you signed in with an older CLI — those sessions predate the change and won't appear.
Sign out of all clears every session at once — including the device you're on, so you'll be signed out here too. It's the right move when you suspect a compromise and don't want to work down the list one row at a time. The action takes two confirmations and, with MFA on, the same MFA step-up as revoking a single session.
Reviewing this list periodically is the fastest way to catch an unauthorized login — if you see a session you can't place, log it out and rotate any credentials that may have leaked.