Build with GARD.

GARD is a transaction protection layer for autonomous money. It sits between an AI agent or application and transaction execution, evaluates a proposed transaction, and returns a decision: ALLOW REVIEW or BLOCK.

Use GARD instantly, with no account, no dashboard and no $GARD. Optimize when you are ready: a free dashboard account adds persistent policies, history and lower fees, and staking $GARD is an optional way to lower them further.

Three ways in, from zero setup to fully integrated. All of them are live on Arc Testnet.

1. Instant: no account, no key

Send a request with an inline policy and get a decision back. Keyless access is rate limited on testnet.

curl -X POST https://gard.cc/v1/evaluate \
  -H "Content-Type: application/json" \
  -d '{"recipient":"0x3e88a1f04c7d59b2e6a0d418f9c73b5e2d10a6f7","asset":"USDC","amount":"25.00","purpose":"Purchase GPU compute","policy":{"maxTransaction":"100","dailyLimit":"500","humanReviewThreshold":"50","allowedAssets":["USDC"],"unknownRecipient":"allow","unknownContract":"review"}}'

2. API key

• Open the dashboard, connect and verify your wallet.
• Set your rules in Policies.
• Create a key in Developers (shown once) and call the API with it.

curl -X POST https://gard.cc/v1/evaluate \
  -H "Authorization: Bearer $GARD_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"recipient":"0x3e88a1f04c7d59b2e6a0d418f9c73b5e2d10a6f7","asset":"USDC","amount":"25.00","purpose":"Purchase GPU compute"}'

import { Gard } from "@gard/sdk";

const gard = new Gard({ apiKey: process.env.GARD_API_KEY });

async function guardedSend(tx: ProposedTransaction) {
  const result = await gard.evaluate({
    recipient: tx.to,
    asset: "USDC",
    amount: tx.amount, // a decimal STRING such as "25.00"
    purpose: tx.purpose,
  });

  if (result.decision === "ALLOW") return wallet.send(tx);
  if (result.decision === "REVIEW") return queueForHumanReview(tx, result);
  throw new Error("Blocked by policy: " + result.reasons.map((r) => r.message).join("; "));
}

3. AI agents (MCP)

Give an MCP-capable agent the GARD tools so it checks every payment before making it.

{
  "mcpServers": {
    "gard": {
      "command": "node",
      "args": ["--experimental-strip-types", "/path/to/gard/packages/mcp/src/bin.ts"],
      "env": { "GARD_API_KEY": "gard_test_...", "GARD_BASE_URL": "https://gard.cc" }
    }
  }
}

Transaction evaluation is the core operation: given a proposed transaction and its context, GARD is designed to assess intent, risk, and policy, and return a decision before anything is executed.

Inputs

• Wallet and recipient
• Asset and amount
• Intended purpose
• Policy and transaction history or context

Output

A decision, a confidence value, and the reasons behind it.

Every evaluation returns exactly one decision.

The application always makes the final choice. GARD returns a decision; it does not move funds on its own.

Policies are explicit rules defined by the application or its operator. They are intended to be evaluated on every request, alongside risk signals.

{
  "maxTransaction": "5000.000000",
  "dailyLimit": "10000.000000",
  "humanReviewThreshold": "1000.000000",
  "allowedAssets": ["USDC"],
  "unknownRecipient": "review",
  "unknownContract": "review"
}

Context is everything GARD is designed to consider beyond the raw transfer: the stated purpose, the wallet's recent activity, the recipient's history, and characteristics of any contract involved. Richer context is intended to support better decisions.

Each decision is intended to be recorded with its inputs, outcome, and reasons so teams can review what an agent attempted and how GARD responded.

In the demo, decisions are stored in your browser only. Durable, shared history is planned as part of a later phase.

POST /v1/evaluate
Authorization: Bearer $GARD_API_KEY      (optional on testnet: keyless "instant" access)
Content-Type: application/json

{
  "requestId": "req-1f3a9c2e",
  "recipient": "0x3e88a1f04c7d59b2e6a0d418f9c73b5e2d10a6f7",
  "asset": "USDC",
  "amount": "500.00",
  "purpose": "Purchase GPU compute"
}

{
  "version": "1",
  "evaluationId": "01M30R5X27FXXZX55JTHC9P8C1",
  "decisionId": "01M30R5X9AXTPJ3H7A0WDEC480",
  "decision": "REVIEW",
  "confidenceBps": 9000,
  "reasons": [
    { "code": "new_recipient", "message": "Recipient has no successful history with this wallet", "severity": "warning" }
  ],
  "policy": { "id": "01M2...", "version": "3", "source": "saved" },
  "evaluator": { "provider": "gard-rules", "version": "gard-rules/2" },
  "accessMode": "api_key",
  "pricingTier": "REGISTERED",
  "replayed": false
}

Errors and limits

