Stablecoins on ERC20: How USDC, USDT, and DAI Work

Open the contract for USDC, USDT, or DAI on Etherscan and the first thing you notice is how much code sits on top of the ERC20 interface. The plain standard is roughly 80 lines. The real production contracts run into the thousands.

That extra surface is where the engineering decisions live. Who can mint. Who can burn. Who can freeze a balance. Whether the contract can be paused or upgraded. Whether transfers go through a fee hook. Each of those decisions shapes how the stablecoin behaves under stress.

If you are integrating a stablecoin into a payment rail, a lending market, or an on chain settlement system, the brand on the token is almost beside the point. What matters is the contract surface you are agreeing to call into. This post walks through three representative stablecoins — USDC, USDT, and DAI — and shows the exact ERC20 extensions each one ships.

When a corporate treasury wires one million dollars to Circle, three things happen. The fiat lands in a partner bank. Circle confirms the reserves. A minter wallet calls the mint function on the FiatTokenV2 contract, which adds one million USDC to the recipient address and bumps total supply by the same amount.

The redeem path runs in reverse. The user transfers USDC back to Circle. Circle calls burn on the contract, which subtracts the balance and reduces total supply. The bank releases fiat to the user. The on chain supply tracks the off chain reserve dollar for dollar.

The mint function itself is a thin wrapper around the ERC20 internal balance update. The interesting code is the access control and the minter allowance system that prevents any single key from inflating supply unilaterally.

// Simplified mint flow used by USDC (FiatTokenV2_2)
function mint(address _to, uint256 _amount)
    external
    whenNotPaused
    onlyMinters
    notBlacklisted(msg.sender)
    notBlacklisted(_to)
    returns (bool)
{
    require(_to != address(0), "ERC20: mint to the zero address");
    require(_amount > 0, "FiatToken: mint amount not greater than 0");

    uint256 mintingAllowedAmount = minterAllowed[msg.sender];
    require(_amount <= mintingAllowedAmount, "FiatToken: mint amount exceeds minterAllowance");

    totalSupply_ = totalSupply_ + _amount;
    _setBalance(_to, _balanceOf(_to) + _amount);
    minterAllowed[msg.sender] = mintingAllowedAmount - _amount;

    emit Mint(msg.sender, _to, _amount);
    emit Transfer(address(0), _to, _amount);
    return true;
}

The minterAllowed mapping is what keeps the system safe from a compromised minter key. Circle assigns each minter wallet a finite allowance. The wallet can mint up to that allowance and then needs to be topped up by a higher privileged controller. A leaked minter key can drain its current allowance but not infinitely inflate supply.

Regulators expect stablecoin issuers to comply with sanctions lists. The way that compliance ships in code is a blacklist mapping plus a modifier injected into the transfer path. Once an address is blacklisted, every transfer touching it reverts.

// Address freeze hook — every transfer routes through this
modifier notBlacklisted(address _account) {
    require(!_blacklisted[_account], "FiatToken: account is blacklisted");
    _;
}

function blacklist(address _account) external onlyBlacklister {
    _blacklisted[_account] = true;
    emit Blacklisted(_account);
}

// Override of ERC20 transfer adds the gate at the contract layer
function _transfer(address from, address to, uint256 value)
    internal
    override
    notBlacklisted(from)
    notBlacklisted(to)
{
    super._transfer(from, to, value);
}

That modifier sits on transfer, transferFrom, mint, and burn. So if your protocol holds USDC on behalf of a user and either the sender or the receiver gets blacklisted between transactions, the funds sit frozen. You cannot move them. You cannot return them. The only path forward is the issuer removing the blacklist entry.

The pause function is more dramatic. It freezes every transfer on the entire contract until a controller wallet unpauses it. USDC was paused once in production, during the bank stress event that briefly broke the peg. Lending markets that had not modeled a paused USDC behaved unpredictably for a few hours.

A user opens a vault, deposits ETH or another approved collateral, and draws DAI against it up to a collateralization ratio of around 150 percent. The DAI token itself is dead simple — it is the surrounding system that does the work.

The Vat is the central accounting ledger. Urns are individual vaults. Ilks are the collateral types. Adapters called Joins move ERC20 tokens in and out of the Vat. The DaiJoin adapter is the one piece that mints and burns DAI on the ERC20 contract proper.

// MakerDAO Vault open + draw (very simplified, real flow uses CDP Manager)
function openVault(bytes32 ilk, uint256 wadCollateral, uint256 wadDai) external {
    // 1. Deposit collateral into the GemJoin adapter
    gemJoin.join(address(this), wadCollateral);

    // 2. Adjust the urn (vault) inside the Vat: add collateral, draw debt
    vat.frob(
        ilk,
        address(this), // urn
        address(this), // collateral source
        address(this), // dai destination
        int256(wadCollateral),
        int256(wadDai)
    );

    // 3. Pull DAI out through the DaiJoin adapter
    daiJoin.exit(msg.sender, wadDai);
}

When a user repays DAI plus the stability fee, the flow reverses. The DaiJoin adapter burns the returned DAI, the Vat reduces the urn debt, and the GemJoin releases the collateral. If the collateral price drops below the safety threshold, keepers liquidate the vault by buying the collateral at a discount in exchange for the DAI debt.

For a payment rail, the lower complexity of USDT is appealing until you remember the single owner key. For a programmable money primitive that needs no off chain trust, DAI is the only candidate. For broad merchant acceptance and clear regulatory posture, USDC is the default. Most production protocols end up integrating two or three of these because each user segment leans different.

The deeper integration patterns — multi stablecoin routing, peg break circuit breakers, atomic redemption flows — are protocol design questions. They sit on top of the ERC20 surface but are not part of it. The ERC standards explainer covers the wider ERC family that stablecoins increasingly compose with.

If you are designing a payment rail, a custody system, or a lending protocol that holds user stablecoin balances, the right starting point is to read the actual contract source for every token you plan to support. Map the privileged roles. Write integration tests that simulate the freeze and pause paths. Document the blast radius.

We help teams ship production grade smart contract systems that integrate with major stablecoins, including the operational surface most tutorials skip. If you are evaluating a stablecoin integration for an exchange, treasury, or DeFi protocol, the contract review is the cheapest insurance you can buy.