The application-focused Layer 1 for identity, assets and agreements. ArcBlock Chain brings these operations into the protocol, with ABT as the public network’s native token.
An account sends a payment. A creator issues a credential. A service accepts a stake. These actions share an identity system and explicit transaction rules, so applications can work with the same objects.
A DID is a decentralized identifier. On ArcBlock Chain, accounts, tokens, NFTs, stakes and delegations each have a DID. The same address format can identify who acts, what is transferred and which permission is used. An identifier alone does not grant access.
Transfers, token issuance, asset operations and staking have native transaction types. Applications invoke those protocols instead of deploying a separate smart contract for each basic operation. Application logic still decides when to act and which permissions to request. Protocol changes require implementation and network adoption.
A transaction requests an action; a Verifiable Credential (VC) is an issuer’s signed statement. Our architecture direction brings them toward a shared verifiable envelope, while keeping their roles distinct. The shared format is still being designed: a credential does not automatically execute a transaction or become an on-chain record.
ABT belongs to the chain’s token system, alongside tokens issued by applications. Its native role gives it network-specific uses; it does not put it outside the common address, balance and transaction model. Token types and issuer permissions determine how each token can be used.
Interchangeable units recorded as balances. Applications can issue their own tokens for payments and other defined uses.
When two applications need users to transfer the same payment unit between them, a general transferable FT may fit. We recommend starting with a defined service need and considering Credit Tokens first for service allowances.
The public network’s native fungible token: used for network fees, Stake for Gas and payments in applications that accept ABT.
Stake 1 ABT for the public network’s transaction-fee exemption, or pay for a service that accepts ABT. The network and service rules define eligibility and charges.
Application credits or service allowances, governed by issuer-defined minting and spending permissions. Their issuer can have authority to consume credits; do not assume the unrestricted transfer rules of a general-purpose token.
After a customer pays for a service, an application issues image-generation or API-call credits. Authorized services deduct credits as they are used. The application defines the unit, tracks consumption and delivers the service.
The BondingCurveToken protocol calculates minting and burning against a reserve token using a configured curve. It makes that conversion rule explicit in the protocol, rather than leaving it to an application’s private calculation.
A compute service could use a curve to calculate the reserve tokens needed to obtain GPU-time units, based on issued supply. This supports a dynamic resource-service design; capacity measurement, scheduling and delivery remain the service’s responsibility.
Examples illustrate application uses. They do not imply that these services are deployed or that token properties alone deliver the service.
Here, stake ≠ yield. A stake locks tokens to support a declared agreement or qualify for a service. Locking them does not by itself generate a reward. The “X” defines what the stake is for, and the protocol can work with any token, subject to that token’s permissions and the service’s terms.
Specify the purpose, token, amount, the party authorized to deduct staked tokens, and withdrawal delay. Rules also identify where deductions go.
The service recognizes the stake. When the agreed deduction conditions occur, the authorized party can initiate a deduction of part or all of the stake. The locked balance is not freely spendable.
After an unstake request and the required delay, the eligible remainder can be returned. Stake for Gas uses ABT to qualify for a transaction-fee exemption; other services define their own X.
ArcBlock Chain and Ethereum are independent Layer 1 networks. Base is an Ethereum Layer 2. ABT connects these environments through bridging, with a 1:1 token-unit conversion. Native-chain utility and the Ethereum ecosystem’s holding and transfer infrastructure serve complementary roles by design.
L1 · NATIVE ABT
Native ABT · Application payments, Stake for Gas and Stake for X. ABT’s ArcBlock utility is executed on this chain.
L1 · ERC-20
ERC-20 ABT · Holding and transfers through widely supported Ethereum wallets and infrastructure.
ETHEREUM L2
ABT in the Ethereum L2 ecosystem · Bridge-supported movement between networks, under each route’s rules.
1:1 describes token units, not the final amount after fees. Supported routes, confirmations, limits and availability follow the bridge’s current interface and rules. A bridge introduces its own security assumptions; it does not make the networks share consensus.
The ledger architecture separates the original transaction history from the views applications use. Checkpoints summarize ranges of records with hashes, so verification can work against a known checkpoint. A checkpoint proves consistency with that reference, not the truth of every real-world claim.
Append-only transaction history: the record of accepted operations.
Balances, holders and permissions derived by applying the transaction rules.
Searchable views for applications, kept separate from the original history.
