Exzo Network Whitepaper

A Safe, Scalable, and Upgradeable layer-1 Web3 Infrastructure featuring full EVM compatibility & Real-Time Transactions.


This paper discusses the key implementation details, in particular the token economics (tokenomics), of the native token of the Exzo Network platform, called Exzo (XZO). The native token secures the network, pays for fees, and provides the basic unit of account between the multiple cross-chain token bridges deployed on other blockchain networks. For additional details on Exzo Network, which serves as a versatile and universal platform, allowing anyone to launch new blockchains with their own rules, virtual machines, and validator sets.

1.0 Introduction

The exponential progression of the internet and mobile broadband has connected billions of people globally, providing access to knowledge, freedom of communication, and a broad range of lower-cost, more convenient services. This connectivity through technology has enabled more people to access and utilize the financial and data driven ecosystem. Yet, regardless of these advancements the lack of liquidity, data privacy, security, and scalability of transactions has been limited or under-regulated.
Exzo Network is a decentralized permissionless layer-1 blockchain and smart contract platform biased towards low-latency management of assets. It utilizes the Solidity programming language to define assets as objects that may be owned by an address.
Solidity programs define operations on these typed objects including custom rules for their creation, the transfer of these assets to new owners, and operations that mutate assets. The Exzo Network is maintained by a permissionless set of node validators that play a role similar to miners in other blockchain systems. It uses a Proof-of-Stake (PoS) BFT consensus protocol between node validators to ensure the safety of common operations on assets, ensuring lower latency and better scalability.
It only relies on Byzantine agreement for the safety of shared objects. As well as governance operations and check-pointing, performed off the critical latency path. Execution of smart contracts is also naturally parallelized when possible. The Exzo Network supports light clients that can authenticate reads as well as full clients that may audit all transitions for integrity. These facilities allow for trust-minimized bridges to other blockchains.
A native digital commodity called Exzo (XZO) is used to pay for gas for all operations. It is also used by its owners to operate node validation or delegation processes to operate the Exzo Network within epochs, and periodically, validators are reconfigured according to the stake delegated to them. Used gas is distributed to validators and their delegates according to their stake and their contribution to the operation of the Exzo Network.
The mission of the Exzo Network is to change this state of affairs by proposing a new methodology to scaling blockchain solutions and implementing methods of building more liquidity reserves for the liquidation of on chain assets. In this paper, we present to you the Exzo Network, a new layer-1 Proof-of-Stake (PoS) blockchain network providing real-time transactions, enhanced settlement, data privacy that maintains compliance with regulators, and enhanced liquidity through the automation of decentralized finance (DeFi) with “money robots” that work to maximize returns for a fee. The Exzo Network enables the implementation of the Ethereum Virtual Machine (EVM) compatible smart contracts in the protocol for better developer onboarding and scalability through pre-built toolsets.

To introduce the Exzo Network, we:

  1. 1.
    Describe the challenges of representing digital assets, data privacy, B2B & P2P payments, and settlement on a blockchain network.
  2. 2.
    Explain how our design for the Exzo Network addresses these challenges.
  3. 3.
    Give an example-oriented overview of the Exzo Network's key features and infrastructure model.
  4. 4.
    Dig into the technical details of the consensus, Proof-of-Stake protocol, governance, token economy and virtual machine design.
  5. 5.
    Conclude by summarizing the progress we have made on the Exzo Network, describing our plans for language evolution, and outlining our roadmap for supporting third-party Move code on the Libra Blockchain.

1.1 Challenges of Representing Digital Assets

The current age of digital assets has had revolutionary changes with the introduction of Web3 technology in the way payments can be processed across borders, data stored and managed, and the way businesses in finance, healthcare, and other industries can provide products or services.
A major inhibiting factor to this area is the lack of safely enabling users to store and manage their digital assets in a non-custodial and decentralized manner due to the many risks users hold when managing their own private keys or seed phrases.
Additionally, when representing digital currencies many vulnerabilities have been found within network protocol's enabling individuals to steal funds from smart contracts or users wallets due to these programmatic vulnerabilities leading to a loss of funds for users and protocols.
While the above pressing issues are currently present another issue is present as well where the cost of transactions can become high during periods of high transaction volume from block miners due to the computational power required to process these blocks in the traditional Proof-of-Work (PoW) consensus mechanisms.

