| [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 | In this context, the Token will entitle its holders to a set of rights and obligations in their interactions with the Protocol. For instance, Token holders will be able to deposit their Tokens within the Protocol and earn Token rewards in exchange. Token rewards will be initially funded through the Protocol's treasury. Once the Protocol's governance is introduced and pre-defined revenue goals are met, a buyback mechanism will be implemented to use part of he Protocol's on-chain fees to purchase Tokens on the open market. Those bought-back Tokens will be used to reward those who deposit their Tokens within the Protocol. Additionally, fees collected by the Protocol will be used to fund its growth and further development. Additionally, depositing the Token within the Protocol will grant Token holders priority access to Protocol products based on their deposit status. The Token will also serve as the Protocol's governance token, allowing Token holders to participate in the Protocol's decision-making process. The Protocol will implement a progressive decentralisation framework, under which governance authority will transition from the Protocol's development team to Token holders over time, across five phases. In the initial phases, Token holders will be able to participate in non-binding temperature checks and appoint or remove Ecosystem Council members. As governance progressively decentralises, Token holders will be able to vote on DAO proposals and protocol upgrade decisions. Initially, any changes to the Token's rights, obligations, or features will be implemented by the Protocol's development team. Once the Protocol governance reaches the final phase of its decentralisation roadmap, changes to the Token's rights, obligations, or features will be implemented by the Protocol's governance. Changes to the Protocol and Token mechanics will be communicated through the Protocol's official channels and documentation. |
|||
| 09 Further information about utility tokens | textBlock | ||||
| 10 Key information about the offer to the public or admission to trading | textBlock | Additionally, a public offering of the Token within the European Union accompanies the trading platform admissions. The public offer of the Token is conducted to support the continued development, scaling, and decentralisation of the Protocol ecosystem. Proceeds from the sale will be used to expand the Protocol cross-chain infrastructure, including further development of the Coral intent layer, growth of integrations across supported blockchains, liquidity expansion, ecosystem incentives, and the development of the Protocol chain-abstracted consumer application. Therefore, the contents of this whitepaper have been drafted to include the relevant details pertaining to both an offer to the public and an admission to trading under MiCA. |
|||
| Part A - Information about offeror or person seeking admission to trading | |||||
| A.1 Name | text | ||||
| A.2 Legal form | text | ||||
| A.3 Registered address | |||||
| Registered addess | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| A.4 Head office | |||||
| Head office | text | ||||
| Country | enumeration | ||||
| Sub-division | text | ||||
| A.5 Registration date | date | ||||
| A.6 Legal entity identifier | LEI | ||||
| A.7 Another identifier required pursuant to applicable national law | text | ||||
| A.8 Contact telephone number | text | ||||
| A.9 E-mail address | text | ||||
| A.10 Response time (days) | integer | ||||
| A.11 Parent company | text | ||||
| A.12 Members of the management body | |||||
| Member #1 | id | 1 | |||
| Identity | text | ||||
| Business address | text | ||||
| Function | text | ||||
| A.13 Business activity | textBlock | ||||
| A.14 Parent company business activity | textBlock | ||||
| A.15 Newly established | boolean | ||||
| A.16 Financial condition for the past three years | textBlock | ||||
| A.17 Financial condition since registration | textBlock | Given this structure, the Person Seeking Admission to Trading is intentionally pre-revenue and maintains limited financial activity, with its role confined to token issuance and ancillary obligations related to the Token's public/community sales. Nonetheless, the broader Protocol is in a strong financial position, having processed more than USD 6 billion in cross-chain transaction volume and has been used by over 1 million uers. It It currently supports interoperability across more than 105 blockchains and is integrated with over 1,000 decentralised applications, wallets, and infrastructure providers. Considered collectively, these elements indicate that the Protocol, and consequently, the Person Seeking Admission to Trading, benefits from a robust financial runway and reflects a stable, sustainable financial position, notwithstanding the deliberate limited level of activity within the Person Seeking Admission to Trading itself. |
|||
| 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 | N/A | . | |||
| B.3 Legal form | N/A | . | |||
| B.4 Registered address | |||||
| Registered addess | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| B.5 Head office | |||||
| Head office | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| B.6 Registration date | N/A | . | |||
| B.7 Legal entity identifier | N/A | . | |||
| B.8 Another identifier required pursuant to applicable national law | N/A | . | |||
| B.9 Parent company | N/A | . | |||
| B.10 Members of the management body | |||||
| Member #1 | N/A | . | |||
| Identity | N/A | . | |||
| Business address | N/A | . | |||
| Function | N/A | . | |||
| B.11 Business activity | N/A | . | |||
| B.12 Parent company business activity | N/A | . | |||
| 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 | N/A | . | |||
| C.2 Legal form | N/A | . | |||
| C.3 Registered address | |||||
| Registered address | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| C.4 Head office | |||||
| Head office | N/A | . | |||
| Country | N/A | . | |||
| Sub-division | N/A | . | |||
| C.5 Registration date | N/A | . | |||
| C.6 Legal entity identifier | N/A | . | |||
| C.7 Another identifier required pursuant to applicable national law | N/A | . | |||
| C.8 Parent company | N/A | . | |||
| C.9 Reason for crypto-asset white paper preparation | N/A | . | |||
| C.10 Members of the management body | |||||
| Member #1 | N/A | . | |||
| Identity | N/A | . | |||
| Business address | N/A | . | |||
| Function | N/A | . | |||
| C.11 Operator business activity | N/A | . | |||
| 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 | - Squid Router: The Protocol's cross-chain swap engine. It allows users to exchange any token on one supported blockchain for any token on another in a single transaction. Swap transactions are routed through axlUSDC, Axelar's wrapped version of USDC, as an intermediate asset. Axelar's generalised message passing ('GMP') infrastructure relays cross-chain messages between smart contracts on different blockchains; therefore, the execution of cross-chain transactions on the destination chain does not require a second user signature. The Protocol also supports cross-chain transactions involving Bitcoin and Solana through an integration with Chainflip, a decentralised exchange ('DEX') protocol, and multi-protocol routing paths combining Axelar, the Inter-Blockchain Communication ('IBC') protocol, the Cross-Chain Transfer Protocol ('CCTP'), and Chainflip. - CORAL (Cross-Chain Order Routing and Auction Layer): The Protocol's intent-based cross-chain order routing and auction layer. CORAL allows users to specify a desired transaction outcome and enables third-party solvers to compete to fulfil the user's transaction intent at the best available price and routing path, targeting sub-5-second cross-chain execution. Rather than relying solely on automated market makers ('AMMs'), CORAL enables solvers to source liquidity and execute transactions across multiple liquidity providers and routing paths, allowing the Protocol to access a broader range of liquidity sources. CORAL relies on Axelar's GMP infrastructure. - Squid Wallet View: A non-custodial portfolio management interface that allows users to connect multiple wallets and view their token balances, prices, and portfolio performance data across supported blockchains. Users can also initiate cross-chain swaps directly from the interface, with transactions signed through third-party wallet interfaces. - Developer Integration Tools: An API, an SDK, and an embeddable swap widget, to allow any developer to integrate cross-chain swap functionalities into their own applications without directly interacting with the Protocol's smart contracts. Fees collected by the Protocol will be used to buy Tokens on the open market through a buyback mechanism and to fund the growth of the Protocol. The bought-back Tokens will be used to reward those who deposit their Tokens within the Protocol. The Protocol's governance model is designed around a progressive decentralisation framework, under which authority over protocol upgrades and governance decisions is intended to transition from the Protocol's development team to Token holders over time, across five phases (Phase 0 through Phase 4). The governance structure comprises two bodies: an Ecosystem Council, a 3-member multisig that advises the Protocol's Foundation on ecosystem growth and grants and oversees community governance processes; and a Security Council, a 3-member multisig that manages protocol upgrades and emergency fixes. |
|||
| 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 | ||||
| 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 | The Protocol currently supports more than 105 blockchains, providing interoperability across EVM-compatible chains, Cosmos-based chains, Bitcoin, Solana, and the XRP Ledger. The Protocol was integrated with over 1,000 decentralised applications, wallets, and infrastructure providers within the digital asset ecosystem, and it has processed more than USD 6 billion in cross-chain transaction volume across more than 3.7 million transactions, with more than 1 million users having interacted with the Protocol. CORAL, the Protocol's intent-based cross-chain order routing and auction layer, was developed and deployed, enabling sub-5-second transaction execution. The Protocol also developed and launched Squid Wallet View, a non-custodial portfolio management interface, and NFT Checkout, a now-discontinued cross-chain NFT purchasing tool. Eight security audits of the Protocol's smart contracts and infrastructure have been completed. |
|||
| Description of future milestones | textBlock | Deposits and Rewards: Activating Token deposits and rewards, and the Protocol's buyback mechanism. Governance: Activating the Protocol's governance framework, beginning with non-binding temperature checks and the appointment of Ecosystem Council members, and advancing through subsequent phases to DAO-governed control of capital allocation and governance decisions. Chain-Abstracted Application Layer: Developing and launching a chain-abstracted application layer to simplify user interaction with multiple blockchains through a unified interface. Expansion of Supported Chains and Integrations: Continuing the expansion of the Protocol's supported blockchains, digital assets, and ecosystem integrations. Further CORAL Development: Continuing the development of CORAL, with improvements to cross-chain execution coordination and liquidity sourcing. |
|||
| D.9 Resource allocation | text | - Full-time engineering and product development teams; Infrastructure for cross-chain transaction routing; - Security reviews and protocol testing; - Ecosystem partnerships with blockchain networks; and - Liquidity provisioning infrastructure and integrations. Funding has been provided through venture investment, ecosystem grants from blockchain networks, and Protocol-related revenues. |
|||
| D.10 Planned use of collected funds or other tokens | text | - Continued protocol development and engineering; - Security reviews and infrastructure operations; - Ecosystem partnerships and integrations; - Liquidity incentives and market development; and - Community growth and governance participation. |
|||
| 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 | Additionally, a public offering of the Token within the European Union accompanies the trading platform admissions. The public offer of the Token is conducted to support the continued development, scaling, and decentralisation of the Protocol ecosystem. Proceeds from the sale will be used to expand the Protocol cross-chain infrastructure, including further development of the Coral intent layer, growth of integrations across supported blockchains, liquidity expansion, ecosystem incentives, and the development of the Protocol chain-abstracted consumer application. |
|||
| E.3 Fundraising target | |||||
| Target expressed in currency | monetary | USD | |||
| Target expressed in units | decimal | ||||
| Target expressed in digital token identifier | text | ||||
| E.4 Minimum subscription goals | |||||
| Goals expressed in currency | monetary | USD | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.5 Maximum subscription goals | |||||
| Goasl expressed in currency | monetary | USD | |||
| 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 | - If the offer is cancelled - If the purchaser exercises his/her right to withdrawal as outlined in Article 13 of MiCA and outlined in E.15 of this whitepaper - If the minimum target subscription goal is not reached |
|||
| E.17 Refund timeline | text | - If the offer is cancelled by the Offeror, refunds will be processed within 14 calendar days from the date of the cancellation announcement. - If a purchaser exercises their right of withdrawal under Article 13 of MiCA, refunds will be processed until the end of the subscription period, in accordance with E.22 of this whitepaper. - If the minimum target subscription goal is not achieved by the end of the subscription period, all contributions will be automatically refunded within 14 calendar days from the subscription period end date. |
|||
| E.18 Offer phases | textBlock | - Announcement Phase: Public communication of the sale, including publication of the crypto-asset whitepaper and relevant disclosures. - Subscription Period: Eligible participants may subscribe to purchase Tokens through the designated placement platform. - Allocation and Settlement Phase: Final allocations are determined following the end of the subscription period. - Token Distribution Phase: At the TGE, purchased Tokens are transferred in full to purchasers in accordance with E.27 and E.28, without vesting or lock-up. |
|||
| 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 | All payments received from a retail holder and if applicable, any charges, shall be reimbursed without undue delay, in any event, no later than 14 days from the date on which is informed of the retail holder's decision to withdraw from the agreement to purchase the Token. This reimbursement will be carried out using the same means of payment used by the retail holder for the initial transaction, unless the retail holder expressly agrees otherwise and provided that the retail holder does not incur any fees or costs as a result of such reimbursement. That being said, this right of withdrawal shall not apply where the Token has been admitted to trading prior to their purchase by the retail holder. |
|||
| E.27 Transfer of purchased other tokens | textBlock | ||||
| E.28 Transfer time schedule | text | ||||
| E.29 Purchaser's technical requirements | textBlock | - A compatible digital wallet or account on supported exchanges; - Internet access; - A device (computer or mobile) to manage a digital wallet/private key and/or account on an exchange to carry out transactions |
|||
| 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 | - Kraken - OKX - Bybit - Coinbase - Binance - Bitget - Revolut - Gate.io - Bitstamp |
|||
| 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 | The Token qualifies as a crypto-asset within the meaning of MiCA, as it a digital representation of the right to access the Ecosystem and participate in the Ecosystem's governance. The Token can be transferred and stored using the distributed ledger technology ("DLT"). The Token facilitates Token holders' interaction with the Network by displaying the following functionalities: - Deposits: Token holders will be able to deposit their Tokens within the Protocol. - Rewards: Token holders who deposit their Tokens within the Protocol will receive Token rewards initially sourced by the Protocol's treasury, and, once implemented, also by the Protocol's buyback mechanism. - Governance: The Token will serve as the Protocol's governance token. - Special Access: Depositing the Token within the Protocol will grant Token holders priority access to Protocol products, based on their deposit status. |
|||
| 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 | In this context, the Token will entitle its holders to a set of rights and obligations in their interactions with the Protocol. For instance, Token holders will be able to deposit their Tokens within the Protocol and earn Token rewards in exchange. Token rewards will be initially funded through the Protocol's treasury. Once the Protocol's governance is introduced and pre-defined revenue goals are met, a buyback mechanism will be implemented to use part of the Protocol's on-chain fees to purchase Tokens on the open market. Those bought-back Tokens will be used to reward those who deposit their Tokens within the Protocol. Additionally, fees collected by the Protocol will be used to fund its growth and further development. The Token will also serve as the Protocol's governance token, allowing Token holders to participate in the Protocol's decision-making process. The Protocol will implement a progressive decentralisation framework, under which governance authority will transition from the Protocol's development team to Token holders over time, across five phases. In the initial phases, Token holders will be able to participate in non-binding temperature checks and appoint or remove Ecosystem Council members. As governance progressively decentralises, Token holders will be able to vote on DAO proposals and protocol upgrade decisions. Additionally, depositing the Token within the Protocol will grant Token holders priority access to Protocol products based on their deposit status. Initially, any changes to the Token's rights, obligations, or features will be implemented by the Protocol's development team. Once the Protocol governance reaches the final phase of its decentralisation roadmap, changes to the Token's rights, obligations, or features will be implemented by the Protocol's governance. Changes to the Protocol and Token mechanics will be communicated through the Protocol's official channels and documentation. |
|||
| 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 | Solana: H949LTL82 |
|||
| 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 | - Deposits: Token holders will be able to deposit their Tokens within the Protocoll and receive Token rewards. - Rewards: Token holders who deposit their Tokens within the Protocol will be entitled to receive Token rewards initially sourced by the Protocol's treasury, and, once implemented, also by the Protocol's buyback mechanism. - Governance: Token holders will be entitled to participate in the Protocol's governance, including non-binding temperature checks and, as governance progressively decentralises, DAO proposals and protocol upgrade decisions. - Special Access: Token holders who deposit their Tokens within the Protocol will be entitled to priority access to Protocol products, tied to their deposit status. |
|||
| G.2 Exercise of rights and obligations | textBlock | - Deposits: To exercise their deposit rights, Token holders must deposit their Tokens within the Protocol. - Rewards: To receive Token rewards, Token holders must deposit their Tokens within the Protocol. - Governance: To exercise their governance rights, Token holders must hold the Token and participate in governance initiatives. - Special Access: To benefit from priority access to Protocol products, Token holders must deposit their Tokens within the Protocol. |
|||
| 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 | ||||
| H.3 Technology used | textBlock | ||||
| H.4 Consensus mechanism | text | The following applies to Solana: Solana uses a combination of Proof of History (PoH) and Proof of Stake (PoS). The core concepts of the mechanism are intended to work as follows: Core Concepts 1. Proof of History (PoH): PoH is a cryptographic ordering and timing mechanism that provides evidence that data existed in a particular sequence and that time passed between proofs. Verifiable Delay Function (VDF): PoH relies on a sequential hash-based proof process that Solana describes as VDF-like. This sequence of hashes provides a verifiable order of events, enabling the network to efficiently agree on the sequence of transactions. 2. Proof of Stake (PoS): Validator Selection: Leader slots are assigned through the network's leader schedule, which is stake-weighted. The more SOL staked, the higher the chance of being selected to validate transactions and produce new blocks. Delegation: Token holders can delegate their SOL tokens to validators, earning rewards proportional to their stake while contributing to the network's security. Consensus Process 1. Transaction Validation: Transactions are broadcasted to the network and collected by validators. Each transaction is validated to ensure it meets the network's criteria, such as having correct signatures and sufficient funds. 2. PoH Sequence Generation: A validator generates a sequence of hashes using PoH, each containing a timestamp and the previous hash. This process creates a historical record of transactions, establishing a cryptographic clock for the network. 3. Block Production: The network uses PoS to select a leader validator based on their stake. The leader is responsible for bundling the validated transactions into a block. The leader validator uses the PoH sequence to order transactions within the block, ensuring that all transactions are processed in the correct order. 4. Consensus and Finalisation: Other validators vote on the ledger state associated with the block. A block may first become confirmed and later finalised once it reaches the network's strongest confirmation state. Security and Economic Incentives 1. Incentives for Validators: Block Rewards: Validators earn rewards for producing and validating blocks. These rewards are distributed in SOL tokens and are proportional to the validator's stake and performance. Transaction Fees: Validators also earn transaction fees from the transactions included in the blocks they produce. These fees provide an additional incentive for validators to process transactions efficiently. 2. Security: Staking: Staking provides economic alignment, and Solana documentation notes that slashing has been discussed as a future mechanism for intentional malicious behaviour, but is not implemented yet. Delegated Staking: Token holders can delegate their SOL tokens to validators, intended to enhance network security and decentralisation. Delegators share in the rewards and are incentivised to choose reliable validators. 3. Economic Penalties: Slashing (planned): Validators can be penalised for malicious behaviour, such as double-signing or producing invalid blocks. This penalty, known as slashing, results in the loss of a portion of the staked tokens, discouraging dishonest actions. The following applies to Base: Base is a Layer-2 (L2) solution on Ethereum that was introduced by Coinbase and developed using Optimism's OP Stack. L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-stake) thus indirectly secures all L2 transactions as soon as they are written to L1. |
|||
| H.5 Incentive mechanisms and applicable fees | text | The following applies to Solana: 1. Validators: Validators participate in block production and voting under Solana's stake-weighted model. They may receive staking-related rewards and a share of transaction-fee income. Under Solana's fee model, the base fee is split between burn and validator compensation, while any prioritisation fee is paid to the validator. Transaction Fees: Validators earn a portion of the transaction fees paid by users for the transactions they include in the blocks. This is intended to provide an additional financial incentive for validators to process transactions efficiently and maintain the network's integrity. 2. Delegators: Delegated Staking: Token holders who do not wish to run a validator node can delegate their SOL tokens to a validator. In return, delegators share the rewards earned by the validators. This is intended to encourage widespread participation in securing the network and to support decentralisation. 3. Economic Security: Solana staking documentation notes slashing as a possible future mechanism for intentional malicious conduct, but states that slashing is not implemented in the protocol today. Economic alignment instead currently arises primarily from staking participation, validator performance incentives, and the opportunity cost of locking capital in staking positions. Fees Applicable on the Solana Blockchain 1. Transaction Fees: Solana transactions require fees in SOL. The fee model consists of a base fee and, where used, an optional prioritisation fee. The base fee compensates signature verification work and is split between burn and validator compensation, while any prioritisation fee is paid to the validator. 2. Rent Fees: Solana accounts that store onchain state must satisfy the rent-exemption threshold, which is linked to the amount of data stored. This mechanism is intended to support efficient use of network state and account storage resources. 3. Program Execution Costs: Deploying and interacting with onchain programs may involve transaction fees and, where relevant, compute-related prioritisation fees and account-storage requirements. These mechanisms are intended to allocate network resources in proportion to use. The following applies to Base: Base is a Layer-2 (L2) solution on Ethereum that uses optimistic rollups provided by the OP Stack on which it was developed. Transaction on base are bundled by a, so called, sequencer and the result is regularly submitted as an Layer-1 (L1) transactions. This way many L2 transactions get combined into a single L1 transaction. This lowers the average transaction cost per transaction, because many L2 transactions together fund the transaction cost for the single L1 transaction. This creates incentives to use base rather than the L1, i.e. Ethereum, itself. To get crypto-assets in and out of base, a special smart contract on Ethereum is used. Since there is no consensus mechanism on L2 an additional mechanism ensures that only existing funds can be withdrawn from L2. When a user wants to withdraw funds, that user needs to submit a withdrawal request on L1. If this request remains unchallenged for a period of time the funds can be withdrawn. During this time period any other user can submit a fault proof, which will start a dispute resolution process. This process is designed with economic incentives for correct behaviour. |
|||
| 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 | Each audit reviews all changes to the code to ensure a high degree of security. The reports of each audit can be found at the following link: https://docs.squidrouter.com/additional-resources/audits-and-security |
|||
| Part I - Information on risks | |||||
| I.1 Offer-related risks | textBlock | Regulatory Compliance Risks: Although the Token is designed to comply with existing regulations (such as MiCA), evolving regulatory landscapes could impact its classification, trading status, or market/ community acceptance. Changes in regulatory requirements may necessitate modifications to the Network's operation, structure, or governance. Token holders must ensure compliance with local laws, as regulatory treatment of crypto-assets varies across jurisdictions. Market Volatility: The Token is subject to extreme price fluctuations, influenced by market speculation, investor sentiment, and broader industry trends. External factors, such as regulatory announcements or technological developments, may further contribute to volatility, potentially leading to financial losses for holders. Liquidity Risks: The ability to buy, sell or otherwise transact Tokens depends on activity on decentralised exchanges ("DEXs") and, if applicable, centralised exchanges ("CEXs"). Limited liquidity may result in difficulties executing large trades without significant price impact, increasing the risk of loss. Risk of Trading Platforms: When Token holders trade on Exchanges, the Person Seeking Admission to Trading does not act as a contractual party to these transactions. All legal relationships regarding these trading platforms are subject to their respective terms and conditions, with no responsibility assumed by the Person Seeking Admission to Trading for their operations, services, or outcomes. Risk of Delisting: There is no guarantee that the Token will remain listed on any exchange. Delisting could significantly hinder the ability to trade Tokens, reducing liquidity and market value. Risk of Bankruptcy: The Exchanges or trading platforms where the Token is listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or Tokens. Blockchain and Smart Contract Dependency: The Token relies entirely on its blockchain infrastructure. Any network downtime, congestion, security vulnerabilities, or smart contract failures could negatively impact its functionality, accessibility, or security. Additionally, the Network may initially operate under a centralised or permissioned model, where specific providers or node operators manage the network. This structure presents centralisation risks, including the potential for censorship or data monetisation. Operational Risks: Risks associated with the Token issuer/offeror's internal processes, personnel, and technologies may impact the ability to manage the Token's operations effectively. Failures in operational integrity could lead to disruptions, financial losses, or reputational damage. Financial Risks: The Token issuer/offeror may face financial risks, including liquidity shortages, credit risks, or market fluctuations, which could affect its ability to continue operations, meet obligations, or sustain the stability and value of the Token. Legal Risks: Uncertainties in legal frameworks, regulatory changes, potential lawsuits, or adverse legal rulings could pose significant risks, affecting the legality, usability, or value of the Token. Fraud and Mismanagement Risks: The risk of fraudulent activity or mismanagement within the Token issuer/offeror's operations may impact the credibility of the project and the usability or value of the Token. Reputational Risks: Negative publicity – whether due to operational failures, security breaches, or associations with illicit activities – could damage the Token issuer/offeror's reputation and, by extension, impact the value and acceptance of the Token. Technology Management Risks: Inadequate management of technological updates or failure to keep pace with advancements may result in security vulnerabilities, inefficiencies, or obsolescence of the Token and its supporting infrastructure. Dependency on Key Individuals: The success of the Token and its ecosystem may be highly dependent on key individuals. Loss or changes in project leadership could lead to operational disruptions, a loss of trust, or potential project failure. Conflicts of Interest: Misalignment of interests between the Token issuer/offeror and Token holders may lead to governance decisions that are not in the best interests of the community, potentially affecting the value of the Token or damaging the credibility of the project. Counterparty Risks: The Token issuer/offeror's reliance on external partners, service providers, and collaborators introduces risks related to non-fulfilment of obligations, which may affect the Token's operations, liquidity, or overall ecosystem stability. Industry Competition Risks: The Token issuer/offeror faces competition from other projects, including larger and well-funded ventures that may attract more users and liquidity, potentially diminishing the viability of the Token. Investor Vesting Risks: While Tokens allocated to the team and other stakeholders may be subject to a vesting schedule to prevent "rug pulls" and conflicts of interest, the unlocking of Tokens over time could affect supply and demand trends and liquidity. Speculative Nature of the Token: Other than as stated herein with respect to the rights, functions, governance, staking, and fee-payment, the Token has no inherent utility beyond market sentiment and community-driven interest. Its value is highly speculative and subject to fluctuations based on external perceptions. Unanticipated Risks: There may be additional risks that cannot be foreseen. Some risks may materialise as unexpected variations or combinations of the factors discussed in this section. |
|||
| I.2 Issuer-related risks | textBlock | ||||
| I.3 Other tokens-related risks | textBlock | Speculative Nature: No assurances of future value, performance, or rewards are made regarding the Token. Other than as stated herein with respect to the rights, functions, governance, staking, and fee-payment, the Token has no inherent or guaranteed utility beyond its role in the Network, and its valuation depends entirely on user adoption, demand, and community engagement. If adoption of the Network fails to grow as expected, the Token's value may be significantly impacted. Liquidity Risks: The ability to trade the Token depends on the level of activity on DEXs and, where applicable, CEXs. Low trading volume may result in difficulties executing large transactions without significant price impact. Limited demand for the Token or the underlying protocol may further reduce liquidity, making it difficult to acquire, sell or otherwise transact with the Token. Adoption and Network Demand Risks: The long-term success of the Token is dependent on widespread adoption of the Network. Adoption is influenced by various external factors, including user demand, competitive economic conditions, and organic community-driven expansion. The Person Seeking Admission to Trading has no control over the pace of adoption, and there is no guarantee that the Network will gain sufficient traction to sustain its economic model. If demand is too low, obtaining services through the Network may be difficult, while an inadequate supply may lead to delays in accessing services. Blockchain Dependency Risks: The Token operates exclusively on its underlying blockchain network. Any disruptions, such as network congestion, downtime, or security vulnerabilities, could impact the ability to transfer, store, or trade the Token. Changes to blockchain infrastructure, governance, or transaction fees may also influence the Token's usability and cost-effectiveness. Transaction Costs: While blockchain fees are generally low, network congestion, high demand, or changes in blockchain fee structures may increase transaction costs, potentially reducing the economic viability of using the Token within the Network. Security Risks: Smart Contract Vulnerabilities: Despite security audits and best practices, unforeseen vulnerabilities in smart contracts could lead to security breaches, impacting Token security or functionality. Private Key Management: Token holders are solely responsible for safeguarding their private keys and recovery phrases. Loss of wallet credentials will result in the permanent loss of Tokens, as blockchain transactions are irreversible. Scam and Fraud Risks: Token holders are exposed to risks associated with scams, phishing attacks, fake giveaways, impersonation of the Token issuer/offeror or its team, counterfeit Tokens, and fraudulent airdrops. Engaging with unverified third-party platforms or unofficial communications increases the risk of fraud. Community and Narrative Risks: The Token's success is closely tied to community interest and the broader crypto narrative. Macroeconomic trends, emerging competitors, or declining community engagement may negatively impact the Token's perceived value and adoption. Regulatory and Compliance Risks: Evolving Legal Frameworks: Regulations governing crypto-assets differ across jurisdictions and are subject to change. New legal requirements may impact the Token's classification, availability, or functionality. Jurisdictional Restrictions: Some jurisdictions may impose restrictions or prohibitions on the trading or use of the Token, limiting its accessibility for certain users. Regulatory Harmonisation Risks: A lack of global regulatory alignment may create uncertainty, with some authorities potentially classifying the Token as a security or financial instrument, leading to increased compliance costs and legal obligations. Regulatory Enforcement Risks: Government agencies may take enforcement actions against the Token issuer/offeror if the Token is deemed an unregistered security or if other financial laws are found to have been violated. Such actions could negatively impact the Token's availability, appeal, and value. Anti-Money Laundering ("AML") & Counter-Terrorism Financing ("CTF") Risks: Crypto transactions may be scrutinised for potential links to illicit activities. Authorities may take action against wallets or platforms suspected of facilitating money laundering or terrorist financing, affecting the ability of Token holders to use or trade their assets. Taxation Risks: The tax treatment of the Token varies by jurisdiction, and Token holders are solely responsible for understanding and complying with applicable tax laws. Any appreciation, conversion, or sale of the Token may trigger tax obligations that differ depending on the regulatory environment. Team Vesting and Token Release Risks: Tokens allocated to the team and other stakeholders may be subject to a vesting and unlock schedule. When these Tokens are vested, unlocked, and released into circulation, they may affect demand trends and liquidity. Technological Obsolescence Risks: The blockchain and crypto industries evolve rapidly. The emergence of new technologies, changes in market demand, or advancements in competing protocols could render the Token or its underlying blockchain infrastructure less competitive, reducing adoption and utility. Software Weakness Risks: The Token's infrastructure relies on relatively new blockchain technologies, which may contain undiscovered bugs, vulnerabilities, or inefficiencies. There is no guarantee that the process of transacting, storing, or interacting with the Token will be uninterrupted or error-free. Unanticipated Risks: Beyond the risks outlined above, additional unforeseen risks may emerge due to changes in regulatory, technological, or macroeconomic conditions, potentially affecting the Token's security, functionality, or value. |
|||
| I.4 Project implementation-related risks | textBlock | Technical Development Risks: Smart Contract Issues: Despite robust security measures, unforeseen vulnerabilities or bugs in the smart contracts could disrupt Token distribution, refunds, or vesting mechanisms. Blockchain Dependency: The Token operates exclusively on its underlying blockchain. Any network congestion, downtime, or security breaches could impact the project's implementation and functionality. Risk of Security Weaknesses in Core Infrastructure: The project relies on open-source software, which may be modified by third parties not directly affiliated with the Issuer. Weaknesses or bugs introduced into the core infrastructure could compromise security and lead to the loss of digital assets. Furthermore, malfunctions or inadequate maintenance of the Network may negatively impact the Token's usability. Bugs in Core Blockchain Code: Even with rigorous testing, unknown bugs may exist in the blockchain protocol, potentially leading to disruptions, incorrect transaction processing, or security vulnerabilities. Regulatory and Compliance Risks: Regulatory Actions in One or More Jurisdictions: The Token and the underlying Network could be impacted by regulatory inquiries or actions, which may restrict further development, implementation, or usage. Evolving Laws and Regulations: New and changing laws related to financial securities, consumer protection, data privacy, cybersecurity, and intellectual property could impact the project. Compliance with these laws may require significant resources and could impose additional operational constraints. Governance Risk: Decision-making mechanisms in blockchain governance may be inefficient, slow, or disproportionately influenced by specific stakeholders, leading to potential centralisation or unfavourable network changes. Operational Risks: Resource Allocation: The project's success depends on the issuer of the Token and its core team allocating sufficient resources (both financial and non-financial) to ensure timely development and deployment. Poor resource management could lead to delays or failure to achieve key milestones. Team Vesting Risks: While the team's Tokens may be subject to a vesting and unlock schedule to align interests with the community, the eventual vesting and unlocking of these Tokens may impact market stability or long-term commitment from team members. Market Adoption Risks: Competitive Environment: The crypto industry is highly competitive and trend-driven. There is a risk that the Token may fail to capture sufficient interest, limiting its adoption. Community Engagement Risks: The success of the Token depends heavily on community-driven sentiment and engagement. Failure to build or sustain an active community could hinder growth and long-term tradability Timeline and Milestone Risks: Delayed Milestones: Key deliverables such as Token distribution and liquidity access may face delays due to technical, operational, or funding challenges. CEX Listing Risks: Listings on centralised exchanges depend on securing the necessary funding for listing fees and meeting platform-specific requirements. Delays or insufficient resources could postpone broader market/ community access. Ecosystem Risks: Dependence on External Partners: The project relies on partnerships with infrastructure providers, liquidity providers/ market makers, exchanges and other third-party service providers. Any failure or delay from these partners could disrupt implementation plans. Risk of Withdrawing Partners: The Token holder understands that the feasibility of the project depends strongly on the collaboration of service providers and other key stakeholders. A loss of critical partnerships could impact project sustainability. Technology and Software Risks: Risk of Software Weakness: The Token holder acknowledges that blockchain and smart contract technologies are still evolving. There is no guarantee that Token usage will be uninterrupted or error-free. Vulnerabilities in the underlying blockchain, smart contracts, or supporting technologies could lead to the complete loss of Tokens or their functionality. Dependency on Underlying Technology: The Network relies on blockchain infrastructure, hardware, and network connectivity, all of which may be subject to failures, outages, or vulnerabilities. Risk of Technological Disruption: The emergence of new technology, such as quantum computing, could undermine the security of blockchain encryption and compromise the integrity of digital assets. Network Security Risks: Network Attacks and Cybersecurity Threats: Blockchain networks can be vulnerable to cyberattacks such as 51% attacks, Sybil attacks, or distributed denial-of-service ("DDoS") attacks. These threats could disrupt network operations and compromise security. Blockchain Network Attacks: The Network may be subject to validation attacks, including double-spend attacks, reorganisations, majority mining power attacks, "vampire" attacks and work race condition attacks. Successful attacks could compromise the proper execution of transactions and smart contracts. Privacy and Anonymity Risks: Public Ledger Transparency: Blockchain transactions are recorded on a public ledger, which may expose transaction history and financial activity. Certain transactions could be linked to specific wallet addresses, making users vulnerable to fraud, phishing attacks, or targeted scams. Economic and Governance Risks: Consensus Failures or Forks: Errors in the consensus mechanism could lead to forks, where multiple versions of the ledger coexist, or network halts, reducing trust in the network. Economic Self-Sufficiency: The long-term sustainability of the Token ecosystem depends on sufficient transaction volume to generate fees to support rewards for validators, which in turn maintain network security. A lack of adoption could lead to governance-driven changes to monetary policy, fee structures, or consensus mechanisms. Incentive Model Risks: Changes to block rewards, staking incentives, or governance models may be required to maintain network participation. Governance decisions could result in modifications that impact Token holders, including inflationary adjustments, transaction fees, or redistribution of rewards. Software Weakness Risks: Unforeseen Bugs and Security Vulnerabilities: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures. Unanticipated Risks: Unforeseen Regulatory, Technological, or Economic Challenges: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory crackdowns, unforeseen Network vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. |
|||
| I.5 Technology-related risks | textBlock | Blockchain Dependency Risks: Network Downtime and Congestion: The Token relies entirely on its underlying blockchain network, which may experience outages, congestion, or downtime. Such events could disrupt Token transfers, trading, or other functionalities. Scalability Challenges: As transaction volume grows, the blockchain network may face scaling limitations. Increased congestion could lead to slower transaction processing times and higher fees, reducing efficiency and usability. Settlement and Transaction Finality Risks: Blockchain transactions are designed to be irreversible; however, under exceptional circumstances such as network forks or consensus failures, there remains a theoretical risk that transactions could be reversed, or multiple competing ledger versions could persist. Transactions sent to an incorrect address are not recoverable, leading to permanent loss of assets. Smart Contract Risks: Vulnerabilities: While smart contracts are developed with security measures, undiscovered vulnerabilities or exploits may impact Token security, distribution, or access. Bugs in the contract code may lead to unintended loss of Tokens, unauthorised transactions, or exposure to external attacks. Immutability Risks: Once deployed, some smart contracts cannot be altered. Errors or security flaws in the code could result in operational failures without the possibility of corrections. Security Exploits: Bugs or vulnerabilities in smart contracts may expose the Token ecosystem to potential hacks, allowing attackers to manipulate transactions, drain liquidity, or disrupt contract execution. Network Security Risks: Risk of Attacks and Forks: The blockchain may be susceptible to consensus-related attacks, such as double-spend attacks, majority validation power takeovers, censorship attacks, or forks. These risks could affect Token transactions, balance integrity, and overall network security. Cybercrime and Theft Risks: Despite security efforts, blockchain-based assets and services may be exposed to cyberattacks, including hacking, phishing, or malware threats. Compromised wallets, exchanges, or smart contracts could lead to asset theft, loss of funds, or disruptions in Token functionality. Data Corruption Risks: The reliability of blockchain data could be compromised due to software bugs, human error, or deliberate tampering. Such incidents may affect transaction records, network integrity, and user confidence in the system. Wallet and Storage Risks: Private Key Management: Token holders are solely responsible for securing their private keys and recovery phrases. The loss of private keys results in irreversible loss of Tokens, as blockchain transactions are final and cannot be undone. Compatibility Issues: The Token is supported only by blockchain-compatible wallets. Incompatibility with specific wallet software, network malfunctions, or wallet provider shutdowns may affect access to and usability of the Token. Ecosystem Dependency Risks: DEX and CEX Integration Issues: The Token's availability depends on integration with DEXs and CEXs. Technical failures, security breaches, or delisting from these platforms could limit liquidity, disrupt trading, and reduce Network accessibility. Reliance on Third-Party Services: Many blockchain services, including wallets, bridges, and oracles, depend on third-party providers. Failures, security breaches, or regulatory actions against these services could negatively affect the functionality of the Token. Centralisation Concerns: Although blockchain networks are designed to be decentralised, a small number of validators or node operators could introduce centralisation risks. This may lead to potential censorship, control over transactions, or increased vulnerability to governance attacks. Software and Protocol Risks: Bugs in Core Blockchain Code: Despite rigorous testing, undiscovered bugs in the core blockchain protocol could lead to network failures, incorrect transaction processing, or security vulnerabilities. A failure to address such issues promptly could result in loss of user confidence and network instability. Risk of Technological Disruption: Emerging technologies, such as quantum computing, could potentially compromise blockchain encryption, making networks vulnerable to attacks that could compromise data integrity or enable unauthorised asset transfers. Dependency on Underlying Technology: The stability of the Token ecosystem relies on underlying technical infrastructures, including internet connectivity, computing hardware, and cryptographic algorithms. Disruptions in these foundational technologies may impact network security and operational efficiency. Privacy and Anonymity Risks: Public Ledger Transparency: Blockchain transactions are recorded on a publicly accessible ledger, which may expose sensitive transaction data. While addresses do not directly reveal identities, sophisticated data analysis could potentially link certain transactions to specific individuals or entities. Exposure to Fraud and Targeted Attacks: Increased transparency may lead to risks such as phishing, fraud, or unauthorised tracking of user activity by malicious actors. Individuals with significant Token holdings may be targeted for scams or social engineering attacks. Economic and Network Viability Risks: Economic Self-Sufficiency: The long-term sustainability of the Token ecosystem depends on maintaining sufficient transaction volume to generate rewards for incentivising validators to ensure network security. If network adoption remains low, there is a risk of reduced validator participation, increased transaction costs, or a need for governance-driven changes to monetary policy, fee structures, or consensus mechanisms. Incentive Model Risks: Changes to block rewards, staking incentives, or governance models may be required to ensure ongoing network security and sustainability. Governance proposals may introduce modifications that impact Token holders, including inflation adjustments, transaction fees, or redistribution of rewards. Software Weakness Risks: Unforeseen Bugs and Security Vulnerabilities: The Token and its supporting infrastructure rely on blockchain technologies that may still be evolving. There is no guarantee that Token transactions will be uninterrupted or error-free. Software vulnerabilities, weaknesses in smart contracts, or infrastructure issues may result in loss of assets, security breaches, or unexpected network failures. Unanticipated Risks: Unforeseen Regulatory, Technological, or Economic Challenges: In addition to the risks identified, new threats may emerge due to changes in legal, technological, or economic conditions. Developments such as regulatory crackdowns, unforeseen Network vulnerabilities, or disruptive innovations could impact the usability, security, or value of the Token in ways not currently foreseeable. |
|||
| I.6 Mitigation measures | textBlock | ||||
| 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 following applies to Solana: Solana uses a combination of Proof of History (PoH) and Proof of Stake (PoS). The core concepts of the mechanism are intended to work as follows: Core Concepts 1. Proof of History (PoH): PoH is a cryptographic ordering and timing mechanism that provides evidence that data existed in a particular sequence and that time passed between proofs. Verifiable Delay Function (VDF): PoH relies on a sequential hash-based proof process that Solana describes as VDF-like. This sequence of hashes provides a verifiable order of events, enabling the network to efficiently agree on the sequence of transactions. 2. Proof of Stake (PoS): Validator Selection: Leader slots are assigned through the network's leader schedule, which is stake-weighted. The more SOL staked, the higher the chance of being selected to validate transactions and produce new blocks. Delegation: Token holders can delegate their SOL tokens to validators, earning rewards proportional to their stake while contributing to the network's security. Consensus Process 1. Transaction Validation: Transactions are broadcasted to the network and collected by validators. Each transaction is validated to ensure it meets the network's criteria, such as having correct signatures and sufficient funds. 2. PoH Sequence Generation: A validator generates a sequence of hashes using PoH, each containing a timestamp and the previous hash. This process creates a historical record of transactions, establishing a cryptographic clock for the network. 3. Block Production: The network uses PoS to select a leader validator based on their stake. The leader is responsible for bundling the validated transactions into a block. The leader validator uses the PoH sequence to order transactions within the block, ensuring that all transactions are processed in the correct order. 4. Consensus and Finalisation: Other validators vote on the ledger state associated with the block. A block may first become confirmed and later finalised once it reaches the network's strongest confirmation state. Security and Economic Incentives 1. Incentives for Validators: Block Rewards: Validators earn rewards for producing and validating blocks. These rewards are distributed in SOL tokens and are proportional to the validator's stake and performance. Transaction Fees: Validators also earn transaction fees from the transactions included in the blocks they produce. These fees provide an additional incentive for validators to process transactions efficiently. 2. Security: Staking: Staking provides economic alignment, and Solana documentation notes that slashing has been discussed as a future mechanism for intentional malicious behaviour, but is not implemented yet. Delegated Staking: Token holders can delegate their SOL tokens to validators, intended to enhance network security and decentralisation. Delegators share in the rewards and are incentivised to choose reliable validators. 3. Economic Penalties: Slashing (planned): Validators can be penalised for malicious behaviour, such as double-signing or producing invalid blocks. This penalty, known as slashing, results in the loss of a portion of the staked tokens, discouraging dishonest actions. The following applies to Base: Base is a Layer-2 (L2) solution on Ethereum that was introduced by Coinbase and developed using Optimism's OP Stack. L2 transactions do not have their own consensus mechanism and are only validated by the execution clients. The so-called sequencer regularly bundles stacks of L2 transactions and publishes them on the L1 network, i.e. Ethereum. Ethereum's consensus mechanism (Proof-of-stake) thus indirectly secures all L2 transactions as soon as they are written to L1. |
|||
| S.5 Incentive mechanisms and applicable fees | text | The following applies to Solana: 1. Validators: Validators participate in block production and voting under Solana's stake-weighted model. They may receive staking-related rewards and a share of transaction-fee income. Under Solana's fee model, the base fee is split between burn and validator compensation, while any prioritisation fee is paid to the validator. Transaction Fees: Validators earn a portion of the transaction fees paid by users for the transactions they include in the blocks. This is intended to provide an additional financial incentive for validators to process transactions efficiently and maintain the network's integrity. 2. Delegators: Delegated Staking: Token holders who do not wish to run a validator node can delegate their SOL tokens to a validator. In return, delegators share the rewards earned by the validators. This is intended to encourage widespread participation in securing the network and to support decentralisation. 3. Economic Security: Solana staking documentation notes slashing as a possible future mechanism for intentional malicious conduct, but states that slashing is not implemented in the protocol today. Economic alignment instead currently arises primarily from staking participation, validator performance incentives, and the opportunity cost of locking capital in staking positions. Fees Applicable on the Solana Blockchain 1. Transaction Fees: Solana transactions require fees in SOL. The fee model consists of a base fee and, where used, an optional prioritisation fee. The base fee compensates signature verification work and is split between burn and validator compensation, while any prioritisation fee is paid to the validator. 2. Rent Fees: Solana accounts that store onchain state must satisfy the rent-exemption threshold, which is linked to the amount of data stored. This mechanism is intended to support efficient use of network state and account storage resources. 3. Program Execution Costs: Deploying and interacting with onchain programs may involve transaction fees and, where relevant, compute-related prioritisation fees and account-storage requirements. These mechanisms are intended to allocate network resources in proportion to use. The following applies to Base: Base is a Layer-2 (L2) solution on Ethereum that uses optimistic rollups provided by the OP Stack on which it was developed. Transaction on base are bundled by a, so called, sequencer and the result is regularly submitted as an Layer-1 (L1) transactions. This way many L2 transactions get combined into a single L1 transaction. This lowers the average transaction cost per transaction, because many L2 transactions together fund the transaction cost for the single L1 transaction. This creates incentives to use base rather than the L1, i.e. Ethereum, itself. To get crypto-assets in and out of base, a special smart contract on Ethereum is used. Since there is no consensus mechanism on L2 an additional mechanism ensures that only existing funds can be withdrawn from L2. When a user wants to withdraw funds, that user needs to submit a withdrawal request on L1. If this request remains unchallenged for a period of time the funds can be withdrawn. During this time period any other user can submit a fault proof, which will start a dispute resolution process. This process is designed with economic incentives for correct behaviour. |
|||
| 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 | The Functionally Fungible Group Digital Token Identifier (FFG DTI) is used to determine all technically equivalent implementations of the crypto-asset in scope. Estimates regarding hardware types, node distribution, and the number of network participants are based on informed assumptions, supported by best-effort verification against available empirical data. Unless robust evidence suggests otherwise, participants are assumed to act in an economically rational manner. In line with the precautionary principle, conservative estimates are applied where uncertainty exists – that is, estimates tend towards the higher end of potential environmental impact. |
|||
| 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 | ||||