Skip to main content
Use this checklist before going live with your Gauntlet vault integration. Complete each section to verify that your integration is production-ready.

​
Authentication

  • API key created and stored securely (not hardcoded in client-side code)
  • JWT token exchange tested successfully against production endpoint
  • Token refresh logic implemented to handle expiration gracefully
  • Rate limit handling in place with appropriate backoff strategy (see Rate Limits)
  • Error responses for authentication failures handled in your UI
See Credentials for authentication setup details.

​
Data Validation

  • Vault list endpoint returns expected vaults for your integration
  • Vault metrics (TVL, APY, share price) display correctly in your UI
  • User position data accurate after test deposit
  • Historical timeseries data rendering properly in charts and reports
  • Data refresh intervals appropriate for your use case (not over-polling)
Test against mainnet with real data. Gauntlet does not maintain a separate testnet environment — use small deposit amounts for validation.

​
Integration Validation

  • Deposit flow tested with small amounts on mainnet
  • Withdrawal flow tested end-to-end (request through receipt of funds)
  • Error handling covers common failure modes: insufficient balance, slippage exceeds tolerance, gas estimation failures, and transaction reverts
  • Transaction confirmation and status tracking working
  • User-facing messaging accurate for all transaction states

​
Fee Setup

If your integration involves fee configuration (see Fees):
  • Fee recipient address configured on-chain
  • Fee accrual verified — deposit, wait for fee period, check accruedFees()
  • Fee claiming tested via claimFees() function
  • Fee display accurate in your UI (if showing fees to end users)
Fee setup applies primarily to Aera V3 vaults with a FeeVault contract. For other protocols, fee configuration is handled through your partnership agreement with Gauntlet.

​
Attribution

  • Builder code received from Gauntlet and set as builderCode on GauntletClient (not self-serve — request from the Gauntlet partnerships team)
  • If using step.payload + sendTransaction: confirm payload.data ends with your ERC-8021 suffix (0x8021 + UTF-8 hex of your builder code)
  • If using step.tx + writeContract: confirm dataSuffix: step.tx.attribution is passed — omitting it silently drops attribution even if the transaction succeeds
  • At least one test deposit confirmed attributed in the Gauntlet Developer Portal or via the events API

​
Monitoring

  • Event tracking active for deposits, withdrawals, and transfers
  • Alerting configured for failed transactions and unexpected errors
  • Volume reporting pipeline operational (see Tracking Attribution)
  • Logging sufficient to diagnose issues in production
  • Health check endpoint monitoring the Gauntlet API availability

​
Security Review

  • API keys stored in secure secret management (not in source control)
  • JWT tokens not exposed to client-side code
  • Smart contract interaction addresses verified against official deployment
  • The SDK will not sign transactions
  • Input validation on all user-provided values (amounts, addresses)

​
Final Steps

Before going live:
  1. Complete all sections above — Address any unchecked items.
  2. Run a full end-to-end test — Simulate the complete user journey from authentication through deposit, data display, and withdrawal.
  3. Contact Gauntlet for production sign-off — Share your integration status with your partner representative.