2.0 Exzo Network

The intent of the Exzo Network is to create an alternative protocol for building decentralized applications, providing a different set of tradeoffs that are believed to be very useful for a large class of decentralized applications, with particular emphasis on situations where real-time transactions, affordability, security, scaling, and the ability of different applications to very efficiently interact, are important. Exzo Network does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions.
A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.
While providing the security and scalability of a Proof-of-Stake (PoS) consensus mechanisms that enables lower energy consumption, affordable real-time transactions, and decentralization for a true community driven protocol that can scale up to ~65,000 transactions per second (TPS) that can provide emerging Web3, Finance, and Metaverse projects with the throughput needed to scale as they grow.

2.1 Philosophy

The design behind Exzo Network is intended to follow the following principles:
  1. 1.
    Simplicity: the Exzo Network protocol should be as simple as possible, even at the cost of some data storage or time inefficiency. An average programmer should ideally be able to follow and implement the entire specification, so as to fully realize the unprecedented democratizing potential that cryptocurrency brings and further the vision of Exzo Network as a protocol that is open to all with the intent to provide interoperability between existing protocols and programming languages.
  2. 2.
    Interoperability: a fundamental part of Exzo Network's design philosophy is that Exzo Network does not have "features". Instead, Exzo Network provides an internal Turing-complete scripting language, which a programmer can use to construct any smart contract or transaction type that can be mathematically defined. Want to invent your own financial derivative? With Exzo Network, you can. Want to make your own currency? Set it up as an Exzo Network smart contract. Want to set up a full-scale Daemon or Skynet? You can. The purpose is to enable cross-chain interoperability and simplicity for developing upon several different frameworks and technologies.
  3. 3.
    Agility: details of the Exzo Network protocol are not set in stone. Although the community will be extremely judicious about making modifications to high-level constructs, for instance with the Proof-of-Stake consensus algorithm , abstracting execution, with only data availability enshrined in consensus. Computational tests later on in the development process may lead us to discover that certain modifications, e.g. to the protocol architecture or to the integrated Ethereum Virtual Machine (EVM), will substantially improve scalability or security. If any such opportunities are found, we will exploit them.
  4. 4.
    Non-discrimination and non-censorship: the protocol should not attempt to actively restrict or prevent specific categories of usage. All regulatory mechanisms in the protocol should be designed to directly regulate the harm and not attempt to oppose specific undesirable applications. A programmer can even run an infinite loop script on top of Exzo Network for as long as they are willing to keep paying the transaction fee set by node validators or users.

3.0 Applications

