What Is EOS? The Platform, Now Vaulta, Explained

EOSIO originally described the software design used to launch the EOS mainnet in 2018. The historical white paper proposed an account-based application platform with named permission levels, action-specific authority, delegated block production, and a resource model intended to support applications without requiring every user action to look like a conventional per-transaction fee.¹

The software and network later evolved beyond that original document. The current protocol reference describes Vaulta as running Antelope Spring software with the Savanna finality algorithm. That distinction matters: an old EOSIO claim is evidence of the original design, not proof of the network's current code, governance, or performance.²⁷

Vaulta's May 2025 token change replaced EOS with A as the native symbol through a 1:1 swap. Official transition materials say the existing mainnet continued without a fork or reset and that the tokenomics, account state, contracts, and supported infrastructure remained in place. A reader researching EOS today should therefore search both the historical EOS name and the current Vaulta documentation.⁴³

A Vaulta application is built from accounts, actions, transactions, and smart contracts. Contracts expose actions; an application groups one or more actions into a transaction; and the transaction succeeds atomically or the chain restores the prior state. That all-or-nothing behavior is important when several contract operations depend on one another.¹⁰

Contracts are normally written in C++ and compiled to WebAssembly plus an application binary interface. The WebAssembly file contains executable code, while the ABI describes callable actions and data structures. A contract is deployed to an account, so control of that account—and whether its permissions permit upgrades—forms part of the application's security model.¹¹⁸

This differs from Ethereum's address-first mental model. Vaulta accounts have human-readable names and native hierarchical permissions. An authority can combine keys and other accounts with weights and a threshold, and a permission can be linked to a particular contract action. The design can support multisignature operations and separation of duties without every application inventing a new authorization contract.⁸¹

Vaulta uses delegated proof of stake. Holders stake A to vote for block producers, and vote weight is linked to the amount staked for voting. The protocol documentation says a holder may vote for up to 30 candidates, while 21 producers are active at a time and standby producers can enter the schedule when rankings change.⁵

Under Spring and Savanna, block publication and finality are separate functions performed by the elected set. Producers rotate through block-publishing rounds, while finalizers vote continuously. Agreement from 15 of the top 21 producers advances irreversible finality. If enough valid votes are unavailable or conflict, finality stops advancing rather than silently declaring a block irreversible.⁶⁷

Producer authority reaches beyond ordering transactions. Current documentation says the system contract is controlled through a 15-of-21 producer multisignature arrangement. This creates a visible supermajority process for system changes, but it also means decentralization depends on who controls producer votes, whether producers are operationally independent, and how easily token holders can replace them.¹²⁵

The platform meters three resources. CPU represents execution time, NET represents transaction bandwidth, and RAM stores persistent on-chain state. CPU and NET can be rented through the PowerUp model, while RAM is a scarce system resource that accounts purchase for persistent data such as account records and contract tables.⁹⁸

A transaction can feel free to an end user when an application or another account supplies its resources, but the capacity is not economically free. Someone pays for or allocates CPU, NET, and RAM, and a producer still enforces execution limits. This makes sponsored user experiences possible while shifting cost planning to application operators.⁹

The trade-off is operational complexity. Developers must forecast state growth, choose who pays, and design behavior when a payer runs short of resources. Users evaluating a 'no fee' claim should ask who is sponsoring capacity, whether that policy can change, and what happens during congestion.⁹

Start with the current Vaulta protocol and developer documentation, not an EOS-era throughput claim or token article. Then separate four objects: the base protocol, producer governance, the specific application contract, and the asset or service being offered. Each can have a different operator and risk profile.²³