AB

AB: A Modular EVM Network Rebuilding the Newton Project Around Cross-Chain Payments

AB is a blockchain network with its own EVM-compatible core chain, specialized sidechains, and a cross-chain layer designed for payments, tokenized assets, and application-specific deployments. The AB token is used primarily for network fees and infrastructure services, but the project's documents describe narrower holder rights than its broader governance language may suggest.

What AB is building

AB presents itself as the successor to the Newton Project, which began in 2018, and as a modular blockchain system rather than a single-purpose token. Its stated architecture combines AB Core, application-specific sidechains, AB Connect for cross-chain asset movement, and supporting tools such as an explorer and developer documentation. The project identifies payments, Internet of Things applications, gaming, finance, decentralized applications, and real-world asset tokenization as intended use cases. These are project-defined objectives; the public materials reviewed do not independently establish broad adoption in those sectors.

AB Core and the execution model

AB Core is an EVM-compatible blockchain intended to support Ethereum-style contracts, wallets, and developer tools. The official technical documentation lists a three-second block interval, a mainnet chain ID of 36888, and a security convention of 20 block confirmations. The project’s public source repository states that AB Core is based on the Go implementation of Ethereum and uses Proof of Authority consensus with a three-second block interval. That consensus choice is a practical limitation as well as an architectural detail: network operation depends on the validator or authority design, whose composition and controls deserve separate scrutiny.

AB Core is not a current implementation of the full Ethereum protocol. The documentation says it supports Ethereum compatibility through the Berlin hard fork but does not implement EIP-1559 or later upgrades such as Shanghai and Dencun. Developers therefore need to check contract assumptions, tooling behavior, opcode support, and fee logic before treating AB Core as interchangeable with a newer Ethereum-compatible chain. The documentation also exposes public RPC endpoints and a separate testnet, while node deployment instructions are published through a separate repository.

UTP, sidechains, and cross-chain dependencies

A central project mechanism is the Universal Transfer Protocol, or UTP. AB describes it as a protocol for fee abstraction, multi-asset fee settlement, and payments across heterogeneous chains. Its proposed user experience allows recognized assets such as AB and USD1 to be authorized for fee settlement while the protocol handles the underlying gas payment. The design is intended to reduce the need for users to hold native gas tokens, but that convenience introduces dependencies on supported assets, settlement logic, relayers, contracts, and any bridge operators involved.

The project also describes AB Connect as a link between AB Core, dedicated sidechains, and external public networks. AB’s materials refer to sidechains for areas including IoT, payments, gaming, and finance, while the roadmap describes planned or targeted bridge support for AB IoT, Tron, Ethereum, BNB Smart Chain, Solana, and Bitcoin. Roadmap language should not be read as proof that every stated connection or swap function is live. The MiCA whitepaper specifically says that the AB Foundation does not itself operate or control cross-chain bridging services and that independent third parties may support bridge use, making bridge availability and security material external dependencies.

What the AB token does

AB is the native asset of the AB ecosystem and is also issued on AB Core, AB IoT, and BNB Smart Chain. The MiCA whitepaper describes it as a network token used for transaction fees, smart-contract execution, computational and storage resources, decentralized services, and incentives for network participants such as node operators. It records a capped total supply of 100 billion tokens. The practical value of these functions depends on actual network activity, supported applications, liquidity between deployments, and the continued operation of the relevant infrastructure.

There is a meaningful distinction between the project's broad description of governance and the token rights described in its regulatory document. The AB website and litepaper refer to governance mechanisms, while the MiCA whitepaper states that AB does not provide investment, voting, profit-sharing, dividend, ownership, or inherent legal governance rights. Readers should therefore avoid assuming that holding AB automatically grants control over protocol decisions. The published AIP process provides a forum for proposals: anyone may submit an AIP, the AB Foundation assigns its number, and proposals are discussed before a final decision. That demonstrates a governance process, but the documents reviewed do not establish token-weighted voting or permissionless on-chain execution by holders.

Who may use it and what remains unproven

The intended users are developers deploying EVM applications, operators of specialized chains, users moving assets between supported networks, and businesses interested in payment or real-world asset infrastructure. The developer documentation and public code make the network’s basic technical surface more concrete than its commercial claims: there is an EVM-compatible core, a published RPC interface, a public explorer, and open-source node software. By contrast, claims about large-scale community participation, billions of dollars in total value locked, hundreds of projects, or extensive real-world adoption appear in project roadmap or promotional material and should be treated as targets rather than established results.

Key limitations for research

AB’s architecture concentrates risk in several areas. Proof of Authority makes validator selection and operational control important. Cross-chain transfers depend on bridge contracts, relayers, asset representations, and third-party operators. The gap between the advertised multi-chain design and independently observable usage should be monitored rather than assumed. Developers must also account for AB Core’s older Ethereum compatibility level, while users need to distinguish the native AB asset from versions on other networks and verify the correct chain and contract before transacting.

Key takeaways

• AB is a modular blockchain system built around an EVM-compatible core chain, specialized sidechains, and cross-chain infrastructure.
• AB Core uses Proof of Authority consensus, publishes a three-second block interval, and supports Ethereum compatibility only through the Berlin-era feature set.
• The AB token is primarily described as a network and fee asset, with a stated maximum supply of 100 billion tokens.
• UTP is designed to abstract gas payments and support settlement with recognized assets, but its operation depends on protocol components and external bridge infrastructure.
• The AIP system provides a proposal and discussion process, but the reviewed documents do not show that AB holders have automatic token-based governance rights.
• Roadmap ambitions and project claims about adoption, liquidity, and ecosystem scale should be separated from currently verifiable technical infrastructure.

Risks and open questions

• Proof of Authority creates dependence on the validator set, its selection process, and its operational security.
• Cross-chain functionality introduces bridge, relayer, contract, and asset-representation risks; the AB Foundation states that it does not itself control all bridge operators.
• The public documents do not establish broad independent adoption across payments, IoT, gaming, finance, or real-world asset applications.
• AB Core’s support through the Berlin hard fork may create compatibility and tooling limitations for developers expecting newer Ethereum features.
• The AIP process demonstrates proposal administration and community discussion, but token-holder voting power and on-chain execution rights are not established in the reviewed sources.
• AB exists across multiple deployments, so chain identity, contract address, migration status, and liquidity route must be checked before any transaction.