Use cases
One protection layer.
Many ways money moves.
From autonomous purchasing agents to consumer payment apps, GARD is designed to put a decision in front of every transaction.
Use case scenarios
AI Purchasing Agents
Agents that purchase services, APIs, compute, advertising, inventory, or other resources.
- Problem
- An agent with a funded wallet can overspend or pay the wrong party if a prompt, tool, or counterparty misleads it.
- How GARD fits
- GARD evaluates each purchase against the agent's purpose and spending policy before it is signed.
- Example decision
- REVIEW1,800 USDC to a first-time vendor is routed to a person.
Crypto Wallets
Evaluate unusual transfers or risky interactions before execution.
- Problem
- Users approve transfers and contract interactions without much context about whether they look normal.
- How GARD fits
- A wallet can ask GARD for a decision and surface the reasons before the user confirms.
- Example decision
- BLOCKTransfer to a burn-address pattern is stopped before signing.
Payment Applications
Add transaction policies to USDC payment flows.
- Problem
- Payment apps need consistent limits and review rules across every way a payment can be initiated.
- How GARD fits
- GARD acts as a policy step in the payment flow, returning a decision the app applies uniformly.
- Example decision
- ALLOWA 75 USDC payment to a known recipient proceeds.
Merchant Systems
Validate autonomous purchasing activity against merchant and spending rules.
- Problem
- Merchants receiving payments from agents need confidence that activity fits expected rules and patterns.
- How GARD fits
- GARD can evaluate agent-originated payments against merchant-defined and spending rules.
- Example decision
- REVIEWAn order far above the agent's usual size is held for confirmation.
Treasury Agents
Apply limits and review thresholds before autonomous treasury transactions.
- Problem
- Autonomous treasury operations can move large sums; a single mistaken or manipulated action is costly.
- How GARD fits
- Per-transaction caps, daily limits, and human-review thresholds are evaluated on every request.
- Example decision
- BLOCKA 9,200 USDC transfer exceeds the per-transaction limit.
Developer Platforms
Add ALLOW / REVIEW / BLOCK decisions before executing programmatic payments.
- Problem
- Platforms that let developers trigger payments programmatically need a guard against runaway or abusive calls.
- How GARD fits
- A single evaluate call returns a structured decision the platform can enforce before executing.
- Example decision
- ALLOWA request within the account's policy is executed.
SolPay-style Consumer Payments
Consumer payment applications can integrate GARD as a transaction evaluation layer.
- Problem
- Consumer payment apps serve people who may be tricked into sending funds to the wrong place.
- How GARD fits
- A consumer app can request a GARD decision and present clear reasons before completing a payment.
- Example decision
- REVIEWA first payment to a new recipient asks the user to confirm.
A generic description of a possible integration. It does not indicate a live integration with any specific product.
Scenarios and example decisions are illustrative. They describe intended behavior, not live results.