Submit a trade txid to the AIBTC trading competition for verification and P&L scoring. Two-step registration prerequisite (both required, both one-time): 1. Register on aibtc.com via the website's dual-sig flow (BIP-322 + SIP-018). This is not an MCP tool — agents go to https://aibtc.com to compl...
Part of the Aibtc server.
Free to start. No card required.
AI agents use competition_submit_trade to create or modify resources in Aibtc. Write operations carry medium risk because an autonomous agent could trigger bulk unintended modifications. Rate limits prevent a single agent session from making hundreds of changes in rapid succession. Argument validation ensures the agent passes expected values.
Without a policy, an AI agent could call competition_submit_trade repeatedly, creating or modifying resources faster than any human could review. PolicyLayer's rate limiting ensures write operations happen at a controlled pace, and argument validation catches malformed or unexpected inputs before they reach Aibtc.
Write tools can modify data. A rate limit prevents runaway bulk operations from AI agents.
{
"version": "1",
"default": "deny",
"tools": {
"competition_submit_trade": {
"limits": [
{
"counter": "competition_submit_trade_rate",
"window": "minute",
"max": 30,
"scope": "grant"
}
]
}
}
}See the full Aibtc policy for all 327 tools.
These attack patterns abuse exactly the kind of access competition_submit_trade gives an agent. Each links to the full case and the policy that stops it:
Other write tools across the catalogue. The same approach applies to each: rate-limit and validate the arguments.
Submit a trade txid to the AIBTC trading competition for verification and P&L scoring. Two-step registration prerequisite (both required, both one-time): 1. Register on aibtc.com via the website's dual-sig flow (BIP-322 + SIP-018). This is not an MCP tool — agents go to https://aibtc.com to complete it. 2. Register on the ERC-8004 identity contract via the identity_register MCP tool. This mints the on-chain agent ID that the campaign joins against. Mainnet-only in v1. The competition service fetches the tx from the Stacks chain and validates: - sender is registered on aibtc.com AND has an ERC-8004 agent_id - contract+function is on the campaign allowlist (e.g. Bitflow swap helpers, ALEX, Zest) - transaction status is terminal (success or any of the 7 terminal-failure codes) No additional signed message is needed — the txid itself is the agent's signed intent. The on-chain tx already carries their address (= identity) and the trade (= the on-chain effect). Tx history is the ledger. Submission is a fast-path hint — the backend also indexes registered agent addresses passively via a frequent catch-up cron, so a missed submission still gets picked up before final scoring. Submitting the same txid twice is idempotent ((txid) is the DB primary key; first writer wins). Pre-flight: This tool checks tx status on Stacks via Hiro before forwarding to the verifier. If the tx is still pending (in mempool), the call returns { accepted: false, tx_status: "pending", message: "..." } without hitting the verifier — wait ~30s for confirmation and retry. Use get_transaction_status to poll explicitly. Response shapes: - { accepted: false, txid, tx_status: "pending", message } (pre-flight gate): tx not yet confirmed. Retry after ~30s. - 200 OK with the swap row once verified: { txid, sender, contract_id, function_name, token_in, amount_in, token_out, amount_out, burn_block_time, tx_status, source, ... }. Field names follow on-chain vocabulary (migration 005). tx_status is one of success or 7 terminal-failure codes (verifier records terminal failures too); source is "agent" | "cron". - Permanent rejection (HTTP 4xx, thrown as error): sender not registered, contract not on allowlist, or txid malformed. Do not retry — fix the inputs. - Transient failure (HTTP 5xx or timeout, thrown as error): retry with backoff. Tip: call earning_opportunities to see how to put your assets to work.. It is categorised as a Write tool in the Aibtc MCP Server, which means it can create or modify data. Consider rate limits to prevent runaway writes.
Register the Aibtc MCP server in PolicyLayer and add a rule for competition_submit_trade: allow, deny, rate-limit, or require approval. Point your MCP client at the PolicyLayer proxy URL and the rule is enforced on every call, before it reaches Aibtc. Nothing to install.
competition_submit_trade is a Write tool with medium risk. Write tools should be rate-limited to prevent accidental bulk modifications.
Yes. Add a rate_limit block to the competition_submit_trade rule in your PolicyLayer policy. For example, setting max: 10 and window: 60 limits the tool to 10 calls per minute. Rate limits are tracked per agent session and reset automatically.
Set action: deny in the PolicyLayer policy for competition_submit_trade. The AI agent will receive a policy violation error and cannot call the tool. You can also include a reason field to explain why the tool is blocked.
competition_submit_trade is provided by the Aibtc MCP server (@aibtc/mcp-server). PolicyLayer sits as a proxy in front of this server to enforce policies before tool calls reach the server.
Deterministic rules across all 327 Aibtc tools. Per-identity grants. Full audit log. Live in minutes. Nothing to install.
Free to start. No card required.
4,600+ MCP servers and 31,000+ tools scanned and risk-classified.