| [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 | HPL does not represent any ownership rights, equity interest, or claim against any legal entity, nor does it grant any right to receive profits, dividends, or other financial returns. The token is not linked to any underlying asset, basket of assets, or fiat currency, and its value is determined solely by market dynamics. HPL may be used within the HyperLend protocol for specific functionalities, including but not limited to participation in governance mechanisms, alignment of incentives among users, and access to certain protocol features such as staking-based programs. In particular, holders may choose to stake HPL to receive a corresponding staking representation, which can be used within the protocol to obtain benefits such as fee rebates. Staking does not grant ownership or control over the protocol or its underlying smart contracts. The rights associated with HPL are limited to its functional use within the protocol as described above. Holding HPL does not create any contractual relationship between the holder and any issuer or developer of the protocol. No guarantees are provided regarding the future utility, adoption, or value of the token. The characteristics, functionalities, and associated conditions of HPL may evolve over time as a result of updates to the HyperLend protocol, including changes implemented through governance processes or smart contract upgrades, where applicable. Such changes may affect the functionality of the token but will not result in the creation of rights to profits, assets, or claims against any entity. |
|||
| 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 | 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 | Subdivision (ISO 3166-2): PA-8 Province of Panama, District of Panama, Betania, Vía Ricardo J. Alfaro, PH The Century Tower, Office 317 |
|||
| Function | text | ||||
| Member #2 | id | 2 | |||
| Identity | text | ||||
| Business address | text | Subdivision (ISO 3166-2): PA-8 Province of Panama, District of Panama, Betania, Vía Ricardo J. Alfaro, PH The Century Tower, Office 317 |
|||
| Function | text | ||||
| Member #3 | id | 3 | |||
| Identity | text | ||||
| Business address | text | Subdivision (ISO 3166-2): PA-8 Province of Panama, District of Panama, Betania, Vía Ricardo J. Alfaro, PH The Century Tower, Office 317 |
|||
| Function | text | ||||
| A.13 Business activity | textBlock | ||||
| A.14 Parent company business activity | textBlock | The Hyperlend Foundation does not engage in commercial activities for profit. Its primary purpose is to support the long-term sustainability, research, and development of the Hyperlend protocol and its associated open-source technologies. In this context, the Foundation's activities are comparable to those commonly undertaken by non-profit organizations in the blockchain sector. The activities of the Hyperlend Foundation include, inter alia: (i) supporting the research, development, and maintenance of open-source software related to the HyperLend protocol; (ii) fostering ecosystem growth by supporting developers, contributors, and community participants through grants, funding programs, and other initiatives; (iii) promoting decentralization and the adoption of the Hyperlend protocol; (iv) facilitating community coordination and supporting governance processes within the ecosystem; and (v) engaging in educational and outreach activities aimed at increasing awareness and understanding of the HyperLend protocol. |
|||
| A.15 Newly established | boolean | ||||
| A.16 Financial condition for the past three years | textBlock | ||||
| A.17 Financial condition since registration | textBlock | ||||
| 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 | The system operates without centralized intermediaries, with all core functionalities executed automatically through smart contracts. Interest rates are determined algorithmically based on supply and demand within each liquidity pool, and risk management mechanisms, such as collateral requirements and liquidation procedures, are embedded in the protocol. The HPL token is a fungible crypto-asset associated with the HyperLend ecosystem and is intended to support the functioning and development of the protocol. HPL does not confer any ownership rights, claims, or entitlements to profits or revenues. Its primary purpose is to enable participation in governance-related processes, align incentives among users, and provide access to certain protocol features, including staking-based mechanisms. Users may voluntarily stake HPL to obtain a corresponding representation within the protocol, which may be used to access specific functionalities such as rebate programs, subject to the conditions defined in the relevant smart contracts. The project is part of the broader decentralized finance ecosystem and is designed to be interoperable with other blockchain-based applications and infrastructure. The protocol relies on external data providers (oracles) for price feeds and incorporates standard security practices, including smart contract audits. HyperLend does not involve the custody of user assets by a central entity, and users interact directly with the protocol through their own digital wallets. The project is intended to provide an open and permissionless financial infrastructure for digital asset lending and borrowing. |
|||
| 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 | In its initial phase, the protocol was designed and developed as a decentralized, non-custodial lending and borrowing infrastructure, including the deployment of core smart contracts, integration with blockchain networks, and implementation of key functionalities such as liquidity pools, collateralized borrowing, algorithmic interest rate models, and liquidation mechanisms. During this phase, the project also established integrations with external oracle providers for price data and conducted security audits of its smart contracts. Subsequently, the HPL token was introduced as a functional component of the ecosystem, enabling participation in governance-related processes, staking mechanisms, and user incentive programs. The project has also implemented ecosystem initiatives, such as points-based programs and staking features, aimed at encouraging user participation and supporting protocol adoption. |
|||
| Description of future milestones | textBlock | Additional plans may also include the development of new features within the ecosystem, integrations with other decentralized applications or infrastructure, and ongoing security reviews and audits of smart contracts. All future developments are subject to technical, regulatory, and market conditions, and no assurance can be given that any specific milestone will be achieved within a particular timeframe or at all. |
|||
| D.9 Resource allocation | text | ||||
| 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 | The value of the crypto-asset is entirely determined by market forces – specifically, the dynamics of supply and demand – and is not supported by any stabilization mechanism. It is neither pegged to a fiat currency nor backed by external assets, which differentiates it from EMTs and ARTs. Moreover, the crypto-asset does not qualify as a financial instrument, deposit, insurance policy, pension product, or any other regulated financial product under EU law. It does not confer any financial entitlements contractual claims on its holders, thereby placing it outside the regulatory scope governing traditional financial instruments. |
|||
| F.2 Other token functionality | textBlock | HPL enables participation in governance-related processes concerning the evolution of the HyperLend protocol, where applicable. It is also used as part of incentive-alignment mechanisms within the ecosystem, including staking-based functionalities. Users may voluntarily stake HPL to receive a corresponding representation, which can be used within the protocol to access specific features, such as rebate programs, in accordance with the conditions defined in the relevant smart contracts. The token may also serve as a mechanism to support ecosystem engagement and coordination among users of the protocol. HPL does not grant any rights to profits, revenues, or assets, and does not represent a claim against any issuer or third party. |
|||
| F.3 Planned application of functionalities | textBlock | Any future evolution, modification, or extension of the functionalities of HPL may occur as part of the ongoing development of the HyperLend protocol, including through governance processes or technical updates. Such developments are not guaranteed and remain subject to technical, regulatory, and market conditions. |
|||
| 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 | The token does not represent any ownership rights, equity interest, or claim against any legal entity, nor does it provide any entitlement to profits, revenues, or other financial returns. HPL is not backed by any underlying assets, fiat currency, or basket of assets, and its value is determined solely by market supply and demand. HPL is designed to be used within the HyperLend protocol to support its functionality, including participation in governance-related processes, incentive alignment mechanisms, and access to certain protocol features such as staking-based functionalities. Users may voluntarily stake HPL to receive a corresponding representation within the protocol, which may enable access to specific ecosystem features, subject to the conditions defined in the relevant smart contracts. The token operates in a decentralized environment, with its functionalities executed through smart contracts without reliance on centralized intermediaries. Transactions involving HPL are recorded on the relevant blockchain networks and are subject to the technical characteristics and limitations of those networks. HPL does not impose any obligations on holders and does not establish any contractual relationship between the holder and any issuer or third party. The characteristics and functionalities of the token may evolve over time as a result of updates to the HyperLend protocol, including through governance processes or technical modifications. |
|||
| 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 | ||||
| Part G - Information on rights and obligations attached to other tokens | |||||
| G.1 Purchaser rights and obligations | textBlock | Any functionalities associated with the $HPL token are limited to its role within the HyperLend protocol and are of a purely technical nature, such as participation in decentralized governance mechanisms or interaction with protocol-level functionalities, where implemented. Such functionalities do not constitute legal rights enforceable against any identifiable issuer or entity. The holding or use of $HPL tokens does not impose any obligation on the purchaser, including any obligation to make additional payments, provide capital contributions, or undertake any form of performance or service. Purchasers are not subject to any contractual or legal obligations solely by virtue of holding or using the token. Ownership and transfer of $HPL tokens are governed by the applicable rules of private law, including the relevant provisions of international private law, which may vary depending on the jurisdiction and the specific circumstances of each case. |
|||
| G.2 Exercise of rights and obligations | textBlock | To the extent that the token enables participation in certain functionalities within the HyperLend ecosystem (such as decentralized governance mechanisms or interaction with smart contracts), such functionalities are exercised exclusively through technical means and are subject to the rules encoded in the relevant smart contracts and protocol architecture. Any such interactions are not enforceable as legal rights against any legal entity and are dependent on the proper functioning of the underlying technology and network. |
|||
| G.3 Conditions for modifications of rights and obligations | textBlock | However, the functionalities associated with the $HPL token in connection with the HyperLend protocol may evolve over time as a result of technical developments, protocol upgrades, or governance decisions implemented at the protocol level. Such changes may affect how the token can be used within the ecosystem but do not constitute modifications of legal rights or obligations. Any such changes are determined by the technical and governance processes of the HyperLend protocol and are not subject to contractual guarantees or enforceable claims by token holders. |
|||
| 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 | HyperCore is designed as a high-performance blockchain supporting fully on-chain financial applications. It maintains a distributed ledger where all transactions, including transfers of HPL and interactions with related protocols, are recorded in a transparent and immutable manner. The network integrates trading and financial primitives directly at the protocol level, enabling deterministic execution and one-block finality for transactions. The distributed ledger is maintained by a network of validators that collectively ensure the integrity, consistency, and availability of the system without reliance on a central authority. |
|||
| H.2 Protocols and technical standards | text | The protocol relies on established design patterns commonly used in decentralized finance applications, including tokenized representations of user positions (such as deposit and debt tokens), overcollateralized lending mechanisms, and algorithmic interest rate models. Smart contracts are designed to be interoperable with standard blockchain tooling and infrastructure, enabling integration with wallets, decentralized applications, and other ecosystem components. HyperLend also integrates with external oracle providers to obtain market data, which is used for collateral valuation, interest rate calculations, and liquidation processes. |
|||
| H.3 Technology used | textBlock | The architecture is based on a pool-based model, where users supply digital assets to shared liquidity pools and borrowers access liquidity by providing collateral. Positions are represented programmatically through tokenized balances, and all interactions are executed directly on-chain. The protocol is designed to be permissionless, meaning that users can interact with it directly through compatible digital wallets without the need for account registration or reliance on intermediaries. Security practices include the use of audited smart contracts and ongoing monitoring of protocol performance and risks. |
|||
| H.4 Consensus mechanism | text | This consensus mechanism enables validators to agree on the state of the blockchain efficiently and securely, providing fast transaction finality and resistance to malicious actors. Transactions are finalized once included in a block, with no need for multiple confirmations, ensuring deterministic and irreversible execution. HyperBFT is designed to support high throughput and low latency, allowing the network to process a large number of transactions and financial operations in real time. |
|||
| H.5 Incentive mechanisms and applicable fees | text | Transactions submitted to the network may be subject to fees, which can vary depending on network conditions and usage. These fees are generally borne by users initiating transactions and may contribute to the incentives provided to network participants. |
|||
| 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 | Market Risk. HPL can be subject to significant price fluctuations based on supply-demand dynamics, market sentiment, and external macroeconomic factors. These may result in financial losses for token holders. Liquidity Risk. While admission to trading increases accessibility, liquidity is not guaranteed. Low trading volumes may result in high slippage or the inability to exit positions efficiently. Counterparty Risk. The exchanges or trading platforms where HPL tokens are listed may become insolvent or cease operations, potentially resulting in a loss of access to funds or HPL. Integration with third-party trading platforms involves dependencies on their internal policies and stability. Delisting, insolvency, or technical failures at such platforms could adversely impact tradability. Issuer Non-involvement in Trading. When HPL is traded on exchanges, the issuer 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 issuer for their operations and services. |
|||
| I.2 Issuer-related risks | textBlock | Operational Dependency Risk. The issuer relies on various infrastructure providers – including cloud services, validators, and custodial partners – to support its operations. Any interruption, failure, or termination of these relationships could adversely affect the functioning of the protocol or associated services. Reputational Risk. Negative publicity stemming from operational incidents, security breaches, or perceived associations with illicit activities could harm the issuer's public image, potentially reducing confidence in and demand for HPL tokens. Internal Operations Risk. Weaknesses in the issuer's internal processes, human resources, or technology systems could impair the effective management of token operations. Failures in operational integrity may result in service disruptions, financial losses, or reputational harm. Legal and Regulatory Risk. Evolving legal frameworks, regulatory changes, or adverse legal proceedings may create uncertainty around the legality, usability, or valuation of HPL tokens, potentially restricting their circulation or acceptance. Competitive Market Risk. The HyperLend protocol operates in a highly dynamic and competitive market. Emerging innovative or better-capitalized competitors may offer alternative solutions that diminish user adoption or the market position of the HPL network. |
|||
| I.3 Other tokens-related risks | textBlock | Volatility Risk. As with most crypto-assets, HPL is subject to substantial short- and long-term price fluctuations. Market sentiment, liquidity shifts, and macroeconomic trends can all cause significant volatility, potentially resulting in financial losses for holders. Liquidity Risk. Market depth and trading activity for HPL may vary over time. Limited order book participation could lead to price slippage or difficulty executing trades efficiently, particularly during periods of market stress. Technological Obsolescence Risk. The blockchain and crypto-asset sectors evolve rapidly. Innovations or competing protocols could surpass or replace the HyperLend protocol's functionality, reducing HPL's utility, adoption, or relevance. Speculative Nature Risk. The value of HPL is highly speculative and depends on market demand, protocol adoption, validator participation, and community engagement. There are no guarantees of future value, performance, or rewards associated with the token. Blockchain Dependency Risk. HPL operates on public blockchains such as HyperCore. Changes to their infrastructure, governance, consensus mechanisms, or transaction fees could affect HPL's usability, transferability, and cost efficiency. Security Risks. a) Smart Contract Vulnerabilities: Despite comprehensive audits, unforeseen bugs or vulnerabilities could compromise smart contract functionality, impacting token security, staking, or governance. b) Private Key Management: Token holders are solely responsible for safeguarding their wallets and private keys. Loss or compromise of credentials will irreversibly result in the loss of tokens. Fraud and Scam Risks. Holders face exposure to scams, phishing, impersonation, counterfeit tokens, and fake airdrops. Interacting with unverified platforms or unofficial channels significantly increases the risk of fraud or asset loss. Cybercrime and Theft Risks. Blockchain assets may be targeted by cyberattacks, including hacking, malware, or phishing. Breaches affecting wallets, exchanges, or smart contracts could lead to theft, loss of assets, or service disruption. Data Integrity Risk. Software bugs, human error, or malicious tampering could corrupt blockchain data, impacting transaction records, network reliability, and user confidence. Wallet and Storage Risk. Access to HPL requires compatible wallets. Incompatibility, network errors, or the shutdown of wallet providers may restrict users' ability to access, store, or transfer tokens. Regulatory and Compliance Risks. a) Evolving Legal Frameworks: Regulatory regimes governing digital assets are changing rapidly, potentially impacting HPL's classification, availability, or functionality. b) Jurisdictional Restrictions: Certain jurisdictions may limit or prohibit HPL trading or use, restricting accessibility for some users. c) Enforcement Actions: Regulators could take action if HPL were reclassified as an unregistered security or other regulated financial instrument. d) AML & CTF Risks: Transactions involving crypto-assets may be scrutinized for compliance with anti–money laundering and counter–terrorism financing laws, potentially affecting users' ability to trade or transfer HPL. |
|||
| I.4 Project implementation-related risks | textBlock | Resource Constraint Risk. The successful development of the HPL ecosystem depends on the availability of adequate financial and human resources. Budget limitations, difficulties in attracting or retaining qualified technical personnel, or reliance on external or volunteer contributors could impede progress and delay protocol improvements. Interoperability and Technical Failure Risk. The HPL token operates in connection to other blockchain networks, such as Hyper-EVM. Interoperability challenges, software bugs, or technical failures affecting one or more of these networks could disrupt transaction execution, cross-chain functionality, or other core operations, potentially undermining user confidence and protocol reliability. Competitive Risk. Hyperlend Inc. operates in a rapidly evolving market. The emergence of more advanced, better-capitalized, or innovative competitors could reduce network adoption and negatively impact HPL's market position and value. |
|||
| I.5 Technology-related risks | textBlock | Smart Contract Vulnerability Risk. Although the HPL smart contracts have undergone extensive security audits, there remains a possibility of undetected bugs or exploitation through novel attack vectors. Such vulnerabilities could compromise token integrity, staking mechanisms, or governance processes. Fault-Tolerance and Incentive Mechanism Risk. HPL's operational model relies partly on user participation and incentive structures. Misconfigurations, design flaws, or unexpected failures in these mechanisms could lead to inconsistent performance or temporary instability in protocol operations. Private Key Management Risk. Token holders are solely responsible for the secure management of their private keys and recovery credentials. Loss, theft, or compromise of wallet access will irreversibly result in the loss of HPL tokens, as blockchain transactions cannot be reversed. External Infrastructure Dependency Risk. The protocol depends on third-party infrastructure providers, including RPC services, decentralized storage solutions, and agent orchestration frameworks. Downtime, cyberattacks, or incompatibility issues within these components could impact data availability, performance, or verification processes across the network. Technological and Coordination Failure Risk. Participants should be aware that technological malfunctions, software errors, or coordination breakdowns among validators, developers, or governance participants could impair the availability, security, or functionality of both the HPL token and the HyperLend protocol. Maintenance and Upgrade Risk. Ongoing network maintenance, software updates, or protocol upgrades introduce a residual risk of unexpected bugs or compatibility issues. |
|||
| I.6 Mitigation measures | textBlock | a) Transparent Governance: All major protocol and token-related decisions are made through community governance, supported by public documentation and auditable voting records. b) Foundation Stewardship: The Hyperlend Foundation provides strategic guidance and ensures the project's adherence to sustainability and compliance standards. Technical Security. a) Independent Smart Contract Audits: All smart contracts are subjected to multiple third-party security audits prior to deployment and after major upgrades. Operational Resilience. a) Infrastructure Diversification: Multiple RPC providers, storage networks, and validator partners are employed to reduce reliance on any single provider. b) Incident Response Procedures: A structured monitoring and response framework enables rapid detection, containment, and resolution of potential security or operational incidents. c) Periodic Stress Testing: Protocol systems undergo regular performance and load testing to evaluate resilience under adverse conditions. Regulatory and Compliance Measures. a) Regulatory Monitoring: The issuer and foundation actively monitor evolving EU and international regulations, including MiCAR developments, to ensure continuous compliance. b) Legal Reviews: Ongoing external legal assessments help ensure that token operations remain consistent with applicable laws and regulatory classifications. Market and Financial Controls. a) Treasury Management Policies: Treasury operations follow internal governance controls to ensure transparent use of funds and responsible liquidity management. b) Diversification of Assets: The treasury maintains a balanced composition of HPL and stablecoins to maintain liquidity. Community and Transparency. a) Clear Documentation: documentation and informative materials are publicly accessible, enabling independent review. b) Continuous Communication: Regular updates through governance forums, community calls, and transparency reports ensure ongoing stakeholder engagement. |
|||
| 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 | This consensus mechanism enables validators to agree on the state of the blockchain efficiently and securely, providing fast transaction finality and resistance to malicious actors. Transactions are finalized once included in a block, with no need for multiple confirmations, ensuring deterministic and irreversible execution. HyperBFT is designed to support high throughput and low latency, allowing the network to process a large number of transactions and financial operations in real time. |
|||
| S.5 Incentive mechanisms and applicable fees | text | Transactions submitted to the network may be subject to fees, which can vary depending on network conditions and usage. These fees are generally borne by users initiating transactions and may contribute to the incentives provided to network participants. |
|||
| 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 identification of hardware used within the network is primarily determined by the technical requirements necessary to operate the relevant client software. Energy consumption levels of such hardware are based on measurements obtained from certified laboratory testing environments. Where available, the Functionally Fungible Group Digital Token Identifier (FFG DTI) is used to identify and include all relevant implementations of the crypto-asset within scope. These mappings are updated on a regular basis using data provided by the Digital Token Identifier Foundation. Information regarding the type of hardware deployed and the number of network participants is based on assumptions that are validated, to the extent possible, using empirical data. It is generally assumed that network participants act in an economically rational manner. In cases of uncertainty, a conservative approach is adopted, meaning that assumptions are made in a way that is more likely to overestimate rather than underestimate potential 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 | ||||