EOS Blockchain Development in 2026: Building on Vaulta and Antelope

The EOS blockchain rebranded as Vaulta in 2025, and its token changed from EOS to A at a 1:1 ratio, but the technology underneath stayed the same Antelope stack. This guide explains how EOS blockchain development works today for teams that maintain an old EOS dApp or consider Vaulta for a new one.

From EOS to Antelope to Vaulta

EOS launched in 2018 on EOSIO software from Block.one. After the community split from Block.one, the EOS Network Foundation took over the project, forked the code and renamed it Antelope. Other chains, such as Telos, WAX and Ultra, also run Antelope.

The node software moved from Leap to Spring. Spring 1.0 introduced the Savanna consensus algorithm, which brought finality down to about one second.

In 2025 the network rebranded as Vaulta and moved toward banking and financial applications. The Vaulta documentation lists these changes for developers:

A contract that accepts EOS transfers must add a handler for core.vaulta::transfer notifications to accept A. A contract that should reject A can check which token contract sent the notification. Tutorials that mention EOSIO, eosio.cdt or deferred transactions are outdated.

How the EOS blockchain works

Accounts and permissions

Accounts have readable names of up to 12 characters, such as payroll.app, instead of hex addresses, using lowercase letters a to z, digits 1 to 5 and periods. Creating an account costs tokens, because the new account needs RAM.

Every account has two base permissions, owner and active. Each permission lists keys or other accounts, each with a weight, and sets a threshold. Multisig and delegated control are therefore built into the account system.

An account can add custom permissions under active and link each one to a specific contract action, so a hot key can call one action while the owner key stays offline. Business apps use this to separate daily operations from account control.

Resources instead of gas

• RAM stores all chain state: balances, contract code and contract data. Accounts buy RAM from the system contract and can sell it back, at a price set by a Bancor formula, so RAM costs more as free RAM runs low. Each table write names the account that pays for the RAM.
• CPU measures execution time in microseconds, and NET measures transaction size in bytes. Through the PowerUp model, accounts rent CPU and NET for 24 hours and pay in A.

An application can pay resources for its users, so users can act without holding the token. EOS used this feature as its main user-experience advantage. The application then has to budget its resources, and a busy dApp can run out of CPU during peak traffic.

Writing EOS smart contracts

Developers write contracts in C++ with the Contract Development Toolkit (CDT) and compile them to WebAssembly. A contract defines actions, which are its entry points, and stores data in multi-index tables scoped by account. One contract calls another through inline actions, which run inside the same transaction.

Follow these practices:

• Call require_auth in every action that changes state for an account.
• State who pays RAM for each table write, or users can face surprise charges, or an attacker can drain the contract's RAM.
• Check which contract sent each incoming transfer notification, because fake token contracts that sent spoofed notifications caused known exploits on EOS.
• Expect the account owner to be able to upgrade the contract. To make a contract immutable, change the account's permissions to remove that power, and announce the change.

Some community tools support Rust, but C++ with CDT is the main supported path. Local development uses nodeos (the node), cleos (the command-line tool) and container-based setups. JavaScript front ends usually use WharfKit for sessions and wallets, and Anchor is the established wallet.

Vaulta EVM

Vaulta also runs an EVM-compatible layer where Solidity contracts deploy with standard Ethereum tools, such as Hardhat, ethers and MetaMask. The EVM layer connects to the native layer, so assets can move between the two.

Ethereum developers can use Vaulta EVM without learning C++ or the Antelope resource model. Teams that know Solidity and want Vaulta's users or partners usually start there. The general practices in Solidity development apply.

When EOS blockchain development fits

Vaulta suits applications that need fast finality, account-level permissions and app-paid resources. The rebrand targets payments and banking-related apps.

Vaulta does not suit apps that need deep DeFi liquidity, a large pool of auditors or many ready-made integrations, since Ethereum and its layer 2 networks lead on all three. Before you commit, check developer activity, wallet support and exchange listings for the A token.

For other chains with their own contract models, see Tezos blockchain and Polkadot development. For dApp design in general, see dApp development.

Typical build process

1. Choose between native C++ contracts and Vaulta EVM.
2. Design accounts, permissions and resource payment for each action.
3. Write contracts with CDT, and test them on a local node, then on the public testnet.
4. Build the front end with WharfKit and wallet support.
5. Audit the contracts, deploy them, and put owner permissions under multisig.

Frequently asked questions