> ## Documentation Index
> Fetch the complete documentation index at: https://mintlify.com/circlefin/evm-cctp-contracts/llms.txt
> Use this file to discover all available pages before exploring further.

# Security

> Security best practices, vulnerability reporting, and role-based access control for EVM CCTP Contracts

## Reporting Vulnerabilities

Circle takes security seriously. If you discover a security vulnerability in the EVM CCTP Contracts, please report it responsibly.

<Warning>
  **Do not file public issues on GitHub for security vulnerabilities.** All security vulnerabilities should be reported privately.
</Warning>

### 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](https://hackerone.com/circle-bbp)
* **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

<AccordionGroup>
  <Accordion title="Validate burn amounts">
    Always validate that burn amounts are within expected ranges and that fees don't exceed the transfer amount.

    ```solidity theme={null}
    require(amount > 0, "Amount must be nonzero");
    require(maxFee < amount, "Max fee must be less than amount");
    ```
  </Accordion>

  <Accordion title="Check recipient addresses">
    Ensure recipient addresses are valid and non-zero before initiating transfers.

    ```solidity theme={null}
    require(mintRecipient != bytes32(0), "Mint recipient must be nonzero");
    ```
  </Accordion>

  <Accordion title="Handle denylist checks">
    V2 contracts include denylist functionality. Ensure your integration handles denylisted addresses gracefully.

    ```solidity theme={null}
    // Calls will revert if sender or tx.origin is denylisted
    tokenMessenger.depositForBurn(...);
    ```
  </Accordion>

  <Accordion title="Monitor pause status">
    CCTP contracts can be paused in emergency situations. Check pause status before operations.

    ```solidity theme={null}
    require(!paused, "Pausable: paused");
    ```
  </Accordion>
</AccordionGroup>

### Attestation Service

<Note>
  The attestation service is rate-limited to **1 request per second**. Implement proper rate limiting and retry logic in your application.
</Note>

* Use exponential backoff when polling for attestations
* Cache attestation responses to avoid redundant requests
* Monitor for `pending` status and wait before retrying

## Role-Based Access Control

CCTP contracts use a sophisticated role-based access control system to manage administrative functions.

### V1 Roles

<AccordionGroup>
  <Accordion title="Owner">
    * Full administrative control over the contract
    * Can update other roles (pauser, rescuer, attester manager)
    * Uses two-step ownership transfer for safety
  </Accordion>

  <Accordion title="Pauser">
    * Can pause and unpause contract operations
    * Emergency stop mechanism for critical situations
    * Only pauser can trigger pause/unpause
  </Accordion>

  <Accordion title="Rescuer">
    * Can rescue tokens accidentally sent to the contract
    * Protects user funds from being permanently locked
  </Accordion>

  <Accordion title="Attester Manager">
    * Manages the set of authorized attesters
    * Can enable/disable attesters
    * Sets signature threshold requirements
  </Accordion>

  <Accordion title="Token Controller">
    * Manages token minting and burning permissions
    * Links local tokens to remote tokens
    * Sets burn limits per message
  </Accordion>
</AccordionGroup>

### V2 Additional Roles

V2 introduces additional roles for enhanced functionality:

<AccordionGroup>
  <Accordion title="Denylister">
    * Can add/remove addresses from the denylist
    * Prevents denylisted addresses from using CCTP
    * Separate from owner role for operational flexibility
  </Accordion>

  <Accordion title="Fee Recipient">
    * Receives fees collected from cross-chain transfers
    * Set during initialization or by owner
    * Fees are minted separately to this address
  </Accordion>

  <Accordion title="Min Fee Controller">
    * Can update the minimum fee percentage
    * Controls fee structure without owner intervention
    * Separate role for fee management flexibility
  </Accordion>
</AccordionGroup>

## 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's `Ownable2Step` pattern for secure ownership transfers:

1. Current owner proposes new owner with `transferOwnership()`
2. New owner accepts with `acceptOwnership()`
3. Ownership only transfers after explicit acceptance

This prevents accidental ownership loss from typos or invalid addresses.

## Additional Resources

<CardGroup cols={2}>
  <Card title="Bug Bounty Program" icon="shield-halved" href="https://hackerone.com/circle-bbp">
    Report security vulnerabilities responsibly
  </Card>

  <Card title="Troubleshooting" icon="wrench" href="/resources/troubleshooting">
    Common issues and solutions
  </Card>
</CardGroup>