Bring an ERC-20 into CoNET

Evidence level: mixed. TreasuryBridgeV3 and the listed canonical CoNET assets are production references. Route policy, miner quorum, and replay controls are implemented capabilities. Hand-off from a bridged asset into CoNET-DLE is a normative design and is not a production L2 service.

Public site: https://gitbook.conet.network/developers/l1-erc20-bridge.html

An ERC-20 issued on another chain is not a CoNET asset. It enters the ecosystem only through the one production Treasury, TreasuryBridgeV3, on an already enabled route. A caller-supplied token address does not create that route.

Architecture detail: Decentralized cross-chain Treasury.

The only Treasury

Older CREATE2 / BaseTreasury / ConetTreasury addresses (including 0xa311…) are deprecated. Do not document them as a second live Treasury.

The current counterpart chain is Base (chainId 8453) on this same V3 proxy. That is a governed CoNET ↔ Base route, not a permissionless bridge.

Two developer jobs

ERC-20 on a supported external chain
        │  enabled Treasury route + miner quorum
        ▼
Treasury-canonical ERC-20 on CoNET L1
        │  wallets, Explorer, applications use this address
        │
        └── optional later DLE admission  ← not live

How an enabled route works

user-authorized source operation
        │
        ▼
configured Treasury route
        │  one operationId-bound payload
        ▼
independent source observation
        │
        ▼
destination miner votes
        │  threshold = ceil(2N / 3)
        ▼
execute exactly once
        ├── mint configured destination asset
        └── or release configured reserve

The destination contract rejects a disabled route, conflicting payloads, duplicate miner votes, failed quorum, beneficiary sums that do not match the gross amount, and a replayed operationId.

These controls decentralize authorization across the configured miner set. They do not prove operator independence, source-chain finality, or that upgrade keys cannot be compromised.

Use a current product path (Base USDC)

Current public product paths use pre-registered assets. The live example is Base USDC → conet-USDC via LockMint on Treasury V3.

Application wallets (for example Beamio) submit the user-authorized source lock through the existing relay. This book does not invent a second public mint API. Integrate against:

• the proxy address above (read treasury() / route state from chain, do not hard-code a deprecated treasury);
• CoNET RPC https://rpc1.conet.network (backup https://publicrpc.conet.network);
• Base RPC https://base-rpc.conet.network for the source lock;
• Explorer https://mainnet.conet.network for the canonical token.

After a successful destination execution, balances live on the CoNET ERC-20 (conet-USDC or the route’s configured token). Do not display the Base contract as the CoNET balance.

Admit a new ERC-20 (policy, not a send)

“Bridge any ERC-20 to CoNET” is not a supported operation until all of the following exist:

1. Source identity — exact chainId, token contract, decimals, and finality depth.
2. Custody mode — LockMint, BurnMint, and any reverse BurnRelease, conserving exact raw units.
3. Canonical CoNET representation — a stable CoNET token with bounded mint/burn roles.
4. Treasury policy — the exact route and version enabled by the configured owner / governance path.
5. Replay domain — unique operationId, nonce, source transaction hash, destination execution flag.
6. Relayer and miner availability — enough independent observers to reach ceil(2N / 3).
7. Exit capacity — locked reserves or replacement-capacity accounting.
8. Application admission — wallets, Explorer, and indexers recognize the CoNET address.

Until those are met, a developer should not tell users to transfer a foreign token to the Treasury and expect a mint.

Read the live quorum

Treasury miners are not the Guardian owner list.

RPC=https://rpc1.conet.network
T=0xa208982212978550594A7FEEB70a61665d129003

cast call $T "miners()(address[])" --rpc-url $RPC
cast call $T "requiredVotes()(uint256)" --rpc-url $RPC
cast call $T "owner()(address)" --rpc-url $RPC

A reproduced snapshot (re-read for a current figure) is in L1 decentralization: four miner addresses, quorum 3, and owner() equal to one miner.

import { ethers } from 'ethers'

const CONET_RPC = 'https://rpc1.conet.network'
const TREASURY = '0xa208982212978550594A7FEEB70a61665d129003'

const abi = [
  'function miners() view returns (address[])',
  'function requiredVotes() view returns (uint256)',
  'function owner() view returns (address)',
]

export async function readTreasuryQuorum() {
  const c = new ethers.Contract(TREASURY, abi, new ethers.JsonRpcProvider(CONET_RPC))
  const [miners, requiredVotes, owner] = await Promise.all([
    c.miners(),
    c.requiredVotes(),
    c.owner(),
  ])
  return { miners, requiredVotes: Number(requiredVotes), owner }
}

Confirm eth_chainId is 0x36ca6 before treating the result as CoNET L1. A failed RPC is untrusted: keep the last successful read.

After CoNET L1: DLE is a second machine

A successful Treasury mint does not create a DLE asset tip, activate L2 backing, or pass pool / TWAP / gateway gates.

canonical ERC-20 on CoNET L1
        │
        ├── usable by enabled L1 applications today
        │
        └── future DLE admission + burn/activation
                 │ AssetAdmissionRegistry = ACTIVE
                 │ approved pool + TWAP adapter
                 │ AssetBurnMintGateway safety gates
                 ▼
          parallel DLE asset tips

That second transition is specified, not deployed. See L2 development and Cross-chain assets in DLE.

Related

• Decentralized cross-chain Treasury
• Core L1 assets
• RPC and Explorer
• Miner-matched order-book exchange — design study on top of canonical assets

Next

L2 development →