1. Summary
Endurance is a high-performance digital entertainment-focused sidechain built on top of aproven, fully EVM Compatible blockchain infrastructure BAS. Launched by Fusion
Interactive, the leading web 3.0 gaming studio created by gaming industry veterans,
Endurance optimizes instant transactions and ultra-low fees, enabling millions of
in-game/social transactions to be executed seamlessly. After 3 months of launch since Jan
2023, the Endurance network has had 50mm transactions and 1.4mm of total active users(source).

2. Abstract
Endurance is a blockchain ecosystem offering high-performance, cost-effective gaming, andsocial networking application solutions. With a focus on optimizing network performance andreducing storage requirements, Endurance aims to create a fast and efficient blockchain
infrastructure for developers to build decentralized applications. The protocol supports
various use cases, with a focus on gaming applications and social networking platforms.
Endurance enables innovations in the blockchain space by providing a scalable and reliableblockchain solution and aims to become a leading player in the digital entertainment
industry.

3. Motivation
The Endurance team has two main motivations to build the Endurance network:● The blockchain industry lacks a sustainable and scalable gaming+social ecosystem.
Endurance offers a faster and more efficient blockchain infrastructure for developers
to build decentralized applications, with a focus on gaming applications to social
networking applications.
● As of today, BNB Chain is the largest chain by active users, but it is experiencing
network scalability problems. The core developers have proposed using BinanceApplication Sidechain (BAS) in their Outlook 2022 paper to solve this problem;
Endurance network is built based off of the BAS design, it offers much higher
throughput, lower gas fees, and a predictable and stable fee system for users.

4. Structure
Endurance blockchain offers a multi-layer architecture to provide scalability and facilitate thereuse of existing modules. This architecture is composed of infrastructure, client interface
execution engines, network protocols, and storage. In addition, this architecture makes it
possible to modify existing smart contracts easily and efficiently.
The Endurance chain consists of multiple layers:

●
●
●
●
●
●
●
●
●
●

API and Tooling: Endurance provides a complete set of APIs and tools to enrich theblockchain ecosystem.
Explorer: Endurance's explorer allows real-time analysis of blocks, transactions,contracts, and accounts on the blockchain.
Governance/Staking App: Allows validators to easily propose, vote, and delegate
through a user-friendly interface.
APIs: Provides valuable information on NFTs and DeFi through RPC and Websocket.
Client Interface: Offers Web3 JSON-RPC with 100% compatibility with the Ethereum
network.
Governance Modules: Enables chain governance, including staking and slashing.
Execution Runtime: 100% EVM compatibility and smooth migration of existing SmartContracts.
Consensus: Endurance adopts a Proof-of-Stake consensus algorithm that combinesa hybrid mechanism of Proof-of-Stake (PoS) and Proof-of-Authority (PoA).
Network Protocol: Implements a P2P communication protocol between validators andnodes.
Storage & State: Provides key-value storage and Merkle Tree State, Tx & Blockstorage optimized for high-capacity processing.

5. Specification
Endurance is a modular framework designed to create BSC (Binance Smart
Chain)-compatible sidechains with optimized performance and improved scalability.
Endurance brings development-ready features like staking, RPC-API, and smart contracts to
the BSC ecosystem. Instead of relying on the BSC security model, Endurance provides
protocols and standards for integrating third-party bridges that the Endurance validator set ofother projects can manage. In addition, it offers several programmable and configurable
modules like networking, blockchain & EVM, Web3 API, transaction pool, PoA & PoS
consensus, and storage & state, that developers can use or modify to reach their businessgoals.

Endurance brings several programmable and configurable modules that developers can use
or modify to reach their business goals.
Here is an example of such modules:● Networking - for p2p communication between different Endurance nodes;● Blockchain & EVM - for block producing and EVM transaction execution, of course,
each Endurance can define its runtime execution environment based, for example,
on WebAssembly;● Web3 API - for essential compatibility with the Web3 ecosystem, including MetaMask
and other applications;● Transaction Pool - for managing internal Endurance policies for transaction filteringand for charging fees for the system operations;● PoA & PoS Consensus - for users to be able to vote for the honest validators in the
Endurance network and guarantee the safeness of actions applied on the chain;● Storage & State - for persisting local data.

