An MCP server is a remote capability boundary. The model calls tools; the user approves signing or delegates to an agent. Syenite returns unsigned transactionRequest objects — routing and data stay separate from custody. The trust layer extends that idea: four tools let you verify, simulate, enforce policy, and confirm on-chain results without trusting Syenite's narrative about the transaction.
Execution tools return intent (calldata and targets), not settled state. If the only step after swap.quote is sign, you trust whoever built the quote — routing APIs, the MCP host, prompt injection — that the to address and data match what you think you are doing. Speed favors skipping checks. Security favors treating every transaction as untrusted until verified against independent sources and your own policy.
Five stages: verify the target, simulate against current state, guard against your rules, sign, and receipt to confirm settlement. Each stage is independent and reproducible via public RPCs and block explorers.
Checks the to address: contract vs EOA, Etherscan verification, Sourcify match, Syenite protocol registry, and optional function selector decode via 4byte.directory. Answers "who am I really calling?"
Parameters:
to (address): target contract or EOAchain: ethereum, arbitrum, base, bscdata (optional): calldata for selector decodeResponse: verification.etherscan, verification.sourcify, protocol.syeniteAllowlisted, riskFlags (e.g. unverified_contract, proxy_contract, eoa_target), summary.
Runs eth_call at the current block. Reports success or revert, gas estimate, native value outflow, and approximate gas cost in USD. Reverts mapped to token_approval_required when the error suggests allowance issues. Answers "does this tx plausibly execute as intended?"
Parameters:
transaction object: to, data, from, optional value, optional chainIdchain (optional): name or idChains: ethereum, arbitrum, base, bsc. Full ERC-20 balance deltas need trace-level simulation (e.g. Tenderly); the tool documents this in its note field.
Evaluates the transaction against rules you supply. Syenite does not change your rules. Answers "does this tx fit my agent's mandate?"
Rules (at least one required):
maxValueNative (string): ETH-equivalent capallowedContracts / blockedContracts: address arraysallowedFunctions: selectors or hex stringsrequireVerifiedContract (boolean): emits skip telling you to run tx.verify firstrequireAllowlisted: must match Syenite curated registrymaxGasLimit: with transaction.gasLimit setResponse: checks with pass/fail/skip, approved (no failures and no skips), summary.
Post-signing confirmation. Fetches the on-chain transaction receipt and decodes events, giving definitive proof of settlement. Answers "did the transaction land, and what happened?"
Parameters:
txHash (string): transaction hash to look upchain (string, optional): defaults to ethereum; accepts names and aliasesResponse: status (confirmed or reverted), gasUsed, gasCostETH, gasCostUSD, decoded logs (up to 20 events with known topic names), tokenTransfers (ERC-20 transfers extracted from Transfer events), explorerUrl. The receipt is fetched via standard RPC — independently verifiable.
Each pre-signing step adds latency (HTTP to explorers, RPC for simulation). The fast path is quote → sign → receipt. The safer path is verify → simulate → guard → sign → receipt. Autonomous agents can default to the full pipeline for high-value or unfamiliar contracts, and relax it for repeated, allowlisted routes once operational confidence is established.
swap.quote, lending.supply, etc.) returns transactionRequest. 2. tx.verify the target. 3. tx.simulate the full tx. 4. tx.guard against your rules. 5. Sign if all checks pass. 6. tx.receipt to confirm settlement and decode events.
Lending execution (supply, borrow, withdraw, repay). Swap and bridge. Security and production. Position alerts.