FastMint FCFS: Execute Time-Critical BSC Mints with Binance Agentic Wallet

What fastmint-fcfs does

fastmint-fcfs is a skill for AI agents such as Claude Code, Codex, Cursor, and OpenClaw. It helps execute a single mint, claim, or buy transaction on BNB Smart Chain as soon as a sale opens.

The tool uses the Binance Agentic Wallet baw CLI. Your machine prepares calldata and chooses when to submit the request, while transaction signing occurs in Binance's backend through Developer Mode. A private key, seed phrase, or session token is not stored on the machine.

Because Binance's wallet flow requires a contract-call preview followed by contract-call execute, fastmint-fcfs optimizes the timing around those steps. It uses several independent triggers instead of waiting for one signal:

• Clock trigger: fires at the sale time using an NTP-corrected clock.
• Head trigger: watches for the first BSC block whose timestamp reaches the opening time.
• Simulation trigger: races eth_call requests across the fastest available RPC endpoints.

The first successful preview is executed exactly once. Other previews that are still running are ignored.

Use this tool only after an explicit user instruction for the specific mint. A URL alone is not authorization to send a transaction.

Prerequisites and installation

Install the required software

Use Node.js 20 or newer. The repository bundles ethers 6.13, so the project itself does not require npm install. Install the Binance Agentic Wallet CLI globally:

npm install -g @binance/agentic-wallet@1.12.0

In the Binance App, enable Agentic Wallet and Developer Mode. Ensure the wallet balance remains below the Developer Mode cap. The optional Binance wallet skill can provide additional wallet-operation support.

Place the skill where your agent can read it

Extract the repository and copy the fastmint-fcfs directory into the skill directory used by your agent:

# Claude Code, per project
mkdir -p .claude/skills
cp -r fastmint-fcfs .claude/skills/

# Claude Code, globally
mkdir -p ~/.claude/skills
cp -r fastmint-fcfs ~/.claude/skills/

# Codex, Cursor, or other .agents-compatible tools
mkdir -p .agents/skills
cp -r fastmint-fcfs .agents/skills/

chmod +x fastmint-fcfs/fastmint.sh

Sign in to the wallet

Sign in once from the terminal:

baw auth signin --json

Open the returned urlForWeb, match the displayed pairingCode in the Binance App, and approve the connection. Then verify the session:

baw auth verify --qrCodeId <qrCodeId> --json
baw wallet status --json

The wallet status must be CONNECTED. Sessions last up to 48 hours of inactivity. If the session expires, the agent must stop and ask you to sign in again rather than attempting authentication automatically.

Check the environment

Change into the project directory and run the read-only benchmark:

cd fastmint-fcfs
./fastmint.sh bench

The benchmark checks the RPC ranking, WebSocket delay, NTP clock offset, wallet connection, Developer Mode, BNB balance, Agent ID, and preview timing. It is a useful first diagnostic before scheduling a mint.

If Node cannot validate a certificate chain on macOS, the project can build a CA bundle from the system keychain:

./fastmint.sh bench --ca

For other environments, set NODE_EXTRA_CA_CERTS to a suitable CA file.

Configure optional RPC endpoints

The launcher automatically sources the .env file in the skill directory. You can add premium HTTP and WebSocket endpoints:

FASTMINT_RPCS_EXTRA=https://<premium-endpoint>
FASTMINT_WS_EXTRA=wss://<premium-endpoint>

Other supported settings include FASTMINT_RPCS to replace the entire RPC pool, FASTMINT_WS to set the WebSocket endpoint, FASTMINT_TZ for the local time zone, and FASTMINT_CA for a Node certificate bundle. Endpoint hosts are masked in logs.

Recommended usage flow

A typical run has four stages: benchmark the environment, inspect the mint contract, rehearse the preview, and then execute the real transaction.