5.0 Circulation Model and Native Asset Bridge
The critical components of each Endurance application are the native token circulation
model and cross-chain bridge for native assets. Native assets of the Endurance chain arelocated within the Endurance application and managed directly by the sidechain. Endurance
is designed to provide cross-chain functionality for the native assets, which Endurance
developers fully manage. However, we leave decisions on token supply manipulation or
minting/burning tokens to the developers' discretion, as they bear the risk of damaging theirreputation.
To ensure active validator sets and verify the correctness of cross-chain transactions, we
require block header verification for the native cross-chain bridge. Although Endurance is atechnology-agnostic solution not designed to have a BSC-compatible consensus or EVM
execution environment, we offer basic functionality for Endurance applications to help themset up their work and be part of the ecosystem. We trust Endurance developers, but we mustensure validator transition integrity. Therefore, we introduce a block header verification
function (BHVF) that the Endurance development team must specify. BHVF, written in
Solidity, verifies block headers from Endurance applications and validator transitions, but it
cannot prove the correctness of state transitions. BHVF is a required parameter to register
Endurance in BSC's smart contract for native cross-chain functionality.
Block header verification is not complicated; we only need to verify block headers to ensure
validator transition accuracy. We can use BLS/BN to publish only epoch blocks containing
new validator sets and signatures from all previous validators without passing all blockheaders into it to achieve confirmation.
interface IProofVerificationFunction {function verifyValidatorTransition(bytes[] calldata proofs, uint256
chainId, address[] calldata existingValidatorSet) external view returns(address[] memory newValidatorSet);}

If we assume that block verification consumes ~50k gas (w/ state modification), then we
have the following calculations:● Per block: 50k gas/block, then its ~16k gas/sec● Per epoch: 50k gas/epoch (epoch can be from 5 minutes up to 1 day), then it's
between ~160 gas/sec (for 5 min epoch) and 0.57 gas/sec (for one-day epoch)
Of course, the gas consumption for cross-chain operations will depend on the epoch length,
but Endurance doesn't need very short epochs. We recommend using an epoch length of
one day for validator transition, which can be reduced to 6-12 hours based on theapplication's needs without significantly changing gas consumption.
Our native asset bridge supports the following user flows:
Deposit (Endurance -> BSC): When a user calls the deposit function, their native tokens will
be locked in the smart contract, and an event will be emitted. The user must then generate
proof containing information about the transaction receipt (including the emitted events) witha Merkle Patricia trie proof to mint peg tokens in the BSC chain. This proof should be
uploaded into the BSC chain, where the EnduranceValidatorHub smart contract can verify it
and validate the signatures from the Endurance chain.
Withdrawal (BSC -> Endurance): The withdrawal of funds is the opposite of the deposit flow.
The user must burn their pegged tokens in the BSC chain to use this proof to withdraw
tokens from the native asset bridge smart contracts. Validators in the Endurance network willverify the correctness of this operation and prevent double-spend attacks.
Endurance developers can specify fees for cross-chain operations between the Endurance
and BSC chains, and these fees or fine-related mechanisms should be specified in the
Endurance smart contract rather than the BSC smart contracts or block verification
functions.

5.1 Endurance Validator Hub
Endurance provides native asset cross-chain functionality to BAS applications by default. In
order to register with Endurance, each application must specify the block header verification
function (BHVF) and is assigned a chain ID by the Endurance smart contract. BHVF verifies
block headers without state transitions and must be written in Solidity to check the blockheader, the correctness of the chain for N blocks, and signatures. Endurance supports
default chain implementation with the Endurance Validator Hub. Still, other developers canwrite their own verification function, provided that they pass code auditing to be trusted by
the community and avoid malicious functions or vulnerabilities.
The system contract address of the Endurance Validator Hub smart contract:
0x0000000000000000000000000000000000007000

5.2 Fast-finality and BLS cryptography
Parlia is a BFT-like consensus where only one Validator produces a block. To ensure thecorrectness of this operation, we must wait for the confirmation time, which is usually
2/3*N+1, where N is the number of active validators (15 blocks for the current configuration).