In general, there are four types of applications built on top of the Exzo Network. The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money through tokenization. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts.
The second category is semi-financial applications, where money is involved but there is also a non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems.
The third category is non-financial applications where money can be involved but it constitutes ownership rights of digital assets or digital assets backed by real-world assets using smart contracts. For example categories such as art, music, playing cards, memberships and data utilize non-fungible tokens (NFT's) for use within this class of assets or ownership. Projects using Web3 technology such as Metaverse projects or NFT gaming or NFT marketplaces utilize these types of smart contracts.
Finally, there are applications such as online voting and decentralized governance that are not financial at all, but benefit community driven projects.

3.1 Token Systems

On-chain token systems have many applications ranging from sub-currencies representing assets such as USD or gold to company stocks, individual tokens representing smart property, secure unforgeable coupons, and even token systems with no ties to conventional value at all, used as point systems for incentivization.
Token systems are surprisingly easy to implement on the Exzo Network. The key point to understand is that a currency, or token system, fundamentally is a database with one operation: subtract X units from A and give X units to B, with the provision that A had at least X units before the transaction and (2) the transaction is approved by A. All that it takes to implement a token system is to implement this logic into a smart contract as you can see in section 4.2.
This is essentially a literal implementation of the "banking system" state transition function described further above in this document. But that's all there is to it. Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency.
The way this would be implemented is that the contract would maintain an XZO balance with which it would refund XZO used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to "activate" their accounts with XZO, but once the XZO is there it would be reusable because the contract would refund it each time.

3.2 Financial derivatives and Stable-Coin Currencies

Financial derivatives are the most common application of a "smart contract", and one of the simplest to implement in code. The main challenge in implementing financial contracts is that the majority of them require reference to an external price ticker; for example, a very desirable application is a smart contract that hedges against the volatility of ether (or another cryptocurrency) with respect to the US dollar, but doing this requires the contract to know what the value of XZO/USD is.
The simplest way to do this is through a "data feed" contract maintained by a specific party (eg. NASDAQ) designed so that that party has the ability to update the contract as needed, and providing an interface that allows other contracts to send a message to that contract and get back a response that provides the price.
Given that critical ingredient, the hedging contract would look as follows:
  1. 1.
    Wait for party A to input 1000 XZO.
  2. 2.
    Wait for party B to input 1000 XZO.
  3. 3.
    Record the USD value of 1000 XZO, calculated by querying the data feed contract, in storage, say this is $x.
  4. 4.
    After 30 days, allow A or B to "reactivate" the contract in order to send $x worth of XZO (calculated by querying the data feed contract again to get the new price) to A and the rest to B.
Such a contract would have significant potential in crypto-commerce. One of the main problems cited about cryptocurrency is the fact that it's volatile; although many users and merchants may want the security and convenience of dealing with cryptographic assets, they may not wish to face that prospect of losing 23% of the value of their funds in a single day.
Up until now, the most commonly proposed solution has been issuer-backed assets; the idea is that an issuer creates a sub-currency in which they have the right to issue and revoke units, and provide one unit of the currency to anyone who provides them (offline) with one unit of a specified underlying asset (eg. gold, USD). The issuer then promises to provide one unit of the underlying asset to anyone who sends back one unit of the crypto-asset. This mechanism allows any non-cryptographic asset to be "uplifted" into a cryptographic asset, provided that the issuer can be trusted.
In practice, however, issuers are not always trustworthy, and in some cases the banking infrastructure is too weak, or too hostile, for such services to exist. Financial derivatives provide an alternative.
Here, instead of a single issuer providing the funds to back up an asset, a decentralized market of speculators, betting that the price of a cryptographic reference asset (eg. XZO) will go up, plays that role. Unlike issuers, speculators have no option to default on their side of the bargain because the hedging contract holds their funds in escrow. Note that this approach is not fully decentralized, because a trusted source is still needed to provide the price ticker, although arguably even still this is a massive improvement in terms of reducing infrastructure requirements (unlike being an issuer, issuing a price feed requires no licenses and can likely be categorized as free speech) and reducing the potential for fraud.

3.3 Decentralized File Storage

Over the past few years, there have emerged a number of popular online file storage startups, the most prominent being Dropbox, seeking to allow users to upload a backup of their hard drive and have the service store the backup and allow the user to access it in exchange for a monthly fee. However, at this point the file storage market is at times relatively inefficient; a cursory look at various existing solutions shows that, particularly at the "uncanny valley" 20-200 GB level at which neither free quotas nor enterprise-level discounts kick in, monthly prices for mainstream file storage costs are such that you are paying for more than the cost of the entire hard drive in a single month. Exzo Network contracts can allow for the development of a decentralized file storage ecosystem, where individual users can earn small quantities of money by renting out their own hard drives and unused space can be used to further drive down the costs of file storage.
The key underpinning piece of such a device would be what we have termed the "decentralized Dropbox contract". This contract works as follows. First, one splits the desired data up into blocks, encrypting each block for privacy, and builds a Merkle tree out of it. One then makes a contract with the rule that, every N blocks, the contract would pick a random index in the Merkle tree (using the previous block hash, accessible from contract code, as a source of randomness), and give X ether to the first entity to supply a transaction with a simplified payment verification-like proof of ownership of the block at that particular index in the tree. When a user wants to re-download their file, they can use a micropayment channel protocol (eg. pay 1 XZO per 32 kilobytes) to recover the file; the most fee-efficient approach is for the payer not to publish the transaction until the end, instead replacing the transaction with a slightly more lucrative one with the same nonce after every 32 kilobytes.
An important feature of the protocol is that, although it may seem like one is trusting many random nodes not to decide to forget the file, one can reduce that risk down to near-zero by splitting the file into many pieces via secret sharing, and watching the contracts to see each piece is still in some node's possession. If a contract is still paying out money, that provides a cryptographic proof that someone out there is still storing the file.

4.0 Exzo Smart Contract Programming

Exzo Network smart contracts are written in the Solidity[6] programming language. Solidity is safe and expressive, and its type system and data model naturally support the parallel agreement/execution strategies that makes the Exzo Network scalable. Solidity is an open-source programming language for building smart contracts originally developed by the Ethereum team. The language is platform-agnostic, and in addition to being adopted by the Exzo Network, it has been gaining popularity on other platforms (e.g., Polygon, Avalanche, Fantom). In this section we will discuss the main features of the Solidity language and explain how it is used to create and manage assets on the Exzo Network. A more thorough explanation of Solidity's features can be found on the OpenZeppelin website[5] and more Exzo-specific Solidity content can be found in the Exzo Network Developer Portal, and a more formal description of Solidity in the context of Exzo can be found in the online Exzo Network developer documentation[2].

4.1 Object Storage

// SPDX-License-Identifier: GPL-3.0
pragma solidity >=0.4.16 <0.9.0;
contract SimpleStorage {
uint storedData;
function set(uint x) public {
storedData = x;
function get() public view returns (uint) {
return storedData;
A contract in the sense of Solidity is a collection of code (its functions) and data (its state) that resides at a specific address on the Exzo Network blockchain. The line uint storedData; declares a state variable called storedData of type uint (unsigned integer of 256 bits). You can think of it as a single slot in a database that you can query and alter by calling functions of the code that manages the database. In this example, the contract defines the functions set and get that can be used to modify or retrieve the value of the variable.
To access a member (like a state variable) of the current contract, you do not typically add the this. prefix, you just access it directly via its name. Unlike in some other languages, omitting it is not just a matter of style, it results in a completely different way to access the member.

4.2 Digital Currency Example

The following contract implements a very simple form of a cryptocurrency. The contract allows only its creator to create new coins (different issuance schemes are possible). Anyone can send coins to each other without a need for registering with a username and password, all you need is an Exzo Network keypair.
// SPDX-License-Identifier: GPL-3.0
pragma solidity ^0.8.4;
contract Coin {
// The keyword "public" makes variables
// accessible from other contracts
address public minter;
mapping (address => uint) public balances;
// Events allow clients to react to specific
// contract changes you declare
event Sent(address from, address to, uint amount);
// Constructor code is only run when the contract
// is created
constructor() {
minter = msg.sender;
// Sends an amount of newly created coins to an address
// Can only be called by the contract creator
function mint(address receiver, uint amount) public {
require(msg.sender == minter);
balances[receiver] += amount;
// Errors allow you to provide information about
// why an operation failed. They are returned
// to the caller of the function.
error InsufficientBalance(uint requested, uint available);
// Sends an amount of existing coins
// from any caller to an address
function send(address receiver, uint amount) public {
if (amount > balances[msg.sender])
revert InsufficientBalance({
requested: amount,
available: balances[msg.sender]
balances[msg.sender] -= amount;
balances[receiver] += amount;
emit Sent(msg.sender, receiver, amount);
The line address public minter; declares a state variable of type address. The address type is a 160-bit value that does not allow any arithmetic operations. It is suitable for storing addresses of contracts, or a hash of the public half of a keypair belonging to external accounts.
The keyword public automatically generates a function that allows you to access the current value of the state variable from outside of the contract. Without this keyword, other contracts have no way to access the variable. The code of the function generated by the compiler is equivalent to the following (ignore external and view for now):
function minter() external view returns (address) { return minter; }
You could add a function like the above yourself, but you would have a function and state variable with the same name. You do not need to do this, the compiler figures it out for you.
The next line, mapping (address => uint) public balances; also creates a public state variable, but it is a more complex datatype. The mapping type maps addresses to unsigned integers.
Mappings can be seen as hash tables which are virtually initialized such that every possible key exists from the start and is mapped to a value whose byte-representation is all zeros. However, it is neither possible to obtain a list of all keys of a mapping, nor a list of all values. Record what you added to the mapping, or use it in a context where this is not needed. Or even better, keep a list, or use a more suitable data type.
The getter function created by the public keyword is more complex in the case of a mapping. It looks like the following:
function balances(address account) external view returns (uint) {
return balances[account];
You can use this function to query the balance of a single account.
The line event Sent(address from, address to, uint amount); declares an “event”, which is emitted in the last line of the function send. Ethereum clients such as web applications can listen for these events emitted on the blockchain without much cost. As soon as it is emitted, the listener receives the arguments from, to and amount, which makes it possible to track transactions.
To listen for this event, you could use the following JavaScript code, which uses web3.js to create the Coin contract object, and any user interface calls the automatically generated balances function from above:
Coin.Sent().watch({}, '', function(error, result) {
if (!error) {
console.log("Coin transfer: " + result.args.amount +
" coins were sent from " + result.args.from +
" to " + + ".");
console.log("Balances now:\n" +
"Sender: " + +
"Receiver: " +;
The constructor is a special function that is executed during the creation of the contract and cannot be called afterwards. In this case, it permanently stores the address of the person creating the contract. The msg variable (together with tx and block) is a special global variable that contains properties which allow access to the blockchain. msg.sender is always the address where the current (external) function call came from.
The functions that make up the contract, and that users and contracts can call are mint and send.
The mint function sends an amount of newly created coins to another address. The require function call defines conditions that reverts all changes if not met. In this example, require(msg.sender == minter); ensures that only the creator of the contract can call mint. In general, the creator can mint as many tokens as they like, but at some point, this will lead to a phenomenon called “overflow”. Note that because of the default Checked arithmetic, the transaction would revert if the expression balances[receiver] += amount; overflows, i.e., when balances[receiver] + amount in arbitrary precision arithmetic is larger than the maximum value of uint (2**256 - 1). This is also true for the statement balances[receiver] += amount; in the function send.
Errors allow you to provide more information to the caller about why a condition or operation failed. Errors are used together with the revert statement. The revert statement unconditionally aborts and reverts all changes similar to the require function, but it also allows you to provide the name of an error and additional data which will be supplied to the caller (and eventually to the front-end application or block explorer) so that a failure can more easily be debugged or reacted upon.
The send function can be used by anyone (who already has some of these coins) to send coins to anyone else. If the sender does not have enough coins to send, the if condition evaluates to true. As a result, the revert will cause the operation to fail while providing the sender with error details using the InsufficientBalance error.

4.3 Accounts

There are two kinds of accounts on the Exzo Network which share the same address space: External accounts that are controlled by public-private key pairs (i.e. humans) and contract accounts which are controlled by the code stored together with the account.
The address of an external account is determined from the public key while the address of a contract is determined at the time the contract is created (it is derived from the creator address and the number of transactions sent from that address, the so-called “nonce”).
Regardless of whether or not the account stores code, the two types are treated equally by the EVM.
Every account has a persistent key-value store mapping 256-bit words to 256-bit words called storage.
Furthermore, every account has a balance in Ether (in “Wei” to be exact, 1 ether is 10**18 wei) which can be modified by sending transactions that include Ether.

4.4 Transactions

A transaction is a message that is sent from one account to another account (which might be the same or empty, see below). It can include binary data (which is called “payload”) and Ether.
If the target account contains code, that code is executed and the payload is provided as input data.
If the target account is not set (the transaction does not have a recipient or the recipient is set to null), the transaction creates a new contract. As already mentioned, the address of that contract is not the zero address but an address derived from the sender and its number of transactions sent (the “nonce”). The payload of such a contract creation transaction is taken to be EVM bytecode and executed. The output data of this execution is permanently stored as the code of the contract. This means that in order to create a contract, you do not send the actual code of the contract, but in fact code that returns that code when executed.

4.5 Gas

Upon creation, each transaction is charged with a certain amount of gas that has to be paid for by the originator of the transaction (tx.origin). While the EVM executes the transaction, the gas is gradually depleted according to specific rules. If the gas is used up at any point (i.e. it would be negative), an out-of-gas exception is triggered, which ends execution and reverts all modifications made to the state in the current call frame.
This mechanism incentivizes economical use of EVM execution time and also compensates EVM executors (i.e. miners / stakers) for their work. Since each block has a maximum amount of gas, it also limits the amount of work needed to validate a block.
The gas price is a value set by the originator of the transaction, who has to pay gas_price * gas up front to the EVM executor. If some gas is left after execution, it is refunded to the transaction originator. In case of an exception that reverts changes, already used up gas is not refunded.
Since EVM executors can choose to include a transaction or not, transaction senders cannot abuse the system by setting a low gas price.

4.6 Storage, Memory, and Stack

Exzo Network utilizes the flexibility of the Ethereum Virtual Machine (EVM) to enable scalability during development with a set of pre-built tools developers are already familiar with for the ease of converting over to the Exzo Network without having to learn a whole new technology stack.
The Ethereum Virtual Machine has three areas where it can store data: storage, memory and the stack.
Each account has a data area called storage, which is persistent between function calls and transactions. Storage is a key-value store that maps 256-bit words to 256-bit words. It is not possible to enumerate storage from within a contract, it is comparatively costly to read, and even more to initialize and modify storage. Because of this cost, you should minimize what you store in persistent storage to what the contract needs to run. Store data like derived calculations, caching, and aggregates outside of the contract. A contract can neither read nor write to any storage apart from its own.
The second data area is called memory, of which a contract obtains a freshly cleared instance for each message call. Memory is linear and can be addressed at byte level, but reads are limited to a width of 256 bits, while writes can be either 8 bits or 256 bits wide. Memory is expanded by a word (256-bit), when accessing (either reading or writing) a previously untouched memory word (i.e. any offset within a word). At the time of expansion, the cost in gas must be paid. Memory is more costly the larger it grows (it scales quadratically).
The EVM is not a register machine but a stack machine, so all computations are performed on a data area called the stack. It has a maximum size of 1024 elements and contains words of 256 bits. Access to the stack is limited to the top end in the following way: It is possible to copy one of the topmost 16 elements to the top of the stack or swap the topmost element with one of the 16 elements below it. All other operations take the topmost two (or one, or more, depending on the operation) elements from the stack and push the result onto the stack. Of course it is possible to move stack elements to storage or memory in order to get deeper access to the stack, but it is not possible to just access arbitrary elements deeper in the stack without first removing the top of the stack.

5.0 Economic Model

The economic model of any new digital currency/asset is one of the most critical components of the platform that the asset resides on. This is especially true for the native token of a self-sovereign, permission-less platform, like Exzo Network. In this paper, we discuss the economic design of the native token, called Exzo (XZO). The discussion is broken down into the governance properties of the token, its supply, rewards function of staker(s), and other pertinent economics details, such as the transactional economy.

5.1 Exzo (XZO) Token Properties

These are the key takeaway properties of the design of the XZO economics model:
  • The resources spent by a validator for staking are proportional to that validator’s total stake.
  • The rewards accumulated by a validator for validating are proportional to that validator’s total stake.
  • Since Exzo Network is leaderless, there is no “rich-get-richer” compounding effects.
  • Validators that lock their stake for longer are rewarded more.
  • Validators are incentivized to stay online and operate correctly as their rewards are based on proof-of-uptime and proof-of-correctness.
  • XZO is a capped-supply token, with a maximum cap of 250 million XZO tokens.
  • While capped, XZO is still governable. The rate at which the total amount of XZO burned yearly is subject to governance.
  • Fees from transactions and interacting on the network are paid to the validator(s) helping secure the Exzo Network.
  • Users can utilize XZO to add liquidity to new projects launched on the Exzo Network.
  • Delegated staking of XZO to stake towards node validator(s) and earn rewards for helping secure the Exzo Network.


Exzo (XZO) is not a form of investment or security. Ensure your district or region's regulatory restrictions and guidelines are obeyed at all times. Please refer to Terms of Use for more information.

5.2 Governance

We initiate our survey of the Exzo Network economic design by first discussing governance, as it plays a critical role within future components. To enable the system to adapt to changing economic conditions, the Exzo Network platform enables key system parameters to be modified dynamically based on user input. A workable process for finding globally acceptable values for system parameters is critical for decentralized systems without custodians.
Exzo Network can use its consensus mechanism to build a system that allows anyone to propose special transactions that are, in essence, system-wide polls. Any participating node may issue such proposals.

5.3 Burn Rate

Burn rate is an important parameter that affects any currency, whether digital or fiat. Unfortunately, cryptocurrencies like Exzo (XZO) that has a fixed fee rate parameter might face various issues, including deflation or hyper-inflation. To that end, the reward rate will be subject to governance, within pre-established boundaries. This will allow token holders to choose the rate at which XZO reaches its deflationary status based on supply and demand. This also allows for adapting to economic changes over a longer period of time.
Transaction fees, denoted by the set F, will also be eventually be governed. F is effectively a tuple which describes the fees associated with the various instructions and transaction supported in future releases. Finally, staking times and amounts will also be governable.
The list of these parameters is defined in Figure 1 below.
Figure 1. Key governable parameters used in Exzo Network.
Ultimately, we note that governance in XZO has hysteresis, meaning that changes to parameters are highly dependent on their recent changes. There are two limits associated with each governable parameter: time and range.
Once a parameter is changed using a governance transaction, it becomes very difficult to change it again immediately and by a large amount. These difficulty and value constraints relax as more time passes since the last change.
These restrictions are in keeping with the design philosophy of predictability: the system must never change drastically over a short period of time, allowing users to safely predict system parameters in the short term, while having strong control and flexibility for the long term.

5.4 Liquidity Reserves Generation Model

Exzo Network plans to enhance the liquidation of digital assets and create a realistic marketcap that is built on a secure, reliable, and scalable source of liquidity reserves.
Users wrapping native tokens on to Exzo Network will have the choice to wrap their tokens into an xVault. An xVault is a series of token pools that follow an investment strategy that is allocated across cross-chain DeFi platforms
Depositing tokens into a xVault automatically mints a new wrapped version of that token on to the Exzo Network, which can be utilized on the Exzo Network as usual, but has dual characteristics of a type of liquidity provider (LP) token. LP tokens are automatically created when tokens are deposited into a liquidity pool — and serve as a claim to a pool’s underlying assets.
Each wrapped token can be redeemed at any time for the originally deposited tokens plus a percentage of the rewards accumulated while the tokens were working in the xVault.
The user will have to pay a fee of their rewards earned from the xVault equivalent to 1-40% of the total rewards earned depending upon the amount deposited. 80% of the fee's generated are directed towards boosting the overall liquidity of assets on the Exzo Network such as the native blockchain token XZO, USDT, BNB, Ethereum, DAI and Polygon. 10% of the fee's generated will be utilized to run nodes on other networks such as Ethereum and Binance. The other 10% of the fee's generated will go towards the core contributors/developers/validators of the protocol.
These liquidity reserve tokens will then be proportioned into yield earning reserves and locked reserves where the yield earning reserves will be compounded over time to earn greater returns that are added to the liquidity of the Exzo Network enabling a constant growing liquidity pool for the network and reducing the volatility on the network.

5.5 Token Economics

XZO has a capped supply of 250,000,000 (250 Million XZO). The governance decisions of the ecosystem will determine the distribution and burn rate of the tokens within the treasury. Twenty percent (20%) of the tokens will be held by the core contributing members and vested, ten percent (10%) will be utilized for bug bounties, centralized exchange (CEX) listings, and other community controlled by governance. The other fifty five percent (55%) of the tokens will be released for the community.
Any and all token sales are available to anyone in the public to build the initial liquidity across blockchain networks (Ethereum, Polygon, Avalanche, and Binance Smart Chain).

Native Token Information

• Native token name = Exzo
• Native token symbol = XZO
• Wrapped token name = Wrapped Exzo
• Wrapped token symbool = WXZO

Token Supply and Price Information

  • Genesis pre-mined supply = 250,000,000 (250 Million XZO)
  • Max total supply = 250,000,000 (250 Million XZO)
  • Total circulating supply = 175,000,000 (175 Million XZO)
  • Burn Rate = *
  • Public sale price = $0.05 USD/1 XZO

Token Distribution

% of Initial Token Distribution
Initial Tokens
Anticipated Distribution Schedule
Released to the community upon launch as a fair launch.
Core Contributors
Vested for 36 months and released over the next 3 years.
Governed by the community to give to new projects.
CEX Market Making
Distributed to centralized exchanges for market making.
Distributed via airdrops to bring awareness to the network over the next 62 months.
The Exzo Network holds 50 million XZO tokens overall, which will be released over the next years. Of that, 25 million XZO is available initially to support ecosystem projects, grants, and unspecified community growth initiatives, and a smaller 5,000,000 XZO available initially to support the Exzo Network initiatives for the Foundation category.


The token economics and token distribution are subject to change until mainnet launch.

Supported Networks and Token Correspondence

  • Exzo Network (XZO)
  • Ethereum (ETH)
  • Binance Smart Chain (BSC)
  • Polygon (POLY)
  • Avalanche C-Chain (AVAX)
  • Fantomm (FTM)
  • Optimism (OP)


* implies that is will be decided by community governance through the governance protocol. ** implies that it will be a main supported network.

6.0 Roadmap

Q1 - 2022

  • Exzo Network testnet development
  • Exzo Network testnet deployment
  • Decentralized exchange (DEX) development
  • ExzoSwap non-custodial mobile app development
  • NFT marketplace development
  • Staking dApp development

Q2 - 2022

  • ExzoSwap Alpha testing launch
  • Decentralized exchange testnet deployment
  • Exzo Network testnet deployment with internal testing

Q3 - 2022

  • Exzo Network testnet deployment to public Beta
  • Exzo Network node validator incentivized program
  • Decentralized exchange mainnet deployment
  • Staking dApp testnet deployment
  • Testnet block explorer development
  • Mainnet block explorer development

Q4 - 2022

  • Exzo Network testnet ecosystem dApp development
  • Exzo Network smart contract audits
  • Launchpad partnership development
  • Exzo Network Mainnet deployment
  • XZO pre-listed on CoinMarketCap
  • XZO pre-listed on CoinGecko
  • XZO fair launch public sale on launchpad partner(s)
  • Develop CEX listing partnerships for XZO
  • Develop RPC provider partnerships for the Exzo Network
  • Team expansion (1-2 developers)
  • Testnet block explorer deployment
  • Mainnet block explorer deployment

Q1 - 2023

  • CEX listing(s) for XZO
  • CoinMarketCap Airdrop event
  • Team expansion (2-4 developers)
  • Corporate partnership(s) development for payment processing using XZO
  • Treasury governance established for community driven projects on the Exzo Network
  • Venture capital funding discovery - Seed funding/series A
  • Web3 wallet extension development
  • USDX stable coin development
  • Goal of 50-100 node validators
  • Ecosystem expansion

Q2 - 2023

  • Web3 wallet extension beta testing
  • Metaverse development discovery or partnership creation
  • Healthcare data management Web3 wallet discovery and planning phase
  • Team expansion (1-4 developers)
  • Goal of 100-300 node validators
  • USDX stable coin deployment

Q3 - 2023

  • Healthcare data management Web3 wallet development
  • Healthcare data management partnership discovery
  • Goal of 300-500 node validators

Q4 - 2023

  • Healthcare data management Web3 wallet beta testing with established partnerships
  • Healthcare data management web3 wallet deployment to public
  • Web3 wallet extension deployment
  • Goal of 500-1,000 node validators
  • CEX listings


  1. 1.
    Ethereum Virtual Machine (EVM). (n.d.). Retrieved October 19, 2022, from
  2. 2.
    Creadore, S. G. (2022, October 10). Exzo network whitepaper. Exzo Network Developer Documentation. Retrieved November 2, 2022, from
  3. 3.
    Nguyen, Cong & Dinh Thai, Hoang & Nguyen, Diep & Niyato, Dusit & Nguyen, Huynh & Dutkiewicz, Eryk. (2019). Proof-of-Stake Consensus Mechanisms for Future Blockchain Networks: Fundamentals, Applications and Opportunities. IEEE Access. PP. 1-1. 10.1109/ACCESS.2019.2925010.
  4. 4.
    Saltini, Roberto & Hyland-Wood, David. (2019). IBFT 2.0: A Safe and Live Variation of the IBFT Blockchain Consensus Protocol for Eventually Synchronous Networks.
  5. 5.
    OpenZeppelin. (n.d.). Retrieved November 2, 2022, from
  6. 6.
    Team, S. (n.d.). Solidity programming language. Solidity Programming Language. Retrieved November 2, 2022, from


The information described in this paper is preliminary and subject to change at any time. Furthermore, this paper may contain forward-looking statements. Forward-looking statements generally relate to future events or our future performance. This includes, but is not limited to, Avalanche’s projected performance; the expected development of its business and projects; execution of its vision and growth strategy; and completion of projects that are currently underway, in development or otherwise under consideration. Forward-looking statements represent our managements beliefs and assumptions only as of the date of this presentation.
These statements are not guarantees of future performance and undue reliance should not be placed on them. Such forward-looking statements necessarily involve known and unknown risks, which may cause actual performance and results in future periods to differ materially from any projections expressed or implied herein.
Exzo Network undertakes no obligation to update forward looking statements. Although forward-looking statements are our best prediction at the time they are made, there can be no assurance that they will prove to be accurate, as actual results and future events could differ materially. The reader is cautioned not to place undue reliance on forward-looking statements.
Last modified 33m ago