Build with GARD.

GARD is a transaction protection layer for autonomous money. It is designed to sit between an AI agent or application and transaction execution, evaluate a proposed transaction, and return a decision: ALLOW REVIEW or BLOCK.

GARD is initially designed for USDC transaction workflows on Arc, with a chain-neutral architecture intended to support other networks over time.

Until the API is available, the fastest way to see the flow is the demo application.

• Open the demo evaluator and submit a sample transaction.
• Adjust limits in Policies and evaluate again to see how the decision changes.
• Review the result in History.

The conceptual integration below shows where GARD is intended to sit in your code.

// Conceptual integration. The GARD API is planned and not yet available.
// GARD_API_URL will be published when the API launches.

async function guardedSend(tx: ProposedTransaction) {
  const res = await fetch(`${GARD_API_URL}/v1/evaluate`, {
    method: "POST",
    headers: { "content-type": "application/json" },
    body: JSON.stringify({
      wallet: tx.from,
      asset: tx.asset,
      amount: tx.amount,
      recipient: tx.to,
      purpose: tx.purpose,
    }),
  });
  const { decision } = await res.json();

  if (decision === "ALLOW") return wallet.send(tx);
  if (decision === "REVIEW") return queueForHumanReview(tx);
  throw new Error("Blocked by policy");
}

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,
  "dailyLimit": 10000,
  "allowedAssets": ["USDC"],
  "unknownRecipient": "review",
  "unknownContract": "review",
  "humanReviewThreshold": 1000
}

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.

A decisions resource is planned to let applications retrieve past decisions and their reasons for audit and analysis, for example GET /v1/decisions. The exact interface is not final.

Webhooks are planned to notify your application when a decision needs attention, such as a REVIEW awaiting a person, or when its outcome is resolved.

{
  "event": "decision.review_required",
  "decisionId": "dec_...",
  "decision": "REVIEW",
  "reasons": ["new_recipient"]
}

A typed TypeScript client is planned for browser and server runtimes.

// Planned interface sketch. Not published.
import { Gard } from "<planned-package>";

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

const result = await gard.evaluate({
  wallet,
  asset: "USDC",
  amount: 500,
  recipient,
  purpose: "Purchase API credits",
});

A Node.js package is planned with server-side helpers, including webhook signature verification.

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.

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.