| [Table 2] Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens | |||||
| Template for white papers for crypto-assets other than asset-referenced tokens or e-money tokens [abstract] | |||||
| General information | |||||
| 00 Table of content | boolean true | ||||
| 01 Date of notification | date | ||||
| 02 Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114 | boolean true | ||||
| 03 Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114 | boolean true | ||||
| 04 Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114 | boolean true | ||||
| 05 Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114 | boolean true | ||||
| 06 Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114 | boolean true | ||||
| SUMMARY | |||||
| 07 Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114 | boolean true | This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto –asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law. |
|||
| 08 Characteristics of the crypto-asset | textBlock | ||||
| 09 Further information about utility tokens | textBlock | ||||
| 10 Key information about the offer to the public or admission to trading | textBlock | ||||
| Part A - Information about offeror or person seeking admission to trading | |||||
| A.1 Name | N/A | . | |||
| A.2 Legal form | N/A | . | |||
| A.3 Registered address | |||||
| Registered addess | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| A.4 Head office | |||||
| Head office | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| A.5 Registration date | N/A | . | |||
| A.6 Legal entity identifier | N/A | . | |||
| A.7 Another identifier required pursuant to applicable national law | N/A | . | |||
| A.8 Contact telephone number | N/A | . | |||
| A.9 E-mail address | N/A | . | |||
| A.10 Response time (days) | N/A | . | |||
| A.11 Parent company | N/A | . | |||
| A.12 Members of the management body | |||||
| Member #1 | N/A | . | |||
| Identity | N/A | . | |||
| Business address | N/A | . | |||
| Function | N/A | . | |||
| A.13 Business activity | N/A | . | |||
| A.14 Parent company business activity | N/A | . | |||
| A.15 Newly established | N/A | . | |||
| A.16 Financial condition for the past three years | N/A | . | |||
| A.17 Financial condition since registration | N/A | . | |||
| Part B - Information about issuer, if different from offeror or person seeking admission to trading | |||||
| B.1 Issuer different from offerror or person seeking admission to trading | boolean | ||||
| B.2 Name | text | ||||
| B.3 Legal form | text | ||||
| B.4 Registered address | |||||
| Registered addess | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| B.5 Head office | |||||
| Head office | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| B.6 Registration date | date | ||||
| B.7 Legal entity identifier | LEI | ||||
| B.8 Another identifier required pursuant to applicable national law | text | ||||
| B.9 Parent company | text | ||||
| B.10 Members of the management body | |||||
| Member #1 | id | 1 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| B.11 Business activity | textBlock | ||||
| B.12 Parent company business activity | textBlock | ||||
| Part C - Information about the operator of the trading platform in cases where it draws up the crypto-asset white paper and information about other persons drawing the crypto-asset white paper pursuant to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | |||||
| C.1 Name | text | ||||
| C.2 Legal form | text | ||||
| C.3 Registered address | |||||
| Registered address | text | Triq Ghar il-Lembi, Sliema SLM1562, Malta |
|||
| Country | enumeration | ||||
| Sub-division | text | ||||
| C.4 Head office | |||||
| Head office | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| C.5 Registration date | date | ||||
| C.6 Legal entity identifier | LEI | ||||
| C.7 Another identifier required pursuant to applicable national law | text | ||||
| C.8 Parent company | text | ||||
| C.9 Reason for crypto-asset white paper preparation | textBlock | - The admission to trading of BASED on regulated platforms, starting with the OKX Exchange. OKX Europe Limited as a result of being a licenced CASP endeavours to fulfill the obligations established under MiCA and the respective MFSA guidelines to: - Notify this whitepaper to the MFSA; - Publish the whitepaper publicly; and - Ensure its registration in the MiCA register maintained by the European Securities and Markets Authority (ESMA). This whitepaper has been prepared to provide transparent, accurate, and fair information to prospective token holders and regulatory authorities in line with the principles of MiCA. |
|||
| C.10 Members of the management body | |||||
| Member #1 | id | 1 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| Member #2 | id | 2 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| Member #3 | id | 3 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| Member #4 | id | 4 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| C.11 Operator business activity | textBlock | ||||
| C.12 Parent company business activity | textBlock | ||||
| C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | text | ||||
| C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | text | ||||
| Member #2 | id | 2 | |||
| C.12 Parent company business activity | N/A | . | |||
| C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A | . | |||
| C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A | . | |||
| Member #3 | id | 3 | |||
| C.12 Parent company business activity | N/A | . | |||
| C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A | . | |||
| C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A | . | |||
| Member #4 | id | 4 | |||
| C.12 Parent company business activity | N/A | . | |||
| C.13 Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A | . | |||
| C.14 Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114 | N/A | . | |||
| Part D - Information about other token project | |||||
| D.1 Crypto-asset project name | text | ||||
| D.2 Crypto-asset name | text | ||||
| D.3 Abbreviation | text | ||||
| D.4 Crypto-asset project description | textBlock | ||||
| D.5 Details of all natural or legal persons involved in implementation of crypto-asset project | |||||
| Person #1 | id | 1 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #2 | id | 2 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #3 | id | 3 | |||
| Type of person | enumeration | Other person involved in implementation | |||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #4 | id | 4 | |||
| Type of person | enumeration | Other person involved in implementation | |||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| D.6 Utility token classification | boolean | ||||
| D.7 Key features of goods or services for utility token projects | text | ||||
| D.8 Plans for the token | |||||
| Description of past milestones | textBlock | ||||
| Description of future milestones | textBlock | ||||
| D.9 Resource allocation | text | Genesis Distribution: 36% (360,000,000 BASED), sub-divided into: Based Community (S1, S2, PUPs, BasedPal): 23.5% of total supply, fully unlocked at the Token Generation Event; Ethena Community: 7.5% of total supply, of which 0.5% is unlocked at the Token Generation Event, 20% is distributed over the three months following the Token Generation Event, and the remaining 80% is unlocked after a one-year cliff; Season 3 Participants: 5% of total supply, scheduled for distribution in May 2026. Ecosystem and Rewards: 23.64% (236,400,000 BASED), managed by the Based Foundation and intended to support ecosystem growth, incentive programs, and platform development. Investors: 20.36% (203,600,000 BASED), subject to a one-year lock followed by two years of monthly unlocks. Core Contributors: 20% (200,000,000 BASED), subject to a one-year lock followed by two years of monthly unlocks. The emission schedule runs from approximately 30 March 2026 through 30 March 2029, at which point all allocations are scheduled to have fully vested. The total supply of BASED is fixed at 1,000,000,000; circulating supply is subject to change depending on vesting schedules and unlocks. |
|||
| D.10 Planned use of collected funds or other tokens | text | ||||
| Part E - Information about offer to public of other tokens or their admission to trading | |||||
| E.1 Public offering or admission to trading | enumeration | ||||
| E.2 Reasons for public offer or admission to trading | textBlock | ||||
| E.3 Fundraising target | |||||
| Target expressed in currency | monetary | EUR | |||
| Target expressed in units | decimal | ||||
| Target expressed in digital token identifier | text | ||||
| E.4 Minimum subscription goals | |||||
| Goals expressed in currency | monetary | EUR | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.5 Maximum subscription goals | |||||
| Goasl expressed in currency | monetary | EUR | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.6 Oversubscription acceptance | boolean | ||||
| E.7 Oversubscription allocation | text | ||||
| Issue price details | |||||
| E.8 Issue price | decimal | ||||
| E.9 Official currency determining issue price | enumeration | ||||
| E.9 Any other tokens determining issue price | text | ||||
| E.10 Subscription fee | |||||
| Fee expressed in currency | monetary | EUR | |||
| Fee expressed in units | decimal | ||||
| Fee expressed in digital token identifier | text | ||||
| E.11 Offer price determination method | text | ||||
| E.12 Total number of offered or traded other tokens | integer | ||||
| E.13 Targeted holders | enumeration | ||||
| E.14 Holder restrictions | text | ||||
| E.15 Reimbursement notice | boolean true | ||||
| E.16 Refund mechanism | textBlock | ||||
| E.17 Refund timeline | text | ||||
| E.18 Offer phases | textBlock | ||||
| E.19 Early purchase discount | textBlock | ||||
| E.20 Time-limited offer | boolean | ||||
| E.21 Subscription period beginning | date | ||||
| E.22 Subscription period end | date | ||||
| E.23 Safeguarding arrangements for offered funds or other tokens | textBlock | ||||
| E.24 Payment methods for other token purchase | textBlock | ||||
| E.25 Value transfer methods for reimbursement | textBlock | ||||
| E.26 Right of withdrawal | textBlock | ||||
| E.27 Transfer of purchased other tokens | textBlock | ||||
| E.28 Transfer time schedule | text | ||||
| E.29 Purchaser's technical requirements | textBlock | ||||
| Other token services provider characteristics | |||||
| E.30 Other token service provider (CASP) name | text | ||||
| E.31 CASP identifier | LEI | ||||
| E.32 Placement form | enumeration | ||||
| Trading platforms characteristics | |||||
| E.33 Trading platforms name | text | ||||
| E.34 Trading platforms market identifier code (MIC) | text | ||||
| E.35 Trading platforms access | text | ||||
| E.36 Involved costs | textBlock | ||||
| E.37 Offer expenses | textBlock | ||||
| E.38 Conflicts of interest | textBlock | ||||
| E.39 Applicable law | textBlock | ||||
| E.40 Competent court | textBlock | ||||
| Part F - Information about other tokens | |||||
| F.1 Crypto-asset type | text | ||||
| F.2 Other token functionality | textBlock | (i) granting tier-based access to reduced trading and prediction-market fees; (ii) granting access to Based Visa Card rewards, including cashback (described in project materials as up to eight per cent, subject to program terms) and higher card limits at higher token holding tiers; (iii) reducing on-ramp and off-ramp fees within the Based platform; (iv) granting access to future launchpool offerings; (v) providing discounts at Based Mall merchants; (vi) providing consumption credits for future agentic-commerce features; (vii) supporting staking within the Based platform, through which holders may unlock fee discounts, launchpool access, and additional ecosystem benefits. |
|||
| F.3 Planned application of functionalities | textBlock | ||||
| A description of the characteristics of the other token, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article | |||||
| F.4 Type of crypto-asset white paper | enumeration | ||||
| F.5 Type of submission | enumeration | ||||
| F.6 Other token characteristics | textBlock | ||||
| F.7 Commercial name or trading name | text | ||||
| F.8 Website of the issuer | text | ||||
| F.9 Starting date of offer to the public or admission to trading | date | ||||
| F.10 Publication date | date | ||||
| F.11 Any other services provided by the issuer | textBlock | ||||
| F.12 Language or languages of white paper | text | ||||
| F.13 Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available | text | ||||
| F.14 Functionally fungible group digital token identifier, where available | text | ||||
| F.15 Voluntary data flag | boolean | ||||
| F.16 Personal data flag | boolean | ||||
| F.17 LEI eligibility | boolean | ||||
| F.18 Home member state | enumeration | ||||
| F.19 Host member states #1 | enumerationSet | ||||
| F.19 Host member states #2 | enumerationSet | ||||
| F.19 Host member states #3 | enumerationSet | ||||
| F.19 Host member states #4 | enumerationSet | ||||
| F.19 Host member states #5 | enumerationSet | ||||
| F.19 Host member states #6 | enumerationSet | ||||
| F.19 Host member states #7 | enumerationSet | ||||
| F.19 Host member states #8 | enumerationSet | ||||
| F.19 Host member states #9 | enumerationSet | ||||
| F.19 Host member states #10 | enumerationSet | ||||
| F.19 Host member states #11 | enumerationSet | ||||
| F.19 Host member states #12 | enumerationSet | ||||
| F.19 Host member states #13 | enumerationSet | ||||
| F.19 Host member states #14 | enumerationSet | ||||
| F.19 Host member states #15 | enumerationSet | ||||
| F.19 Host member states #16 | enumerationSet | ||||
| F.19 Host member states #17 | enumerationSet | ||||
| F.19 Host member states #18 | enumerationSet | ||||
| F.19 Host member states #19 | enumerationSet | ||||
| F.19 Host member states #20 | enumerationSet | ||||
| F.19 Host member states #21 | enumerationSet | ||||
| F.19 Host member states #22 | enumerationSet | ||||
| F.19 Host member states #23 | enumerationSet | ||||
| F.19 Host member states #24 | enumerationSet | ||||
| F.19 Host member states #25 | enumerationSet | ||||
| F.19 Host member states #26 | enumerationSet | ||||
| F.19 Host member states #27 | enumerationSet | ||||
| F.19 Host member states #28 | enumerationSet | ||||
| F.19 Host member states #29 | enumerationSet | ||||
| F.19 Host member states #30 | enumerationSet | ||||
| Part G - Information on rights and obligations attached to other tokens | |||||
| G.1 Purchaser rights and obligations | textBlock | ||||
| G.2 Exercise of rights and obligations | textBlock | ||||
| G.3 Conditions for modifications of rights and obligations | textBlock | ||||
| G.4 Future public offers | textBlock | ||||
| G.5 Issuer retained other token | integer | ||||
| G.6 Utility token classification | boolean | ||||
| G.7 Key features of goods or services utility tokens | text | ||||
| G.8 Utility tokens redemption | text | ||||
| G.9 Non-trading request | boolean | ||||
| G.10 Other tokens purchase or sale modalities | text | ||||
| G.11 Other tokens transfer restrictions | text | ||||
| G.12 Supply adjustment protocols | boolean | ||||
| G.13 Supply adjustment mechanisms | text | ||||
| Other token schemes details | |||||
| G.14 Token value protection schemes | boolean | ||||
| G.15 Token value protection schemes description | textBlock | ||||
| G.16 Compensation schemes | boolean | ||||
| G.17 Compensation schemes description | textBlock | ||||
| G.18 Applicable law | textBlock | ||||
| G.19 Competent court | textBlock | ||||
| Part H – Information on underlying technology | |||||
| H.1 Distributed ledger technology (DTL) | text | ||||
| H.2 Protocols and technical standards | text | Ethereum (ERC-20): ERC-20 is the widely adopted standard for fungible tokens on Ethereum, defining a common interface for token issuance, transfers, and third-party integrations. ERC-20 tokens are deployed via smart contracts that control total supply, balances, and permissions, and are compatible with Ethereum wallets, DeFi applications, and decentralized exchanges. The standard supports functions such as transfer, approve, mint, and burn, enabling programmable token logic through Ethereum's account-based architecture. BNB Smart Chain (BEP-20): BEP-20 is the widely adopted standard for fungible tokens on BNB Smart Chain, defining a common interface for token issuance, transfers, and third-party integrations. BEP-20 tokens are deployed via smart contracts that control total supply, balances, and permissions, and are compatible with EVM-compatible wallets, DeFi applications, and decentralized exchanges. The standard supports functions such as transfer, approve, mint, and burn, enabling programmable token logic through BNB Smart Chain's account-based architecture. Hyperliquid HyperEVM (ERC-20): The Hyperliquid HyperEVM is the EVM-compatible execution environment of the Hyperliquid Layer 1 blockchain. BASED is deployed on HyperEVM as a smart contract following the ERC-20 token standard, providing the same common interface for token issuance, transfers, and third-party integrations as the Ethereum deployment, and compatible with EVM-compatible wallets and applications. The HyperEVM deployment interacts with HyperCore, Hyperliquid's native order-book trading environment, via the chain's HyperCore-to-HyperEVM bridging primitives. |
|||
| H.3 Technology used | textBlock | Ethereum: Ethereum is a general-purpose Layer 1 blockchain that supports smart contract execution via the Ethereum Virtual Machine (EVM). The BASED token contract on Ethereum is written in Solidity and interacts with the Ethereum network using RPC-compatible clients. The Ethereum ecosystem enables composability with DeFi, NFT, and DAO infrastructure, and supports programmable token functionality within a Turing-complete environment. BNB Smart Chain: BNB Smart Chain is a general-purpose Layer 1 blockchain that supports smart contract execution via the Ethereum Virtual Machine (EVM). The BASED token contract on BNB Smart Chain interacts with the BNB Smart Chain network using RPC-compatible clients. The BNB Smart Chain ecosystem enables composability with DeFi, NFT, and DAO infrastructure, and supports programmable token functionality within a Turing-complete environment. Hyperliquid HyperEVM: HyperEVM is the EVM-compatible execution environment running in parallel with HyperCore on the Hyperliquid Layer 1 blockchain. The BASED token contract on HyperEVM interacts with the network using EVM-compatible RPC clients. HyperEVM provides general-purpose smart-contract execution while interoperating with HyperCore, Hyperliquid's native on-chain order-book trading environment, via the chain's HyperCore-to-HyperEVM transfer primitives. |
|||
| H.4 Consensus mechanism | text | Ethereum: Ethereum uses a Proof-of-Stake (PoS) consensus mechanism. Validators are selected to propose and attest to new blocks based on the amount of ETH they have staked. Blocks are finalized through a checkpoint-based finality system, with strong economic incentives to penalize dishonest behavior. This mechanism supports decentralization, finality, and high security. This consensus model ensures the integrity of the blockchain, including the execution and recording of all associated transactions for the BASED token. BNB Smart Chain: BNB Smart Chain uses a Proof-of-Staked-Authority (PoSA) consensus mechanism. A limited set of validators are selected to produce and attest to new blocks based on the amount of BNB they have staked. This model is designed for high throughput and low transaction fees, combining elements of Delegated Proof-of-Stake (DPoS) and Proof-of-Authority (PoA) to achieve fast finality. This mechanism supports high performance and security, ensuring the integrity of the blockchain, including the execution and recording of all associated transactions for the BASED token. Hyperliquid HyperEVM: The Hyperliquid Layer 1 blockchain operates a custom Byzantine Fault Tolerant (BFT) consensus algorithm referred to as HyperBFT, in which a permissioned validator sets the network's native HYPE token. Transactions on HyperCore and HyperEVM are sequenced and finalized by the same validator set, providing deterministic finality with sub-second block times. Validator economic security is enforced through staked HYPE and protocol-level slashing of dishonest behavior. This consensus model ensures the integrity of the blockchain, including the execution and recording of all associated transactions for the BASED token on HyperEVM. |
|||
| H.5 Incentive mechanisms and applicable fees | text | Ethereum: Ethereum validators earn rewards in the native token (ETH) for producing and attesting to blocks. Gas fees are paid in ETH and are required to execute transactions or smart contract calls, including BASED token transfers. Under EIP-1559, a portion of the base fee is burned while the remainder is distributed to validators. Fees vary depending on network congestion and computational complexity of the transaction. BNB Smart Chain: BNB Smart Chain validators earn rewards in the native token (BNB) for producing and attesting to blocks. Gas fees are paid in BNB and are required to execute transactions or smart contract calls, including BASED token transfers. Fees vary depending on network congestion and the computational complexity of the transaction but are generally designed to be lower than on the Ethereum network. Hyperliquid HyperEVM: Validators on the Hyperliquid Layer 1 blockchain earn rewards in the native token (HYPE) for participating in HyperBFT consensus, with rewards funded through protocol issuance and the protocol's fee distribution model. Gas fees on HyperEVM are paid in HYPE and are required to execute transactions and smart contract calls, including BASED token transfers. Fees vary depending on the computational complexity of the transaction and on the relevant HyperEVM block-space pricing. |
|||
| H.6 Use of distributed ledger technology | boolean | ||||
| H.7 DLT functionality description | textBlock | ||||
| Other token audit details | |||||
| H.8 Audit | boolean | ||||
| H.9 Audit outcome | textBlock | ||||
| Part I - Information on risks | |||||
| I.1 Offer-related risks | textBlock | Risks associated with the admission to trading include; Service-related interruption; Holders may be unable to access the utility due to technical, operation, or regulatory disruptions. Jurisdictional limitations; BASED services or token utility may not be available in all jurisdictions, potentially restricting access. Platform reliance; Access depends on third-party infrastructure (wallets,platforms) and service interruptions or failures may affect token utility. Limited liability; OKX Europe Limited assumes no responsibility for the issuers project continuation, and token ownership does not confer contractual rights or guarantees. Unexpected Risks: Beyond the risks outlined in this whitepaper, there may be additional risks that are currently unforeseen. It is imperative to note that certain risks may emerge from unforeseen events, changes, or interactions among factors that are difficult to predict. These unexpected risks may significantly and negatively impact the crypto-asset, the project, or the parties involved. |
|||
| I.2 Issuer-related risks | textBlock | Counterparty Risks; Counterparty risks may arise where the issuer relies on third-party service providers or technology partners. Reputational Risks; Adverse media and/or damage or loss of key personnel could negatively affect the ecosystem that the BASED token lives on. Competition Risk; The issuer may face increased competition or changes in market conditions that affect its ability to carry out its objectives. Regulatory Risks; The issuer may be subject to investigations, enforcement actions, or change in regulation that affect the tokens legal status in certain jurisdictions. Disclosure Risks; The issuer may not be required to provide financial statements, limiting BASED token holders visibility into the financial health status of the issuer/project. Issuer Risks; The information provided is based solely on publicly available sources and does not constitute any form of guarantee or warranty as to its accuracy or completeness. Key Person Risk; The project and/or tokens success may rely on a small number of individuals or core team. If these individuals depart from the project, the direction and continuity of the project may be negatively affected in the future. Governance Risk; Projects that lack a formal, decentralised community governance mechanism, with decisions regarding protocol upgrades, treasury management, and strategic direction being made centrally by the project team may increase project centralisation risks. As a result, the direction of the project may rest predominantly with the issuer or a small group of contributors, which may affect the transparency of future changes, reduce alignment with user interests, and expose the project to operational or reputational risks if those central parties encounter difficulties or act in a manner contrary to the expectations of the broader community. |
|||
| I.3 Other tokens-related risks | textBlock | Utility Risk; The BASED tokens utility depends on access to certain services, and any modification or discontinuation of those services could reduce the associated utility of the token. Smart Contract Risk; The BASED token may operate through smart contracts that may contain vulnerabilities, even if audited, and upgrades to the protocol or governance changes may affect functionality. Liquidity Risk; Periods of low/limited liquidity may occur, particularly if the demand for the token or its use case decreases, which could have adverse effects on the BASED tokens price and future use cases. Token Unlock Risk; Scheduled vesting cliffs and token unlocks may significantly increase circulating supply, potentially causing volatility and/or downward price pressure. Project Maturity Risk; Tokens associated with recently launched projects may carry increased risk due to limited development history, untested infrastructure, and/or the absence of a proven track record. |
|||
| I.4 Project implementation-related risks | textBlock | Governance Risk; The project may be subject to governance processes that involve on-chain voting or community proposals. Misaligned incentives, low participation, or malicious actors may affect the outcome of governance decisions and disrupt the project's roadmap. Centralisation Risk; Similar to governance risks outlined above, centralisation within the governance process, or validator centralisation could lead to a lack of decentralization within the network, which carries future risks in terms of trust within the project, and also in regards to future roadmaps where plans may not reflect the interests of the broader user base. |
|||
| I.5 Technology-related risks | textBlock | Blockchain Performance Risk; The Ethereum, BNB Smart Chain, and Hyperliquid blockchains, on which the token is issued, may experience downtime or congestion, which could delay or prevent token transfer or utility usage. Consensus Failure Risk; A failure in the blockchain's consensus mechanism could result in halted transactions, unexpected behavior, or loss in network integrity. Smart Contract Vulnerabilities; Although the token uses audited or standard smart contract makeups (ERC-20 on Ethereum, BEP-20 on BNB Smart Chain, and ERC-20 on the Hyperliquid HyperEVM), undetected bugs, exploits, or implementation errors could compromise functionality or security. Upgradeability Risk; If the token or related contracts are upgradeable and have designated "owner" addresses, this introduces a central point of failure, and could be misused by malicious actors. Third-party Infrastructure Dependency; Interaction with the token or project may rely on external infrastructure (APIs, wallet services, off-chain governance voting). Outages or attacks may interrupt access to token-related services. Interoperability Risk; If the token interacts with other chains, bridges, or oracles, failures or exploits in those systems could affect the token's operations. Protocol-level Risk; Upgrades or forks of the protocol itself may affect the token, which could lead to compatibility issues and/or unexpected token behaviour. Emerging Technology Risk; Advances in computing or undiscovered vulnerabilities in cryptographic algorithms may pose long-term security risks to the blockchain or associated smart contracts. |
|||
| I.6 Mitigation measures | textBlock | Blockchain Performance Risk; The Ethereum, BNB Smart Chain, and Hyperliquid blockchains have each adopted consensus mechanisms designed to improve network scalability and reduce latency. Ongoing protocol upgrades to these networks are designed to enhance throughput, and per-network transaction fees help prioritise transactions under load. Consensus Failure Risk; The consensus mechanisms operated by the Ethereum, BNB Smart Chain, and Hyperliquid blockchains each include validator incentives, slashing or equivalent penalties for malicious actors, and finality mechanisms to ensure integrity. Validator sets are designed to be distributed to reinforce decentralization of each network. Smart Contract Vulnerabilities; Smart contracts on the Ethereum, BNB Smart Chain, and Hyperliquid blockchains are immutable by design, unless explicitly designed to be upgradeable. The ecosystems on each network encourage open source code, independent audits, and community input. Standardised libraries (such as OpenZeppelin for EVM-compatible chains) reduce coding errors by reusing tested components. Upgradeability Risk; The Ethereum, BNB Smart Chain, and Hyperliquid blockchains do not enforce upgrade functionalities within smart contracts but support their technical implementation. Risks related to upgradeable contracts can be mitigated through standard practices such as time-delay triggers and multi-signature wallets. Third-party Infrastructure Dependency; The Ethereum, BNB Smart Chain, and Hyperliquid blockchains and their ecosystems support decentralized indexing, querying, and RPC infrastructure to reduce reliance on centralized third-party data services. Interoperability Risk; Mitigations for cross-chain bridging across the Ethereum, BNB Smart Chain, and Hyperliquid blockchains include the use of audited bridges and token locking mechanisms. Protocol-level Risk; The Ethereum, BNB Smart Chain, and Hyperliquid blockchains each maintain public roadmaps and follow structured governance processes. Core updates to these networks undergo extensive testing and community review prior to implementation. Emerging Technology Risk; Developers across the Ethereum, BNB Smart Chain, and Hyperliquid blockchains monitor potential emerging-technology threats and actively research and develop quantum-resistant solutions. The modular designs of these networks may allow for future cryptographic upgrades if required. |
|||
| Part J - Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts | |||||
| J.1 Adverse impacts on climate and other environment-related adverse impacts | textBlock | ||||
| Mandatory information on principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism | |||||
| General information about adverse impacts | |||||
| S.1 Name | text | ||||
| S.2 Relevant legal entity identifier | text | ||||
| S.3 Name of the crypto-asset | text | ||||
| S.4 Consensus mechanism | text | The crypto-asset's Proof-of-Stake (PoS) consensus mechanism, introduced with The Merge in 2022, replaces mining with validator staking. Validators must stake at least 32 ETH every block a validator is randomly chosen to propose the next block. Once proposed the other validators verify the blocks integrity. The network operates on a slot and epoch system, where a new block is proposed every 12 seconds, and finalization occurs after two epochs (~12.8 minutes) using Casper-FFG. The Beacon Chain coordinates validators, while the fork-choice rule (LMD-GHOST) ensures the chain follows the heaviest accumulated validator votes. Validators earn rewards for proposing and verifying blocks, but face slashing for malicious behavior or inactivity. PoS aims to improve energy efficiency, security, and scalability, with future upgrades like Proto-Danksharding enhancing transaction efficiency. Hyperliquid is a decentralized perpetual exchange (DEX) built on its proprietary Layer 1 blockchain, Hyperliquid L1. At the core of its architecture is the HyperBFT consensus mechanism, inspired by the Hotstuff protocol, designed to meet the demands of high-frequency trading while maintaining security and consistency across the ecosystem. Binance Smart Chain (BSC) uses a hybrid consensus mechanism called Proof of Staked Authority (PoSA), which combines elements of Delegated Proof of Stake (DPoS) and Proof of Authority (PoA). This method ensures fast block times and low fees while maintaining a level of decentralization and security. Core Components 1. Validators (so-called \u201cCabinet Members\u201d): Validators on BSC are responsible for producing new blocks, validating transactions, and maintaining the network\u2019s security. To become a validator, an entity must stake a significant amount of BNB (Binance Coin). Validators are selected through staking and voting by token holders. There are 21 active validators at any given time, rotating to ensure decentralization and security. 2. Delegators: Token holders who do not wish to run validator nodes can delegate their BNB tokens to validators. This delegation helps validators increase their stake and improves their chances of being selected to produce blocks. Delegators earn a share of the rewards that validators receive, incentivizing broad participation in network security. 3. Candidates: Candidates are nodes that have staked the required amount of BNB and are in the pool waiting to become validators. They are essentially potential validators who are not currently active but can be elected to the validator set through community voting. Candidates play a crucial role in ensuring there is always a sufficient pool of nodes ready to take on validation tasks, thus maintaining network resilience and decentralization. Consensus Process 4. Validator Selection: Validators are chosen based on the amount of BNB staked and votes received from delegators. The more BNB staked and votes received, the higher the chance of being selected to validate transactions and produce new blocks. The selection process involves both the current validators and the pool of candidates, ensuring a dynamic and secure rotation of nodes. 5. Block Production: The selected validators take turns producing blocks in a PoA-like manner, ensuring that blocks are generated quickly and efficiently. Validators validate transactions, add them to new blocks, and broadcast these blocks to the network. 6. Transaction Finality: BSC achieves fast block times of around 3 seconds and quick transaction finality. This is achieved through the efficient PoSA mechanism that allows validators to rapidly reach consensus. Security and Economic Incentives 7. Staking: Validators are required to stake a substantial amount of BNB, which acts as collateral to ensure their honest behavior. This staked amount can be slashed if validators act maliciously. Staking incentivizes validators to act in the network's best interest to avoid losing their staked BNB. 8. Delegation and Rewards: Delegators earn rewards proportional to their stake in validators. This incentivizes them to choose reliable validators and participate in the network\u2019s security. Validators and delegators share transaction fees as rewards, which provides continuous economic incentives to maintain network security and performance. 9. Transaction Fees: BSC employs low transaction fees, paid in BNB, making it cost-effective for users. These fees are collected by validators as part of their rewards, further incentivizing them to validate transactions accurately and efficiently. |
|||
| S.5 Incentive mechanisms and applicable fees | text | The crypto-asset's PoS system secures transactions through validator incentives and economic penalties. Validators stake at least 32 ETH and earn rewards for proposing blocks, attesting to valid ones, and participating in sync committees. Rewards are paid in newly issued ETH and transaction fees. Under EIP-1559, transaction fees consist of a base fee, which is burned to reduce supply, and an optional priority fee (tip) paid to validators. Validators face slashing if they act maliciously and incur penalties for inactivity. This system aims to increase security by aligning incentives while making the crypto-asset's fee structure more predictable and deflationary during high network activity. Hyperliquid incentivizes participants through its native token, HYPE. Validators and delegators earn rewards in HYPE for securing the network and participating in governance. Users can also earn HYPE by staking, providing liquidity, and engaging in other ecosystem activities. This dual-token system encourages active participation and supports the network's growth and stability. Hyperliquid employs a dynamic fee model where transaction fees are based on network activity and the complexity of the transactions. These fees are paid by users conducting transactions on the network and are designed to cover the costs of processing transactions while incentivizing validators. Binance Smart Chain (BSC) uses the Proof of Staked Authority (PoSA) consensus mechanism to ensure network security and incentivize participation from validators and delegators. Incentive Mechanisms 1. Validators: Staking Rewards: Validators must stake a significant amount of BNB to participate in the consensus process. They earn rewards in the form of transaction fees and block rewards. Selection Process: Validators are selected based on the amount of BNB staked and the votes received from delegators. The more BNB staked and votes received, the higher the chances of being selected to validate transactions and produce new blocks. 2. Delegators: Delegated Staking: Token holders can delegate their BNB to validators. This delegation increases the validator's total stake and improves their chances of being selected to produce blocks. Shared Rewards: Delegators earn a portion of the rewards that validators receive. This incentivizes token holders to participate in the network\u2019s security and decentralization by choosing reliable validators. 3. Candidates: Pool of Potential Validators: Candidates are nodes that have staked the required amount of BNB and are waiting to become active validators. They ensure that there is always a sufficient pool of nodes ready to take on validation tasks, maintaining network resilience. 4. Economic Security: Slashing: Validators can be penalized for malicious behavior or failure to perform their duties. Penalties include slashing a portion of their staked tokens, ensuring that validators act in the best interest of the network. Opportunity Cost: Staking requires validators and delegators to lock up their BNB tokens, providing an economic incentive to act honestly to avoid losing their staked assets. Fees on the Binance Smart Chain 5. Transaction Fees: Low Fees: BSC is known for its low transaction fees compared to other blockchain networks. These fees are paid in BNB and are essential for maintaining network operations and compensating validators. Dynamic Fee Structure: Transaction fees can vary based on network congestion and the complexity of the transactions. However, BSC ensures that fees remain significantly lower than those on the Ethereum mainnet. 6. Block Rewards: Incentivizing Validators: Validators earn block rewards in addition to transaction fees. These rewards are distributed to validators for their role in maintaining the network and processing transactions. 7. Cross-Chain Fees: Interoperability Costs: BSC supports cross-chain compatibility, allowing assets to be transferred between Binance Chain and Binance Smart Chain. These cross-chain operations incur minimal fees, facilitating seamless asset transfers and improving user experience. 8. Smart Contract Fees: Deployment and Execution Costs: Deploying and interacting with smart contracts on BSC involves paying fees based on the computational resources required. These fees are also paid in BNB and are designed to be cost-effective, encouraging developers to build on the BSC platform. |
|||
| S.6 Beginning of period to which disclosed information relates | date | ||||
| S.7 End of period to which disclosed information relates | date | ||||
| Mandatory key indicator | |||||
| S.8 Energy consumption | energy (kWh) | ||||
| Sources and methodologies | |||||
| S.9 Energy consumption sources and methodologies | textBlock | To determine the energy consumption of a token, the energy consumption of the network Ethereum, Hyperliquid HyperEVM and BNB Smart Chain is calculated first. For the energy consumption of the token, a fraction of the energy consumption of the network is attributed to the token, which is determined based on the activity of the crypto-asset within the network. When calculating the energy consumption, the Functionally Fungible Group Digital Token Identifier (FFG DTI) is used - if available - to determine all implementations of the asset in scope. The mappings are updated regularly, based on data of the Digital Token Identifier Foundation. The information regarding the hardware used and the number of participants in the network is based on assumptions that are verified with best effort using empirical data. In general, participants are assumed to be largely economically rational. As a precautionary principle, we make assumptions on the conservative side when in doubt, i.e. making higher estimates for the adverse impacts. |
|||
| Supplementary information on principal adverse impacts on climate and other environment-related adverse impacts of consensus mechanism | |||||
| Supplementary key indicators | |||||
| S.10 Renewable energy consumption | percent | ||||
| S.11 Energy intensity | energy (kWh) | ||||
| S.12 Scope 1 DLT GHG emissions - controlled | GHG emissions (tCO2e) | ||||
| S.13 Scope 2 DLT GHG emissions - purchased | GHG emissions (tCO2e) | ||||
| S.14 GHG intensity | GHG emissions (tCO2e) | ||||
| Sources and methodologies | |||||
| S.15 Key energy sources and methodologies | textBlock | ||||
| S.16 Key GHG sources and methodologies | textBlock | ||||
| Optional information on principal adverse impacts on the climate and on other environment-related adverse impacts of the consensus mechanism | |||||
| Optional indicators | |||||
| S. 17 Energy mix | percent | ||||
| S.18 Energy use reduction | |||||
| Energy use reduction target (absolute value) | energy (kWh) | ||||
| Energy use reduction target (percentage) | percent | ||||
| S.19 Carbon intensity (kgCO2e/kWh) | decimal | ||||
| S.20 Scope 3 DLT GHG emissions - value chain | GHG emissions (tCO2e) | ||||
| S.21 GHG emissions reduction targets or commitments | textBlock | ||||
| S.22 Generation of waste electrical and electronic equipment (WEEE) | mass (tonnes) | ||||
| S.23 Non-recycled WEEE ratio | percent | ||||
| S.24 Generation of hazardous waste | mass (tonnes) | ||||
| S.25 Generation of waste (all types) | mass (tonnes) | ||||
| S.26 Non-recycled waste ratio (all types) | percent | ||||
| S.27 Waste intensity (all types) | mass (tonnes) | ||||
| S.28 Waste reduction targets or commitments (all types) | textBlock | ||||
| S.29 Impact of use of equipment on natural resources | textBlock | ||||
| S.30 Natural resources use reduction targets or commitments | textBlock | ||||
| S.31 Water use | volume (m3) | ||||
| S.32 Non recycled water ratio | percent | ||||
| Sources and methodologies | |||||
| S.33 Other energy sources and methodologies | textBlock | ||||
| S.34 Other GHG sources and methodologies | textBlock | ||||
| S.35 Waste sources and methodologies | textBlock | ||||
| S.36 Natural resources sources and methodologies | textBlock | ||||