1. Bench: confirm that the wallet and network environment are ready.
2. Recon: discover the contract address, ABI, mint function, arguments, timing, and relevant getters.
3. Dry-run: send the preview but stop before execution.
4. Fire: run the transaction engine and allow one execution after the preview passes all checks.

1. Inspect a mint website

Run recon against the mint page:

./fastmint.sh recon https://mint-site

If you already know the contract address, provide it directly:

./fastmint.sh recon https://mint-site --contract 0x...

Recon downloads the page and relevant JavaScript or agent documents, then searches for contract addresses, chain IDs, function names, ABI signatures, and timestamps. It also verifies deployed bytecode, retrieves an ABI from Sourcify when available, reads view functions, and prints mint candidates with guessed arguments, calldata, simulation results, and a possible start time.

Use the output to verify the opening time, price, free supply, per-wallet limit, Agent ID requirements, and decoded contract errors. Do not rely on guessed arguments without checking them.

2. Rehearse the preview

Use fire --dry to perform the checks and preview without executing the transaction:

./fastmint.sh fire --to 0xSALE --data 0x195ad114 --start 23:00 --dry

The --start option accepts Unix seconds, a local HH:MM[:SS] time, or an ISO-8601 timestamp. Inspect the printed call value and confirm that the selector and arguments represent the intended function.

For a rehearsal that must exercise a time-gated path, add --gateSim. This prevents an already-succeeding eth_call from causing the rehearsal to fire before the configured opening time.

3. Execute one mint

After reviewing the dry-run and receiving explicit approval, run the transaction in the background so the agent remains responsive:

./fastmint.sh fire --to 0xSALE --data 0x195ad114 --start 23:00 --label project_free

When the preview returns a successful simulation, the engine invokes baw contract-call execute once. The final report includes the transaction hash, BscScan link, receipt status, received assets when available, a timeline, and the log path.

Basic command examples

Use a function signature

Instead of preparing raw calldata, provide a function signature:

./fastmint.sh fire \
  --to 0xSALE \
  --sig "claimFreeShare()" \
  --start 23:00

Send a paid mint

Paid mints require an explicit amount and a matching maximum cap. For example, two shares at 0.005 BNB each would use:

./fastmint.sh fire \
  --to 0xSALE \
  --sig "buyWithBnb(uint256,address,uint256)" \
  --args '[2,"0x0000000000000000000000000000000000000000",0]' \
  --value 0.01 \
  --maxValue 0.01 \
  --start 23:00

Free mints must use --value 0. The tool rejects a nonzero value without a cap and rejects values that exceed --maxValue.

Require a specific NFT result

Use --expectNft when execution should occur only if the preview indicates that an exact number of NFTs will enter the wallet:

./fastmint.sh fire \
  --to 0xNFT \
  --data 0xa0712d68...0002 \
  --value 0 \
  --expectNft 2

Dynamic arguments

Arguments can be evaluated immediately before each preview. This is useful when a deadline, wallet address, Agent ID, or contract counter changes near the opening time.

• $wallet resolves to the connected wallet address on BNB Smart Chain.
• $agentId resolves to the Agent ID token ID derived from the wallet's registered handle.
• $zero resolves to the zero address.
• $now+1800 resolves to the current Unix time plus 1,800 seconds.
• {"getter":"totalMinted()","add":1} reads a getter and adds one to its unsigned integer result.
• {"getter":"saleStart()","at":"0x..","mul":2} reads a getter from another contract and multiplies the result.

For example, this command refreshes the Agent ID and deadline for every preview:

./fastmint.sh fire \
  --to 0xSALE \
  --sig "mintFree(uint256,uint256,uint256,uint256,address)" \
  --args '["$agentId","1","0","$now+1800","0x0000000000000000000000000000000000000000"]' \
  --start 21:00

Dynamic calls use a lock key based on the destination, selector, and value, so changing arguments does not accidentally permit a second execution of the same mint.

Timing and trigger behavior

