Verify transaction intent API

Compare an EVM transaction's calldata and native value with the action declared in the request. Decoding uses the ABI in the request, or the standard ERC-20 transfer, transferFrom, approve, and increaseAllowance encodings when that selector matches. intent_match is true, false, or the string indeterminate when a declared field cannot be checked. risk_level is low, medium, high, or critical. This is static analysis: it does not read chain state, simulate the call, or decide that a contract is malicious or that the transaction will succeed.

The Verify transaction intent operation is part of the Transaction Intent Verification API on BRAINIAC.software. Compare an EVM transaction's calldata and native value with the action declared in the request. Decoding uses the ABI in the request, or the standard ERC-20 transfer, transferFrom, approve, and increaseAllowance encodings when that selector matches. intent_match is true, false, or the string indeterminate when a declared field cannot be checked. risk_level is low, medium, high, or critical. This is static analysis: it does not read chain state, simulate the call, or decide that a contract is malicious or that the transaction will succeed. It is exposed as POST /api/v1/crypto-security/transaction-intent-verify and priced at $0.04 USDC on Base. Payment uses the x402 exact scheme: an unpaid call returns HTTP 402 with payment requirements; after paying the exact USDC amount, retry the same request with a payment-signature header and Idempotency-Key. No account and no API key are required. Data sources for this product: Caller-supplied transaction calldata, ABI, and declared intent processed locally Limitations: This is static calldata analysis. It does not read chain state, simulate execution, or decide whether a contract is malicious or whether a transaction will succeed. A function is decoded from the caller ABI, or from the standard ERC-20 transfer, transferFrom, approve, and increaseAllowance selectors when no ABI is supplied. Other functions are not inferred. If the selector is unknown, intent_match is indeterminate. Chain ID is accepted as a label and is not checked against a network. Unlimited approvals are the uint256 maximum encoded in the calldata. No allowance is read from a contract. Storage variables are matched by slot and offset. A matching name is not storage identity. A storage result of compatible does not prove that an upgrade is safe or that runtime behavior is unchanged. Struct, mapping, and dynamic-array layouts are compared only from the types map in the request. intent-safety reads the supplied transaction or EIP-712 message. A known selector later in multicall, aggregate, or execute calldata is reported as an inner call and can be a coincidence. storage-slot-grade treats the collision score as a weighted count of overlaps and moves, capped at 100. It is not a measured probability. Outputs are compliance prechecks, drafts, or data lookups for human review. They are not official determinations, legal advice, identity confirmation, or certified filings. Related operations in this group include Score transaction intent safety, Audit proxy upgrade storage, Grade proxy storage slot changes. Open the group documentation for the full request schema, field notes, and response examples before integrating.