We must upload at least 15 blocks to the blockchain to prove one block. BLS cryptography
with Parlia's fast finality can solve this problem because we can collect one aggregatedsignature and send only this signature to BSC. However, we need to know the BLS publickeys of each Validator. Currently, BLS cryptography is merged into the official geth
repository, but BSC does not yet support it. Applying these changes to the Parlia consensus
engine may take some time. Additionally, it is not strictly required to use BLS; geth has
support for the BN256 curve since the Byzantium fork, which can be used as a replacement
for BLS aggregated signatures.
Here are some possible solutions:● Break compatibility with Parlia and implement fast finality in the Endurance version of
Parlia using the BN256 curve.
● Wait for BSC's version of fast-finality and BLS support.
● Given the many moving parts involved, consider fast finality as an optional solution
for Endurance.

5.3 System Smart Contracts
Each Endurance sidechain is also technology-agnostic, allowing developers to modify or
include any module within Endurance and use any consensus or runtime execution
environment. By default, Endurance provides an EVM execution environment with a set ofsystem smart contracts for platform operation. However, developers want to add morefunctionality to their sidechain. In that case, they can implement it themselves or contribute itto the official Endurance template to extend the default module set with additional extensions
that other developers can utilize in the future.
Predefined BSC-compatible system smart contracts:● Staking (0x0000000000000000000000000000000000001000) - for managing
validator delegations and active validator set● SlashingIndicator (0x0000000000000000000000000000000000001001) - forslashing not active validators● SystemReward (0x0000000000000000000000000000000000001002) - treasury forthe system rewards to cover relay fees and others
Endurance-defined smart contracts:● StakingPool (0x0000000000000000000000000000000000007001) - a staking poolthat helps to aggregate stakes and optimize gas consumption for the reward
calculation● Governance (0x0000000000000000000000000000000000007002) - default on-chain
implementation by Compund's Alpha governance● ChainConfig (0x0000000000000000000000000000000000007003) - configuration
for the consensus that is managed by on-chain governance● RuntimeUpgrade (0x0000000000000000000000000000000000007004) - smart
contract for managing runtime upgrades in the chain● DeployProxy (0x0000000000000000000000000000000000007005) - a proxy for
managing ACLs for deploying and doing calls (under development, address isreserved for future needs)

To incentivize users to stake their funds and vote for honest validators, Endurance also
supports the Parlia consensus engine. This makes Endurance sidechains more
decentralized and trustworthy while allowing stakers to earn rewards from their stakes byreceiving fees from block producers. To interact with the Parlia consensus engine,
Endurance supports a staking contract that is compatible with the following interface:interface IValidatorSet {function init() external;function getValidators() external view returns (address[] memory);function deposit(address validator) external payable;
receive() external payable;}interface ISlashingIndicator {function init() external;function slash(address validator) external;}
interface ISystemReward {function init() external;
receive() external payable;}
Endurance provides a default implementation and financial model for staking that isembedded in the Genesis block as a system smart contract. However, Endurance
developers can also choose to implement a different staking model based on their specificbusiness requirements. This flexibility allows for customization and optimization of staking
mechanisms to best suit the needs of each project using the Endurance framework.

5.4 Staking Smart Contract
The default implementation of Endurance includes staking smart contracts written in Solidity
for the EVM execution environment. This smart contract extends the IValidatorSet interface
and enables users to manage active validators based on the total delegated amount anddistribute rewards between stakeholders. While it's not strictly necessary to have an EVM
implementation of such smart contracts, it can benefit default Endurance solutions. It's worth
noting that the specific ABI methods for these smart contracts are implementation-definedand can be customized by Endurance developers to meet their particular requirements.