Before and around the opening time, the engine can send previews from multiple independent triggers. The default burst lasts three seconds, previews are spaced by at least 350 milliseconds, and up to three previews can be in flight at once.

After the burst, the eth_call loop continues checking for a successful simulation until the timeout, which defaults to 600 seconds. This allows the tool to handle a sale that opens later than announced without repeatedly consuming the preview limit.

Reverts are decoded using the contract's Sourcify ABI, built-in common errors, and 4byte data when available. Errors such as NotStarted, NotOpen, and TooEarly are treated as temporary. Errors such as SoldOut, FreeGone, AlreadyClaimed, NotEligible, and WrongValue are treated as terminal. Unknown errors wait through the grace period before becoming fatal.

You can customize classification with --waitOn and --fatalOn regular expressions, but do so only when you understand the contract's error behavior.

Safety rails to understand

• The tool requires an explicit user instruction for the specific mint.
• A lock file is written before execution, preventing the same call from being broadcast again.
• The engine never automatically signs in, requests a private key, or asks for a seed phrase.
• Binance risk blocks, risk flags, allowance changes, and authority changes stop the run.
• The wallet must have enough balance for the requested value and gas.
• The preview must have simulation code 000000000, a request ID, acceptable native outflow, and no prohibited wallet changes.
• PENDING_CONFIRMATION means the user must approve in the Binance App; the transaction must not be resent.
• After an execute error, a reverted transaction, or a missing receipt, do not retry automatically.

To inspect previous runs, use:

./fastmint.sh logs
./fastmint.sh locks

Delete a lock only after a new explicit user instruction, never merely because a transaction appears slow or failed.

Troubleshooting

Wallet and Developer Mode errors

If baw wallet status reports UNCONNECTED, sign in again manually. Codes 351802 and 351804 usually indicate that Developer Mode is disabled, expired, or above its balance cap. Code 351803 is a Binance risk block and must not be bypassed.

Simulation and contract errors

Repeated 351805 responses are normal before Binance's backend observes the opening block, but they can also indicate incorrect arguments. A persistent NotStarted response may mean the configured time is wrong. SoldOut, FreeGone, and AlreadyClaimed are terminal conditions.

AgentIdRequired or NotEligible may mean that the call needs an Agent ID argument. Payment errors such as PaymentLow and WrongValue mean the supplied BNB amount does not match the contract's requirements.

Network and certificate problems

If RPCs are slow or rate-limited, configure FASTMINT_RPCS or FASTMINT_RPCS_EXTRA. If Node reports UNABLE_TO_GET_ISSUER_CERT_LOCALLY, generate or provide a CA bundle as described in the installation section.

DNS interception can also cause certificate errors or return unexpected ISP domains. Use encrypted DNS or a VPN outside the agent's control; do not change system DNS automatically.

Useful files and commands

The main files are:

• fastmint.sh launches benchmark, recon, fire, log, and lock commands.
• fire.js manages prechecks, triggers, previews, execution, and receipts.
• recon.js discovers contract details and mint candidates.
• bench.js checks the wallet and network environment.
• lib.js provides RPC racing, WebSocket heads, NTP correction, revert decoding, and wallet helpers.
• runs/ stores logs, preview data, execution data, receipts, and lock files.
• cache/ stores downloaded Sourcify ABIs.

Each run log includes local timestamps and T+x.xxxs offsets. The final line is a TIMELINE summary.

Conclusion

fastmint-fcfs combines contract reconnaissance, synchronized timing, parallel blockchain signals, Binance wallet previews, and one-time execution protection for time-sensitive BSC mints. Start with bench, inspect the target with recon, rehearse using --dry, and execute only after confirming the calldata, amount, wallet state, and user authorization.

The project currently targets BNB Smart Chain. Its chain ID, RPC pool, Agent ID registry, and explorer integration are BSC-specific, so it should not be treated as a multi-chain tool.