Errors are { error: { code, message } }. Codes include validation_error, invalid_api_key, rate_limited and quota_exceeded (both HTTP 429 with Retry-After) and payment_required (HTTP 402, x402). A bad key is always a 401: it never falls back to keyless access.

• GET /v1/evaluations/{id}: one stored evaluation with its signals and execution status.
• GET /v1/decisions: newest-first history, filterable by decision.
• GET /v1/policy: the policy your evaluations are checked against.
• GET /v1/limits: spending remaining today. Counts confirmed transactions only.

Events: evaluation.created, decision.allow, decision.review_required, decision.block, execution.submitted, execution.confirmed and execution.failed. Every delivery is HTTPS, signed with HMAC-SHA256 over the timestamp and body, carries a unique delivery id so you can de-duplicate, and is retried with exponential backoff (1 minute, 5 minutes, 30 minutes, 2 hours, 6 hours) until it succeeds or is marked failed.

POST https://your-server.example/gard
Gard-Event: decision.review_required
Gard-Delivery-Id: dec-01M30R5X9AXTPJ3H7A0WDEC480-01M2...
Gard-Signature: t=1790000000,v1=9f2c...

{ "id": "dec-01M30...", "type": "decision.review_required",
  "data": { "evaluationId": "01M30...", "decision": "REVIEW", "reasons": [ ... ] } }

import { Gard } from "@gard/sdk";

// rawBody is the exact request body string; never re-serialize it.
Gard.verifyWebhook({
  secret: process.env.GARD_WEBHOOK_SECRET!,
  payload: rawBody,
  signatureHeader: req.headers["gard-signature"] as string,
});

Zero dependencies. Amounts are decimal strings (a JS number is rejected). Retries reuse the same idempotency key, honor Retry-After, and a 402 surfaces the x402 challenge.

import { Gard } from "@gard/sdk";

const gard = new Gard({ apiKey: process.env.GARD_API_KEY });

async function guardedSend(tx: ProposedTransaction) {
  const result = await gard.evaluate({
    recipient: tx.to,
    asset: "USDC",
    amount: tx.amount, // a decimal STRING such as "25.00"
    purpose: tx.purpose,
  });

  if (result.decision === "ALLOW") return wallet.send(tx);
  if (result.decision === "REVIEW") return queueForHumanReview(tx, result);
  throw new Error("Blocked by policy: " + result.reasons.map((r) => r.message).join("; "));
}

Agent frameworks are expected to call GARD from the tool or step that would otherwise sign and send a transaction: evaluate first, then execute only on ALLOW, queue on REVIEW, and stop on BLOCK. Passing a clear purpose with each request is intended to improve decisions.

Wallets can request a decision before presenting a confirmation prompt and display GARD's reasons alongside it, so users see why a transaction looks unusual before they sign.

Payment applications can add GARD as a policy step in USDC payment flows, applying the same limits and review rules however a payment is initiated.

Protected by GARD means a transaction passed through GARD's policy and evaluation system before it was sent, and the decision was recorded.

Wallets, agent platforms, payment apps and merchant or treasury systems can integrate GARD and show this label. Commercial terms for integrations (platform fee, evaluation usage, protected-transaction usage, implementation fee, custom rate, service levels) are agreed per customer. No customer or contract is implied by this page.

Anyone can use GARD. You never need an account or $GARD.

Two ways GARD earns

• GARD protected execution. The transfer goes through the GARD router. The recipient receives the full amount and the fee is paid to the treasury in the same transaction. You still sign with your own wallet; GARD never holds your funds.
• Evaluation only. You evaluate with GARD and execute independently. GARD cannot collect a transaction fee on a transfer that bypasses it, so evaluation pricing applies instead (a per-evaluation price for keyless callers, and plan allowances with overage for accounts).

Plans

Paid-plan checkout is prepared but no payment provider is connected yet, so no plan is billable today.

GARD is policy-first: explicit rules are evaluated on every request, and risk signals are intended to inform, not replace, those rules. The most restrictive outcome wins. If one rule says BLOCK, the decision is BLOCK.

The demo evaluator follows this model with a small set of deterministic rules so you can see how policy changes affect a decision.

REVIEW exists for cases that should not be decided automatically. Applications are expected to route these to a person and record the outcome. Human-review thresholds let you decide how large a transaction can be before a person must approve it.

• GARD does not promise to prevent all malicious, mistaken, or unwanted transactions.
• An ALLOW decision is not a guarantee that a transaction is safe or reversible.
• Risk signals are planned and will not catch every case.
• Applications remain responsible for the policies they configure and the actions they take.

$GARD is intended to coordinate access and participation: access tiers, lower fees, higher API and policy limits, and future operator bonding. USDC remains the asset used for payments. See the $GARD page for details.

Staking $GARD is intended to unlock access tiers. Mechanics, thresholds, and any related terms have not been finalized.

Higher tiers are intended to provide lower protocol and API fees and higher limits. No fee schedule has been published.