Reporting Vulnerabilities
Circle takes security seriously. If you discover a security vulnerability in the EVM CCTP Contracts, please report it responsibly.Bug Bounty Program
Circle operates a Bug Bounty Program through HackerOne to reward security researchers who help keep CCTP secure.- Report vulnerabilities: Circle Bug Bounty Program on HackerOne
- Program scope: Review the program policy before submitting a report
- Responsible disclosure: Follow responsible disclosure practices
Security Best Practices
When integrating with CCTP contracts, follow these security best practices:Smart Contract Integration
Validate burn amounts
Validate burn amounts
Always validate that burn amounts are within expected ranges and that fees don’t exceed the transfer amount.
Check recipient addresses
Check recipient addresses
Ensure recipient addresses are valid and non-zero before initiating transfers.
Handle denylist checks
Handle denylist checks
V2 contracts include denylist functionality. Ensure your integration handles denylisted addresses gracefully.
Monitor pause status
Monitor pause status
CCTP contracts can be paused in emergency situations. Check pause status before operations.
Attestation Service
The attestation service is rate-limited to 1 request per second. Implement proper rate limiting and retry logic in your application.
- Use exponential backoff when polling for attestations
- Cache attestation responses to avoid redundant requests
- Monitor for
pendingstatus and wait before retrying
Role-Based Access Control
CCTP contracts use a sophisticated role-based access control system to manage administrative functions.V1 Roles
Owner
Owner
- Full administrative control over the contract
- Can update other roles (pauser, rescuer, attester manager)
- Uses two-step ownership transfer for safety
Pauser
Pauser
- Can pause and unpause contract operations
- Emergency stop mechanism for critical situations
- Only pauser can trigger pause/unpause
Rescuer
Rescuer
- Can rescue tokens accidentally sent to the contract
- Protects user funds from being permanently locked
Attester Manager
Attester Manager
- Manages the set of authorized attesters
- Can enable/disable attesters
- Sets signature threshold requirements
Token Controller
Token Controller
- Manages token minting and burning permissions
- Links local tokens to remote tokens
- Sets burn limits per message
V2 Additional Roles
V2 introduces additional roles for enhanced functionality:Denylister
Denylister
- Can add/remove addresses from the denylist
- Prevents denylisted addresses from using CCTP
- Separate from owner role for operational flexibility
Fee Recipient
Fee Recipient
- Receives fees collected from cross-chain transfers
- Set during initialization or by owner
- Fees are minted separately to this address
Min Fee Controller
Min Fee Controller
- Can update the minimum fee percentage
- Controls fee structure without owner intervention
- Separate role for fee management flexibility
Security Audits
The CCTP contracts have undergone multiple security audits. Key security features include:- Multi-signature attestation: Requires threshold signatures from multiple attesters
- Nonce tracking: Prevents replay attacks with used nonce tracking
- Domain validation: Ensures messages are only processed on intended chains
- Access control: Role-based permissions for all administrative functions
- Pausability: Emergency stop mechanism for critical situations
Two-Step Ownership Transfer
CCTP uses OpenZeppelin’sOwnable2Step pattern for secure ownership transfers:
- Current owner proposes new owner with
transferOwnership() - New owner accepts with
acceptOwnership() - Ownership only transfers after explicit acceptance
Additional Resources
Bug Bounty Program
Report security vulnerabilities responsibly
Troubleshooting
Common issues and solutions