5.5 PoSA Consensus
The consensus algorithm is a crucial component of any blockchain network as it enables
decentralized nodes to agree on the validity of transactions without relying on central
authorities. Endurance, being a public blockchain, also relies on a consensus algorithm toverify the validity of transactions and ensure the protocol rules are followed. Therefore, it isdesigned to process a high volume of transactions, with a target of 10,000 transactions per
second, and pursue immediate transaction finality. Endurance aims to achieve this byimplementing a fast block creation time of 2 seconds and allowing more than 20 consensus
nodes to participate in the consensus.
Proof of Staked Authority (PoSA):
Endurance uses a hybrid consensus algorithm called PoSA, which combines the Proof of
Staking (PoS) and Proof of Authority (PoA) mechanisms. PoSA allows only authorized
validators to generate blocks, and validators must stake a certain amount of Endurance's
native token ACE to participate in the consensus. The ranking of validator candidates isdetermined by the number of ACE tokens deposited, and the top validator candidates(Candidate Validators) are elected as Active Validators. The governance process determines
the number of Active Validators, and delegators can delegate their ACE tokens to validators
or candidates to receive block rewards.
Validators and delegates on Endurance are subject to slashing penalties for bad behavior,such as double signing and node instability. To ensure that validators cannot misuse theirpower, Endurance has an unbonding period for validators and delegates to prepare forpossible misbehavior. The PoSA consensus algorithm of Endurance ensures faster block
generation and lower costs while maintaining decentralization and community engagement.

5.6 Gas Fee
Network activity and market decisions influence transaction fees on the Endurance
blockchain. As a result, excessive fees can hinder usability, while low fees may cause
security concerns. To address this, Endurance introduces the Elastic Fee, which allows forflexible application of transaction fees based on external factors.
The Elastic Fee system lowers barriers to entry by providing different and flexible fees,
enabling flexible responses to various situations that may arise. Particular transactions,which are essential for using Endurance services, do not incur a fee for users; instead, thesystem pays the fee. Different fees will be charged for all other user transactions based on
the membership provided. Smart contracts ensure the execution of these different fees istransparent and secure.
Endurance will establish a standard fee policy under Endurance governance, which will beapplied flexibly through the Elastic Fee policy. This will ensure that fees are aligned withappropriate levels, promoting usability and addressing security issues.

5.7 Runtime Upgrade
The Endurance blockchain allows easy upgrades without requiring a hard fork, meaning all
nodes do not need to upgrade their client modules simultaneously. In case of functional
improvements or security changes, upgrades can be made through the System Genesis
Contract. However, proposals and votes are required through an on-chain governanceprocess before any enhancements can be implemented, which can only be done by selectedvalidators.

5.8 Validator Selection
As mentioned above, to become a validator on the Endurance chain, a certain amount of$ACE is required for staking, and the selection of an active validator is determined in thefollowing order:
Candidate Validator: To become a validator candidate, a certain amount of $ACE coins must
be deposited as collateral.
Voting Period: Active Validators submit proposals to add new validator candidates to the
Validator Hub. Active Validator Operators can vote for, against, and abstain during the voting
period. When a proposal reaches a quorum or a minimum threshold defined by the protocol,
it is passed on to the next stage.
Authorized Validator: When multiple Active Validators accept a proposal, the Proposed
Validator immediately becomes an Authorized Validator.
Active Validator: At the next epoch, the consensus engine selects a top Authorized Validator
as the Active Validator to propose blocks and secure the network. Only Active Validators canparticipate in voting, proposals, and block creation. The number of Active Validators can be
regulated by governance, and the staking quantity of $ACE selects Active Validators.

5.7 Governance
Each Endurance sidechain should have an on-chain governance mechanism that allows
users to vote for new proposals. This governance system is designed to provide Endurance
users with a voice in the decision-making process and ensure that the network evolves in adecentralized and community-driven manner.
The governance system in Endurance is based on the Compound's alpha governance, andvalidator owners in the chain have the ability to create and vote for new proposals. The
voting power is distributed based on the total delegated amount to the Validator. Once ⅔ ofthe quorum is reached and >51% of votes are for the proposal, it can be executed by anyone
on the chain.
The Endurance governance system is able to manage staking parameters like felony
threshold or jail period to ensure the network's security and stability. Through thismechanism, Endurance aims to promote transparency, accountability, and community
participation in the governance of the network.

6. Tokenomics$ACE total supply is 147 millions, it is used as the native asset on the Endurance
blockchain, and is used by network users to pay for nodes that process the requested
operation.

●
●
●
●

Gas Fee
Digital Asset Purchase (NFT Marketplace) and Service Fees
Token for all apps independently developed by the Team
Used for staking in Endurance validator nodes

Description

Allocation

AmountTGE

