Skip to main content

Best Practices

This document outlines best practices, common pitfalls, and security considerations for developers integrating with the Transaction Submission API. Following these guidelines will help ensure a secure, efficient, and reliable integration.

General Principles

  • Validate Inputs: Always validate and sanitize any inputs from users or external systems that are used to construct calls within an intent. Never trust user input directly when forming transaction data.
  • Least Privilege: Construct intents with the minimum permissions necessary to achieve the desired outcome. For example, if swapping tokens, set the exact amount for approval rather than an unlimited approval.
  • Idempotency: Design your submission logic to be idempotent where possible. If you encounter a network error when submitting an intent, you should be able to safely retry the submission without creating duplicate intents.

Security Best Practices

  • Signature Verification: The security of the entire system relies on cryptographic signatures. Ensure you are using trusted libraries (like viem or ethers) to produce EIP-7702 authorizations and intent signatures.
  • Protect User Private Keys: In any front-end integration, the user’s private key must remain entirely within their control. Your application should only ever request signatures for authorizations and intents, never the key itself.
  • Chain ID and Contract Address Validation: Double-check that you are targeting the correct chainId and delegate contract address when creating EIP-7702 authorizations. A mismatched chain ID can lead to failed transactions or unexpected errors.

Common Errors and Troubleshooting

  • CallReverted: This means one of the calls within your ChainBatch failed on-chain.
    • Troubleshooting:
      1. Check the to, value, and data for the failing call. Is the address correct? Is the function signature in the data correct?
      2. Ensure the Delegate contract has the necessary approvals (e.g., ERC20 approve) to perform the action on behalf of the user. Approvals should be included as one of the first calls in your ChainBatch.

Integration Guidelines

Frontend Integration

  • Use established Web3 libraries like viem, ethers, or wagmi for wallet connections and signature generation
  • Always show users what they’re signing before requesting signatures
  • Implement proper loading states during transaction submission and execution
  • Handle network errors gracefully with retry mechanisms

Backend Integration

  • Implement proper error handling and logging for all API calls
  • Use database transactions when updating your application state based on intent execution
  • Consider implementing webhooks or polling for intent status updates
  • Store transaction hashes for audit trails and user support

Performance Optimization

  • Batch multiple operations into single intents when possible
  • Use appropriate gas limits to avoid failed transactions
  • Consider implementing retry logic with exponential backoff for network errors
  • Cache frequently accessed data like chain configurations

Development Workflow

  1. Test on Testnets: Always test your integration thoroughly on testnets before going to production
  2. Use Dry Runs: Utilize the dryRun option in step execution to validate your intents before committing
  3. Monitor Gas Usage: Track gas consumption patterns to optimize your intents
  4. Handle Edge Cases: Plan for scenarios like network congestion, failed steps, and partial execution

Security Checklist

  • User private keys never leave their device
  • All user inputs are validated and sanitized
  • Chain IDs and contract addresses are verified
  • Signature verification is implemented correctly
  • Error handling doesn’t leak sensitive information
  • Rate limiting is implemented to prevent abuse
  • Audit trails are maintained for all transactions

Support and Resources