We refreshed our doc site!
Bookmarked links may have changed
Read release notes
"Reorgs" and Associated Risks
Transactions in a blockchain are packaged into blocks. Different blockchains have different rules for how to decide which transactions get packaged into a block, but they often include rules for invalidating recently generated blocks.
This rewrite of history is called a "reorganization" ("reorg" for short) and invalidates any transactions included in the invalidated blocks. You can think of invalidated transactions that moved funds as transactions that "never happened".
Such events can represent a security risk, because an attacker could use a cryptocurrency transfer as payment for a good or service, and subsequently trigger a reorg, thus invalidating his transfer (and getting his cryptocurrency back) while keeping the good or service he paid for.
Confirmations
To protect against reorg attacks, it's beneficial to wait for a number of confirmed blocks before recognizing a transfer as final. As more blocks are processed after a given block, the difficulty with which that block may be invalidated increases. Therefore, by choosing how many blocks to wait before recognizing a transfer, a receiver is able to balance speed (waiting very few blocks in order to process the transfer quickly while taking on risk of losing money due to a reorg) and security (waiting more blocks to minimize the risk of a reorg at the cost of slower transfer processing).
The number of blocks you wait before considering a transfer as final is called the "confirmation number", which is typically different for different chains. Circle Mint and its APIs use the following confirmation numbers for each supported chain. They are based on a variety of factors that Circle has considered, including a given chain's historical performance, reorganizations, and overall architecture, and they do not reflect the blockchain networks' inherent requirements or limits.
| Chain | Confirmations/Blocks | Approximate Time |
|---|---|---|
| Algorand (USDC) | 1 | ~3 seconds |
| Arbitrum (USDC) | 300 | ~3 minutes |
| Avalanche (USDC, EURC) | 1 | ~2 seconds |
| Base (USDC, EURC) | 12 | ~3 minutes |
| Bitcoin (BTC) | 4 | ~40 minutes |
| Celo (USDC) | 1 | ~5 seconds |
| Ethereum (USDC, EURC, ETH) | 12 | ~3 minutes |
| Flow (USDC)* | 1 | ~2.5 seconds |
| Hedera (USDC) | N/A | ~3 seconds |
| NEAR (USDC) | 1 | ~2 seconds |
| Noble (USDC) | 1 | ~1.53 seconds |
| OP Mainnet (USDC) | 12 | ~4 minutes |
| Polkadot Asset Hub (USDC) | 1 | ~12 seconds |
| Polygon PoS (USDC) | 50 | ~2 minutes |
| Solana (USDC, EURC) | 1 | ~400 milliseconds |
| Stellar (USDC, EURC) | 1 | ~5 seconds |
| Sui (USDC) | 1 | ~500 milliseconds |
| TRON (USDC)** | 19 | ~1 minute |
| ZKsync Era (USDC)*** | 35 | ~4 hours |
*Effective Sept 3, 2024 - Circle is discontinuing support for USDC on Flow. For details, see Circle is Discontinuing Support for USDC on the Flow (Cadence) blockchain.
** Effective Feb. 20, 2024 -Circle is discontinuing support for USDC on Tron. For details, see Circle is Discontinuing Support for USDC on the TRON blockchain.
*** ~35 Ethereum blocks after the proof for the batch is posted to the L1.
Hedera
Hedera is built on a hashgraph rather than a blockchain. For this reason, there isn’t a count of confirmations/blocks before Circle determines the transfer to be valid. Instead, this determination is performed on Hedera directly and is then shared back to Circle. Please see the following link to learn more about Hedera consensus.
Polygon PoS
Circle’s platform requires 372 confirmations for transactions on Polygon PoS before marking them as complete, which takes ~20 minutes. 372 represents 3X the number of confirmations needed to ensure transaction finality beyond a reasonable doubt, based on the largest reorg seen to date.
Base and OP Mainnet
These Layer 2 (L2) rollup blockchains are based on the OP Stack and maintain their security by periodically batch transferring their transaction data to their L1 blockchain, Ethereum. To ensure finality beyond a reasonable doubt, Circle's platform recognizes transaction finality for these L2 networks after their batched transaction data has settled and achieved 12 confirmations on Ethereum.
You can use L2 block explorers (such as BaseScan and Optimistic Etherscan) to view transactions at any time, including during the time period that elapses while Circle's platform is waiting to recognize transaction finality on its internal systems.
Confirmations and Transfer Status
As soon as an incoming transfer is included in a block, the API will make it available for you (whether you poll the get transfers endpoint or subscribe to notifications). However, the transfer will have a running status and it will not credit the balance of the associated hosted wallet with the transfer amount until the required number of confirmations has been reached.
At that point the transfer status will change to completed. If you have subscribed to notifications, you will receive a message indicating such status change.
You might want to deem an incoming transfer completed before such a status change and fulfill your business process that depends on that transfer. But note that you will be doing so at your own risk, as you might never actually receive the funds in case there is a reorg before the number of confirmations has been reached.
Please note that waiting for confirmations before crediting a wallet only applies for on-chain transfers, where the source is of type blockchain. Transfers between hosted wallets, where the source is of type wallet do not require waiting on confirmations and are credited instantly.
Did this page help you?
© 2023-2024 Circle Technology Services, LLC. All rights reserved.
