Developer Mode

Copy page

🎯 Goal

Go beyond the built-in operations: have your Agent preview and execute contract calls you construct yourself, and produce EIP-712 typed-data signatures — with simulation, risk checks and an explicit confirmation step in front of every action.

✅ Prerequisites

• Agentic Wallet installed and signed in.
• Developer Mode enabled in the Binance App. It cannot be switched on by the Agent, by the CLI, or from the web — this is deliberate.

Check the current state before you try anything else:

"Is Developer Mode enabled on my wallet?"

Code
baw wallet settings --json

Look for devMode.enabled. If it is false, enable it in Binance App → Agentic Wallet management page → Settings, then ask again. Four fields are worth reading before you script anything:

Field	Meaning
devMode.enabled	Whether external signing is currently allowed at all
devMode.expiresAt	When Developer Mode lapses (Unix seconds); null when disabled or expired
devMode.dailyLimit	The external-sign spend cap for a 24-hour period
developerModeQuotaUsed	How much of that cap has already been consumed today

This quota is its own pool. Developer Mode spending is independent of your main dailyLimit, and of the prediction, DeFi and x402 quotas — it neither consumes them nor is capped by them. Read developerModeQuotaUsed for Developer Mode usage, never defiQuotaUsed or quotaUsed.

---

What Developer Mode does and does not change

By default, Agentic Wallet performs only capabilities that have been verified end to end — swap, transfer, limit order, prediction market, tokenized securities, DeFi — and does not sign or initiate arbitrary transactions. That is a security decision rather than a missing feature; see Verified Capabilities Only for the reasoning.

Developer Mode is the one exception, and it is deliberately narrow.

What enabling it adds:

• Arbitrary contract calls you construct — EVM to + calldata, or a Solana unsigned transaction.
• EIP-712 typed-data signatures for payloads you build yourself, such as Permit and Permit2.

What does not move:

Boundary	Still applies
A separate spend cap	External signing draws on its own Developer Mode daily limit, set in the App
Time-boxed access	Developer Mode expires — devMode.expiresAt — and must be re-enabled in the App
Risk interception	Operations assessed as high risk are blocked outright, before you can confirm them
Private key custody	Keys are MPC keyless and cannot be exported — there is no way to sign outside the wallet
Two-step confirmation	Every contract call and signature requires a preview and an explicit confirmation

The enable switch lives in the Binance App only — an Agent cannot turn Developer Mode on for itself, which is why the prerequisite check above matters before you script anything against it.

---

Supported signature types

Developer Mode widens what the Agent can do, but it does not lower the security floor. Message signing stays restricted to structured data that can be parsed and shown to you before you approve it:

Signature type	Method	Supported
EIP-712 typed data	eth_signTypedData_v4	✅ Yes
EIP-191 personal message	personal_sign / eth_sign	❌ Not supported

sign-message accepts --signType EIP712 only, and --message must be a full eth_signTypedData_v4 JSON-RPC request — not a plain string and not a pre-hashed digest.

Why typed data only. EIP-712 carries its own schema — domain, types, and the exact values being authorised — so a preview can show you the spender, amounts and deadlines you are actually granting. An EIP-191 plain-text message carries no structure at all: neither you nor the Agent can verify what the resulting signature will be used for, which is exactly the property blind-signing attacks rely on. Since an Agent signs without a human inspecting every payload, that class of request is not permitted.

What this means in practice

A large number of third-party flows ask you to sign a plain text message rather than structured typed data. Common examples:

• "Sign in with Ethereum" style logins and dApp session authentication
• Airdrop, reward or points claim flows that verify address ownership by signing a sentence
• Allowlist or campaign registrations

All of these use EIP-191 personal_sign, and they cannot be completed with an Agentic Wallet. This applies even when the activity that earned the reward was itself performed through Agentic Wallet — for example, supplying liquidity or staking through the DeFi flows, and later being asked to sign a message to claim a distribution from that protocol.

Because keys cannot be exported, the signature cannot be produced elsewhere with the same address either.

---

The two-step safety flow

Every Developer Mode operation is deliberately split in two. The Agent will:

1. Run preview — parses the operation, simulates it, and returns risk information.
2. Show you the parsed transaction or message, any risks, and any authority being granted.
3. Wait for your explicit confirmation.
4. Run execute, using the requestId from that preview.

A preview that returns an error produces no requestId and cannot be executed. Previews also expire — if execute reports an expired preview, simply preview again.

---

Contract calls

"Preview a contract call to 0xTargetContract on BSC with this calldata"

Code
baw contract-call preview \
  --binanceChainId 56 \
  --from 0xYourAgentWallet \
  --to 0xTargetContract \
  --value 0 \
  --inputData 0x... \
  --json

Parameter	Required	Description
--binanceChainId	Yes	For example 56 (BSC), 1 (Ethereum), CT_501 (Solana)
--from	Yes	Your Agentic Wallet address on that chain — ownership is verified server-side
--to	EVM	Target contract address
--value	No	Native value in wei, not human-readable. Integers only; decimals rejected
--inputData	No	EVM calldata, defaults to 0x
--unsignedTx	Solana	Base58-encoded unsigned transaction, used instead of --to / --inputData
--gasLimit	No	EVM only. An integer from 21000 to 15000000. Omit it and the backend estimates

Leave gas alone by default. contract-call accepts no gas price and no gas option. Preview simulates the call, and the backend estimates the gas limit.

Setting your own gas limit. --gasLimit is an advanced fallback rather than part of the normal flow — pass it only when you specifically want a ceiling. It is a cap, not a bypass:

• The call is still simulated, with your value as the ceiling. If it passes, that exact value goes on chain — no buffer is added.
• If the call needs more gas than the cap, preview fails rather than letting the transaction run out of gas after broadcast. Raise the value and preview again.
• Pass it on preview only. execute takes just the requestId and reuses the value from that preview.
• EVM only — passing it on Solana is rejected, as is any value outside the range above.

Then execute with the returned requestId:

Code
baw contract-call execute --requestId a1b2c3d4... --json

Reading the result:

• status: BROADCASTED — signed and submitted; use the returned txHash to track it on-chain.
• status: PENDING_CONFIRMATION — you must approve in the Binance App before it completes.
• requireConfirmation in the preview tells you in advance which of the two to expect.
• parsedTx.amount is in the smallest unit. Divide by the token's decimals from tokenInfos before reading it as a human amount.

If the preview is intercepted, it returns an error and no requestId — the operation was assessed as high risk and stopped before you could confirm it. There is nothing to execute in that case; the error body carries the reason.

---

Signing messages

"Preview this EIP-712 signature request"

Code
baw sign-message preview \
  --binanceChainId 1 \
  --signType EIP712 \
  --message '{"method":"eth_signTypedData_v4","params":["0xYourAgentWallet","{\"domain\":{...},\"primaryType\":\"Permit\",\"types\":{...},\"message\":{...}}"]}' \
  --json

params[0] must be your own Agentic Wallet address; params[1] is the EIP-712 typed data (domain, types, primaryType, message) as a JSON string.

Code
baw sign-message execute --requestId e5f6g7h8... --json

On success you get status: COMPLETED with signature and signatureRecovery. If it returns PENDING_CONFIRMATION, approve in the App and then fetch the result:

Code
baw sign-message result --order-id msg-order-xxx --json

REJECTED or EXPIRED means no signature will be produced.

Permit and Permit2: these grant spending authority, not just a signature. Before confirming, read the spender, sigDeadline and each entry in details[] (token, amount, expiration) from parsedMessage — that is exactly what you are authorising.

---

Signature history

"Show me my recent message signatures"

Code
baw sign-message history --binanceChainId 56 --limit 50 --json

Returns past signatures with signatureTime, messageType, and for Permit-style messages the spenderAddress, tokenPermits and signatureDeadline. Use it to audit what authority your wallet has granted over time. See also Security & Settings for reviewing and revoking approvals.

---

What's next

• Security & Settings — daily limit, token scope, approvals
• Automated Strategies — combine Skills into end-to-end automation
• Skills Reference — full capability reference