Use Gateway
ReviewAudited by ClawScan on May 10, 2026.
Overview
The skill appears purpose-aligned for Circle Gateway, but it handles real USDC transfers and includes broad, long-lived signing patterns that users should review carefully before using.
Review this skill before using it with real funds. Start on testnets, independently verify Circle contract addresses and API URLs, protect Circle API credentials server-side, and only sign burn intents after confirming the amount, recipient, fee cap, destination chain, and expiry.
Findings (5)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A signed burn intent may remain usable much longer than expected if mishandled, and users may not understand the maximum fee or authorization lifetime.
The transfer example signs a financial burn intent with an effectively unbounded block-height limit and a fixed fee cap, without explaining expiry or user-specific fee controls.
const MAX_FEE = 2_010000n; ... maxBlockHeight: maxUint64.toString(), maxFee: MAX_FEE.toString(),
Use explicit, finite validity limits and user-visible fee/recipient/amount confirmations. If Circle Gateway requires these values, document why and warn users not to sign or store burn intents casually.
If these credentials are exposed or used in the wrong environment, an attacker could potentially operate the associated Circle developer-controlled wallets.
The developer-controlled wallet flow requires Circle API credentials and an entity secret, which can authorize wallet and transaction operations.
apiKey: process.env.CIRCLE_API_KEY!, entitySecret: process.env.CIRCLE_ENTITY_SECRET!
Keep these credentials server-side only, use a secrets manager, limit permissions where possible, rotate them if exposed, and avoid using production wallets while testing.
Circle receives wallet addresses, transfer details, and signatures needed for attestation as part of the normal workflow.
The documented workflow sends signed burn intents to Circle's Gateway API, which is expected for the integration but carries transaction metadata outside the user's local wallet.
const response = await fetch(`${gatewayUrl}/transfer`, {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify([{ burnIntent, signature: burnSignature }]),Use only the official Circle Gateway endpoints, avoid logging request bodies, and treat signed burn intents as sensitive authorization material.
Users could sign an opaque message without fully understanding that it authorizes a Gateway transfer.
The Solana flow may ask users to sign a non-standard message payload that some wallets refuse, which can be hard for users to inspect even though it is part of the intended burn-intent workflow.
Some browser wallets such as Phantom reject payloads that are not strictly Solana transactions. This workflow has been found to work with Solflare.
Show users the decoded burn-intent details before signing, including amount, source chain, destination chain, recipient, fee cap, and expiry.
Users have less built-in assurance that the listed contract addresses and workflows match Circle's official documentation.
The skill provides financial contract-integration instructions, but the registry metadata does not identify a source repository or homepage for provenance.
Source: unknown Homepage: none
Verify all Gateway Wallet, Gateway Minter, USDC token addresses, and API URLs against Circle's official documentation before using mainnet funds.