Every ETC transaction follows a specific lifecycle from creation to finality. Understanding this process helps users and developers reason about confirmation times, gas pricing, and transaction reliability.
1. Creation and Signing
The sender constructs a transaction with:
- To: Recipient address (or empty for contract deployment)
- Value: Amount of ETC to transfer
- Data: Input data (empty for simple transfers, calldata for contract interactions)
- Gas limit: Maximum gas the transaction may consume
- Gas price: ETC per unit of gas the sender is willing to pay
- Nonce: Sequential number matching the sender's current nonce
- Chain ID: 61 for ETC mainnet (EIP-155 replay protection)
The transaction is then signed with the sender's private key using ECDSA on the secp256k1 curve.
2. Broadcast
The signed transaction is broadcast to the sender's connected peers. Each peer validates the transaction (valid signature, sufficient balance, correct nonce) and forwards it to their peers. Within seconds, the transaction propagates across the network.
3. Mempool
Each node maintains a transaction pool (mempool) of valid but unconfirmed transactions. The mempool is not consensus-critical — different nodes may have different views of pending transactions.
4. Block Inclusion
Miners select transactions from their mempool to include in the next block, typically prioritizing by gas price (higher price = higher priority). When a miner finds a valid proof-of-work nonce, the block — including the selected transactions — is broadcast to the network.
5. Confirmation
Once included in a block, the transaction has one confirmation. Each subsequent block adds another confirmation. The probability of a transaction being reversed decreases exponentially with each confirmation:
| Confirmations | Security Level |
|---|---|
| 1 | Low (possible reorganization) |
| 6 | Moderate (standard for most transfers) |
| 20 | High (recommended for large amounts) |
| 40+ | Very high (exchange standard) |
6. Finality
Unlike proof-of-stake chains with deterministic finality, ETC uses probabilistic finality. A transaction is never mathematically "final" — but after sufficient confirmations, the cost of reversing it exceeds any rational economic incentive.
Failed Transactions
If a transaction runs out of gas during execution, it reverts — but the gas is still consumed and the transaction appears on-chain as failed. The sender pays for the computation even though the state change was rolled back.