First 2 Months
Vesting %LOCKUP(Mth)

VEST (Mth）Team

15.00%

22,050,000

0%

0%

12

36

Early Equity
Investor

2.30%

3,381,000

100%

100%

0

0

Eco-Fund11.60%

17,052,000

2.5%

12.5%

-

36

Incentive Pool

26.00%

38,220,000

5%

10%

1

45

Initial Reward Pool

1.00%

1,470,000

100%

100%

-

-

Treasury/Reserve

9.00%

13,230,000

10%

10%

12

36

Strategic Investors

2.50%

3,675,000

20%

20%

12

36

Marketing &Collaborators

3.50%

5,145,000

15%

20%

-

16

Launch Pool

7.00%

10,290,000

100%

100%

-

0

Nexus Bond
Airdrop3.40%

4,998,000

3.68%

14%

0

24

Jump Start

1.00%

1,470,000

100%

100%

-

0

Early Investors

17.70%

26,019,000

0%

0%

12

36

6.0 Minting
The initial release of 1.47 million $ACE tokens, representing 1% of the total supply, will beavailable for the first 60 days after launch. Should these tokens be claimed(Engage to Earn)by users during this period, additional tokens may be made available from the <Reserved
Reward Pool> to the <Initial Reward Pool>

6.1 Reward Distribution
To ensure that the Endurance network grows and the ecosystem remains sustainable, 15%of the $ACE token will be used for the Ecosystem Fund. The use of the Ecosystem Fund will
be divided into two categories as follows:● Establish a strong and sustainable ecosystem by incentivizing its most outstanding
partners. This can be done by providing them with a certain percentage of ACE tokens or byoffering a token swap between ACE and their upcoming tokens, creating a deep binding
between the two projects. By doing so, Endurance can motivate its partners to improve theirproducts and create valuable content for Endurance users, thus creating a stable andsustainable ecosystem. This approach will also foster collaboration and innovation within thecommunity, developing new and exciting use cases for Endurance.
● Used for marketing (Airdrop) to secure initial users using Endurance networks (gameservices, content services, NFTs, etc.)

6.2 Burning
Endurance aims to create a highly sustainable closed-loop ecosystem that enables the bestdevelopers to acquire WEB3 users while also allowing users to continuously gain substantial
long-term rewards from the content created by these developers.
If Endurance's partners generate income in $ACE on the network, 20% to 40% of it will beburned every two weeks, determined by the project and track types.
For developers who generate $ACE revenue on the Endurance network, 100% will beburned every two weeks.
We aim to maintain a deflationary $ACE token to achieve long-term stability.

7. Development Tools
7.0 Smart Contracts​
Smart contracts development with Endurance enables you to build your smart contracts forany use, including cryptocurrency exchanges, smart contract-based dApps, and more. Smartcontracts are programming logic that are executed automatically when a certain condition(s)are met. In Endurance, smart contracts can be written in Solidity programming language.
Please refer to the official documentation of Solidity for any queries.

7.1 IDE​
Multiple IDEs and libraries can be used for developing and deploying smart contracts.
●

●

●
●

Remix IDE: A powerful open-source tool that helps you write Solidity contracts
straight from the browser. It is written in JavaScript and supports both usages in thebrowser, but runs locally and in a desktop version. Remix IDE has modules fortesting, debugging, deploying smart contracts, and much more.
Intellij Solidity Plugin: Every aspect of IntelliJ IDEA has been designed to maximize
developer productivity. Together, intelligent coding assistance and ergonomic design
make development not only productive but also enjoyable.
BSC Studio: Blockchain Labs building graphic IDE to expedite dApp development.
Chainide: A Cloud-Based Multi-Chain IDE.

7.2 Development Framework​
●
●
●
●

●

Truffle: A world class development environment, testing framework and asset
pipeline for blockchains using the Ethereum Virtual Machine.
Embark: Embark is a platform that enables easy development and deployment ofdecentralized applications.
Waffle: The most advanced framework for testing smart contracts.
OpenZeppelin: OpenZeppelin provides security products to build, automate, andoperate decentralized applications. We also protect leading organizations byperforming security audits on their systems and products.
HardHat: Hardhat is a development environment for Ethereum software.

7.3 Solidity Code Quality​
●
●
●
●
●

Solhint: This is an open source project for linting Solidity code. This project provides
both Security and Style Guide validations.
Ethlint: Ethlint (Formerly Solium) analyzes your Solidity code for style & security
issues and fixes them.
Manticore: Manticore is a symbolic execution tool for analysis of smart contracts andbinaries.
Slither: Slither is a Solidity static analysis framework.
Echidna: Echidna is a program designed for fuzzing/property-based testing of
Ethereum smart contracts.

7.4 Front-End Programming​●●

Web3.js: Access full node capabilities without running your own.
Ethers.js: Designed to make it easier to write client-side JavaScript based wallets,
keeping the private key on the owner’s machine at all times.

7.5 Back-End Programming​
●
●
●
●
●

Web3.py: A python interface for interacting with the Ethereum blockchain andecosystem.
Web3.php: A php interface for interacting with the Ethereum blockchain andecosystem. Native ABI parsing and smart contract interactions.
Java Web3: Lightweight Java and Android library for integration with Ethereumclients.
Net Web3: Bringing the love of .NET to Ethereum. An open source .NET integration
library for blockchain.
Ruby Web3: Ethereum library for the Ruby language.

7.6 Wallet SDK​●●●

Venly: Wallet creation by social accounts.
Sequence.app: Wallet creation by social accounts.
Web3Auth: Wallet creation by social accounts.

●

BSC Connector: This example demonstrates how to support the Binance Chain
Wallet through a custom connector.

7.7 Multisig​●

Gnosis: The purpose of multisig wallets is to increase security by requiring multiple
parties to agree on transactions before execution.

JSON RPC Endpoints​
Chain Name

Endurance Smart Chain Mainnet

Chain ID

648

TickerACE

RPC Endpointhttps://rpc-endurance.fusionist.io/

Explorer

https://explorer-endurance.fusionist.io/

7.8 JSON-RPC API
The JSON-RPC API method of Endurance blockchain is fully compatible with Ethereum.
Please refer to the link underneath for more details about the API Spec.
https://ethereum.org/en/developers/docs/apis/json-rpc/#json-rpc-methods

7.9 Decentralized storage●●●●

BNB Greenfield: Core consists of a storage-oriented blockchain (BNB Greenfield)
and a decentralized network of Storage Providers (SPs).
IPFS: A peer-to-peer hypermedia protocol designed to preserve and grow humanity's
knowledge by making the web upgradeable, resilient, and more open.
Arweave: A decentralized on-chain data storage.
Filecoin: Filecoin is making the web more secure and efficient with a decentralized
data storage marketplace, protocol, and cryptocurrency.

Disclaimer
NOTHING IN THIS WHITEPAPER CONSTITUTES LEGAL, FINANCIAL, BUSINESS OR
TAX ADVICE AND YOU SHOULD CONSULT YOUR OWN LEGAL, FINANCIAL, TAX OR
OTHER PROFESSIONAL ADVISOR(S) BEFORE ENGAGING IN ANY ACTIVITY IN
CONNECTION HEREWITH. NEITHER THE COMPANY, THE PLATFORM, OR THEIRRESPECTIVE AFFILIATES (COLLECTIVELY, “WE, OR US”), NOR ANY SERVICEPROVIDER SHALL BE LIABLE FOR ANY KIND OF DIRECT OR INDIRECT DAMAGE OR
LOSS WHATSOEVER WHICH YOU MAY SUFFER IN CONNECTION WITH ACCESSING
THIS WHITEPAPER, OR ANY OTHER WEBSITES OR MATERIALS (“WEBSITE”)
PUBLISHED BY US.

Nature of the Whitepaper and Coins/Tokens
The Whitepaper and the Website are intended for general informational purposes onlyand do not constitute a prospectus, an offer document, an offer of securities, a solicitation forinvestment, or any offer to sell any product, item or asset (whether digital or otherwise),including any of the digital Coins/tokens referred to in this Whitepaper (“Coins/Tokens”). The
Coins/Tokens are not intended to be, and do not purport to be regarded as securities orinvestment products or any other form of similar regulated products in any jurisdiction inwhich the Coins/Tokens may be sold, traded, or issued in.
Please note that while the Platform sets aside certain loyalty rewards to incentivise thegrowth of the Platform’s user base, holders of Coins/Tokens are not entitled to participate in
the profits earned by the Company.
The information herein may not be exhaustive and does not imply any element of acontractual relationship. There is no assurance as to the accuracy or completeness of suchinformation and no representation, warranty or undertaking is or purported to be provided as
to the accuracy or completeness of such information. Where the Whitepaper or the Website
includes information that has been obtained from third party sources, we have notindependently verified the accuracy or completion of such information. Further,you acknowledge that circumstances may change and that the Whitepaper or the Website
may become outdated as a result; and we are under no obligation to update or correct thisdocument in connection therewith.

Deemed Representations and Warranties
By accessing the Whitepaper or the Website (or any part thereof), you shall be deemed
to represent and warrant to us as follows:(a) In any decision to purchase any Coins/Tokens, you shall not rely on any statement set
out in the Whitepaper or the Website.
(b) You will and shall at your own expense ensure compliance with all laws, regulatory
requirements and restrictions applicable to you (as the case may be).
(c) You acknowledge, understand and agree that the Coins/Tokens may have no value, there
is no guarantee or representation of value or liquidity for Coins/Tokens, and Coins/Tokens is
not an investment product including for any speculative investment.

(d) We shall not be responsible for or liable for the value of the Tokens, the transferability
and/or liquidity of Coins/Tokens and/or the availability of any market for Coins/Tokens
through third parties or otherwise.
(e) You acknowledge, understand and agree that you may not be eligible to purchase any
Coins/Tokens if you are a citizen, national, resident (tax or otherwise), domiciliary and/or
green card holder of a geographic area or country (i) where it is likely that the sale of
Coins/Tokens would be construed as the sale of a security (howsoever named), financial
service or investment product and/or (ii) where participation in Coins/token sales is
prohibited by applicable law, decree, regulation, treaty, or administrative act; and to thiseffect you agree to provide all such identity verification documents whenrequested in order for the relevant checks to be carried out.
We do not and do not purport to make, and hereby disclaims, all representations, warranties
or undertaking to any entity or person (including without limitation warranties as to theaccuracy, completeness, timeliness or reliability of the contents of the Whitepaper or theWebsite, or any other materials published by us). To the maximum extent permitted by law,
we shall not be liable for any indirect, special, incidental, consequential or other losses ofany kind, in tort, contract or otherwise (including, without limitation, any liability arising fromdefault or negligence on the part of any of them, or any loss of revenue, income or profits,
and loss of use or data) arising from the use of the Whitepaper or the Website, or any othermaterials published, or its contents (including without limitation any errors or omissions) orotherwise arising in connection with the same. Prospective purchasers of Coins/Tokens
should carefully consider and evaluate all risks and uncertainties (including financial andlegal risks and uncertainties) associated with the Coins/Tokens or its issuing entities.

Informational purposes only
No regulatory authority has examined or approved, whether formally or informally, of any of
the information set out in the Whitepaper or the Website. No such action or assurance has
been or will be taken under the laws, regulatory requirements or rules of any jurisdiction. The
publication, distribution or dissemination of the Whitepaper or the Website in any jurisdiction
or language does not imply that the applicable laws, regulatory requirements or rules havebeen complied with.

Regulatory approval
All statements contained herein, statements made in press releases or in any place
accessible by the public and oral statements that may be made by us may constituteforward-looking statements (including statements regarding intent, belief or current
expectations with respect to market conditions, business strategy and plans, financial
condition, specific provisions and risk management practices). You are cautioned not toplace undue reliance on these forward-looking statements given that these statements
involve known and unknown risks, uncertainties and other factors that may cause the actual
future results to be materially different from that described by such forward-looking
statements, and no independent third party has reviewed the reasonableness of any suchstatements or assumptions. We expressly disclaim any responsibility (whether express orimplied) to release any revisions to these forward-looking statements to reflect events after
such date.

References to companies and platforms
The use of any company and/or platform names or trademarks herein does not imply any
affiliation with, or endorsement by, any third party. References in the Whitepaper or theWebsite to specific companies and platforms are for illustrative purposes only.