> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chance.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# Alchemy

> Venue-aware verification for the Alchemy agent stack — pass the exact EVM transaction your agent composed before signing, get a verdict bound to those bytes.

Chance is built to slot into the stack agents are already using — and for onchain agents, that stack is **Alchemy**. Alchemy's [MCP server](https://www.alchemy.com/docs/alchemy-mcp-server) gives an agent everything it needs to *compose* a transaction: balances, nonces, gas estimates, token metadata, simulations across 100+ chains. What it deliberately doesn't provide is a verdict on whether that transaction matches what the agent was told to do. That's Chance. Submit the **exact transaction request** your agent composed — `{to, value, data, chainId}` — before it reaches a signer, and the harness decodes the calldata deterministically, judges it against your mandate with the EVM's own standards in the loop, and returns a signed verdict whose `requestHash` binds to those exact bytes. Alchemy provides the data; Chance provides the verdict.

## What gets recognized

| Family       | Payloads                                                                                                                             |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------ |
| `transfer`   | Native-currency transfers (positive `value`, empty calldata), ERC-20 `transfer` (`0xa9059cbb`), ERC-20 `transferFrom` (`0x23b872dd`) |
| `permission` | ERC-20 `approve` (`0x095ea7b3`) — including detection of the unlimited-allowance sentinel (2^256−1)                                  |
| `unknown`    | Any other contract call — surfaced with its raw selector, judged cautiously                                                          |

The venue accepts any standard EVM transaction request, whichever tools composed it. The classifier decodes recipients, spenders and raw amounts straight from the calldata, converts wei to native units, resolves the chain id to a named network, and flags the things agents gloss over: an approval that never expires, a `transferFrom` spending someone else's balance, a "0 ETH" transaction that moves a six-figure token amount inside `data`. Because token decimals and symbols live in contract state — not calldata — the harness resolves them with a live read-only lookup and reasons over:

> *EVM ERC-20 APPROVE: grant spender 0x51b4…cb44 an allowance of UNLIMITED (2^256−1, the infinite-approval sentinel) on token contract 0x8335…2913 on Base (chainId 8453). No tokens move now; the spender may transferFrom later at will. — resolved: the contract reports symbol "USDC", decimals 6.*

That decode step is what catches the classic onchain-agent failure: an agent whose plan says *"swap 200 USDC on the usual router"* while the transaction it composed quietly grants an unlimited allowance to an address nobody has ever seen. The approval moves nothing at signing time — it looks free — but it hands the spender the wallet's entire current and future balance of that token. The judge sees the decoded grant, not the agent's description. If a selector can't be decoded or a token can't be resolved, the verdict leans ESCALATE rather than trusting the agent's own account: fail closed, never allow on assumption.

## Use it from your bot

Wrap the transaction you were already going to sign:

```ts theme={null}
const tx = {
  to: "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913", // USDC on Base
  value: "0x0",
  chainId: 8453,
  data: "0xa9059cbb000000000000000000000000ab5801a7d398351b8be11c439e05c5b3259aec9b000000000000000000000000000000000000000000000000000000000bebc200",
};

const res = await fetch("https://harness.chance.cc/api/v1/intent", {
  method: "POST",
  headers: { "x-api-key": process.env.CHANCE_API_KEY!, "Content-Type": "application/json" },
  body: JSON.stringify({
    intent: "Treasury ops on Base only. Transfers up to 500 USDC to whitelisted payees. Token approvals exact-amount only, never unlimited.",
    venue: "alchemy",
    action: tx, // the exact payload — the verdict binds to these bytes
  }),
});

const { verdict, reasoning, mode } = await res.json();
if (verdict !== "ALLOW") throw new Error(`Blocked: ${reasoning}`);
// only now sign and broadcast the transaction
```

`venue` is optional — transaction-request shapes carrying calldata are auto-detected — but passing `venue: "alchemy"` is good hygiene (`"evm"` still works as a legacy alias), and freeform `action` descriptions still work (`mode: "semantic"`).

## Use it from Claude or ChatGPT

If your agent already has Alchemy's MCP connected (`https://mcp.alchemy.com/mcp`), add the hosted Chance connector alongside it (`https://harness.chance.cc/api/mcp`, see [Connectors](/connectors)) and give the agent one standing instruction:

> Before signing or broadcasting any transaction you compose with Alchemy's tools, call `verify_intent` with my rules as the intent and the exact transaction object ({to, value, data, chainId}) as the action, with `venue: "alchemy"`. Only proceed on ALLOW; on BLOCK or ESCALATE, stop and tell me why.

The pairing is deliberate: Alchemy's tools give the agent the chain data to build the transaction, and Chance gates the one moment that matters — the payload on its way to the signer. Agents with signing tools then get gated automatically; agents without them still give you provable pre-sign checks in chat.

## How the harness knows the Alchemy stack

The judge works from a **versioned snapshot of the standards themselves** — the JSON-RPC transaction object, the ERC-20 specification and its selector/calldata encoding rules, the ABI encoding spec, EIP-155 chain ids, Circle's canonical USDC contract addresses, and the Alchemy MCP tool surface — plus a curated brief of the venue's footguns (allowances as standing custody grants, decimal-blind raw amounts, unauthenticated symbol strings, chainless payloads). Static knowledge is never fetched at verdict time; the only live calls are read-only token-metadata lookups (`symbol()`/`decimals()` on the target contract) that resolve raw amounts into human units, and what they resolve is recorded in the verdict's hash-chained transcript. Every documentation page the judge consults is chained with its content hash — the receipt proves exactly which knowledge, at which version, informed the decision. See [Architecture](/concepts/architecture).

## What the receipt adds for Alchemy

On top of the standard proof bundle (transcript root, judge signature, onchain anchor), venue-aware verdicts carry `venue: "alchemy"`, the `actionFamily`, the decoded `actionType` (`native-transfer`, `erc20-transfer`, `erc20-approve`, `erc20-transfer-from`, `contract-call`), `mode: "structured"`, the knowledge-snapshot version — and the resolved token metadata (symbol, decimals, chain) when a live lookup succeeded, all inside the hash-chained transcript.

<Note>
  **Roadmap:** escrowed execution — the same contract, but an ALLOW triggers signing by a Chance-held key and a BLOCK physically never reaches one. The payload-first contract above is forward-compatible with it.
</Note>