| [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 | Core Mechanics of Token and rights and obligations of the Token holder: • Creator Settlement Layer: Token serves as a component of the creator revenue payout through the Vibe protocol's programmatic settlement layer (VXD), combining stable liquidity with protocol-native tokens to ensure long-term Vibe ecosystem alignment for participating creators. • Community Stewardship: Token holders participate in the Vibe DAO (“DAO”), the decentralized autonomous organization that oversees the Token’s evolution, strategic direction, and the management of the DAO Treasury among the Token allocation, which will be enabled in the Foundation’s (as defined in Section A.11 below) website for suggestions, discussion, voting system by token lock-ups for the Token holders. Token holders participate in the DAO by exercising voting power over decisions for ecosystem expansions, and the integration of new creator platforms into the Vibe economic layer. Each Token holder has the voting rights as per previous sentence with 1 Token holding one vote. No other rights or obligations are attached to Token, however with the expansion of the ecosystem other rights may be conferred to Token. The conditions for exercising the voting rights attached to Token are that Tokens must be locked up. The voting rights specified above cannot be modified. Initial supply of Tokens was 1 000 000 000, distributed as follows: Category and Allocation • DAO 50% • Community Rewards – Marketing 10% • Community Rewards – Creator Rewards 5% • Community Rewards – Liquidity 5% • Foundation 10% • Dev Co 20% Tokens are freely transferable, in whole or in part, to third parties, and all associated usage rights and obligations follow the Token upon transfer. |
|||
| 09 Further information about utility tokens | textBlock | ||||
| 10 Key information about the offer to the public or admission to trading | textBlock | Token is expected to initially be listed in the EU on Kraken (i.e., on the EU cryptoasset trading platform operated by Payward Global Solutions Limited, with its registered office at Sir John Rogerson's Quay 70, D02 R296 Dublin, Ireland, Registration No C559106), and may also be listed on other crypto-asset trading platforms in the future. |
|||
| 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 | To ensure ongoing operational stability, the Core Contributor has committed to providing the Issuer with the necessary loan for its future operating expenses, including regulatory compliance and technical maintenance, through intercompany loan facilities. There were no material changes in the financial situation of Issuer since its establishment up to the date of this whitepaper. |
|||
| 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 | ||||
| D.5 Details of all natural or legal persons involved in implementation of crypto-asset project | |||||
| Person #1 | id | 1 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #2 | id | 2 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #3 | id | 3 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #4 | id | 4 | |||
| Type of person | enumeration | ||||
| Name of person | text | ||||
| Business address of person | text | ||||
| Domicile of company | enumeration | ||||
| Person #5 | id | 5 | |||
| 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 | ||||
| Description of future milestones | textBlock | ||||
| D.9 Resource allocation | text | Compliance & Legal: USD 80,000 Research and Development: USD 20,000 Security Audits: USD 20,000 Infrastructure Testing: USD 15,000 Branding & Identity Preparation: USD 12,000 Technical Architecture: USD 5,000 The Issuer has established a strategic allocation for the Vibe (V) token to foster ecosystem growth and long-term sustainability. Specifically, the 'Foundation' allocation will be utilized to execute the initiatives outlined in Section D.8. • DAO (50%): A governance-controlled reserve dedicated to ecosystem grants, creator incentives, platform growth, liquidity support, and long-term governance. • Community Rewards – Marketing (10%): Allocated for growth campaigns, strategic partnerships, promotional events, and global user acquisition. • Community Rewards – Creator Rewards (5%): Incentivizes creators, contributors, and early participants through structured reward programs. • Community Rewards – Liquidity (5%): Supports DEX/CEX liquidity to ensure healthy trading conditions and minimize volatility. • Foundation (10%): Funds operational for stability, regulatory compliance, ecosystem stewardship, and ongoing platform governance. • Dev Co (20%): Reserved for the core development team to drive product innovation, platform stability, and the continued expansion of the Vibe (V) ecosystem. |
|||
| D.10 Planned use of collected funds or other tokens | text | ||||
| Part E - Information about offer to public of other tokens or their admission to trading | |||||
| E.1 Public offering or admission to trading | enumeration | ||||
| E.2 Reasons for public offer or admission to trading | textBlock | ||||
| E.3 Fundraising target | |||||
| Target expressed in currency | monetary | EUR | |||
| Target expressed in units | decimal | ||||
| Target expressed in digital token identifier | text | ||||
| E.4 Minimum subscription goals | |||||
| Goals expressed in currency | monetary | EUR | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.5 Maximum subscription goals | |||||
| Goasl expressed in currency | monetary | EUR | |||
| Goals expressed in units | decimal | ||||
| Goals expressed in digital token identifier | text | ||||
| E.6 Oversubscription acceptance | boolean | ||||
| E.7 Oversubscription allocation | text | ||||
| Issue price details | |||||
| E.8 Issue price | decimal | ||||
| E.9 Official currency determining issue price | enumeration | ||||
| E.9 Any other tokens determining issue price | text | ||||
| E.10 Subscription fee | |||||
| Fee expressed in currency | monetary | EUR | |||
| Fee expressed in units | decimal | ||||
| Fee expressed in digital token identifier | text | ||||
| E.11 Offer price determination method | text | ||||
| E.12 Total number of offered or traded other tokens | integer | ||||
| E.13 Targeted holders | enumeration | ||||
| E.14 Holder restrictions | text | ||||
| E.15 Reimbursement notice | boolean true | ||||
| E.16 Refund mechanism | textBlock | ||||
| E.17 Refund timeline | text | ||||
| E.18 Offer phases | textBlock | ||||
| E.19 Early purchase discount | textBlock | ||||
| E.20 Time-limited offer | boolean | ||||
| E.21 Subscription period beginning | date | ||||
| E.22 Subscription period end | date | ||||
| E.23 Safeguarding arrangements for offered funds or other tokens | textBlock | ||||
| E.24 Payment methods for other token purchase | textBlock | ||||
| E.25 Value transfer methods for reimbursement | textBlock | ||||
| E.26 Right of withdrawal | textBlock | ||||
| E.27 Transfer of purchased other tokens | textBlock | ||||
| E.28 Transfer time schedule | text | ||||
| E.29 Purchaser's technical requirements | textBlock | ||||
| Other token services provider characteristics | |||||
| E.30 Other token service provider (CASP) name | text | ||||
| E.31 CASP identifier | LEI | ||||
| E.32 Placement form | enumeration | ||||
| Trading platforms characteristics | |||||
| E.33 Trading platforms name | text | ||||
| E.34 Trading platforms market identifier code (MIC) | text | ||||
| E.35 Trading platforms access | text | ||||
| E.36 Involved costs | textBlock | ||||
| E.37 Offer expenses | textBlock | ||||
| E.38 Conflicts of interest | textBlock | ||||
| E.39 Applicable law | textBlock | ||||
| E.40 Competent court | textBlock | ||||
| Part F - Information about other tokens | |||||
| F.1 Crypto-asset type | text | ||||
| F.2 Other token functionality | textBlock | • Protocol Collateralization: Vibe (V) serves as the fundamental backing for the ecosystem’s internal assets. It provides 50% collateralization for VXD (Creator Revenue Settlement Token). This ensures that creator rewards and platform credits are natively linked to the protocol’s primary asset. • Governance and Stewardship: Vibe (V) represents stewardship of the platform, granting holders a direct voice in key governance decisions and ecosystem grant allocations. Governance follows a token-based voting with a lockup mechanism to ensure long-term alignment between holders and ecosystem growth. • Settlement Infrastructure: Vibe (V) is the anchor of a settlement layer designed to return ~80% of revenue generated from the AI-generated content to the original creator. By replacing traditional platform fee structures with a programmatic on-chain model, Vibe (V) enables creators to retain a majority of their earnings. This is achieved through the VXD (Creator Revenue Settlement Token), a non-transferable asset specifically designed for secure and efficient creator revenue settlement. Ai creators in the Vibe ecosystem maintain a right to redeem the revenue settlement from the content they created through VXD, which is backed by 50% MiCA-compliant USD stablecoins to ensure immediate liquidity and 50% Vibe (V) tokens to provide creators with native protocol ownership and long-term ecosystem alignment. |
|||
| F.3 Planned application of functionalities | textBlock | • Platform Curation: Vibe (V) holders participate in governance votes to curate high-quality user-generated content. By voting, holders contribute to the ecosystem by increasing exposure for quality content. Voting rights can be delegated to trusted experts. This unified voting mechanism balances visibility with quality recommendations. • DAO Treasury Decisions: Vibe (V) holders can participate in ecosystem funding initiatives that contribute to the Vibe (V) ecosystem using the DAO treasury reserve, which represents 50% of total Vibe (V) supply. • Community Growth: Vibe (V) holders shape community expansion by proposing and voting on events, marketing initiatives, creator programs, and strategic partnerships that strengthen network effects and user acquisition. Approved initiatives may receive DAO resources and be executed by delegated working groups to ensure accountability and impact. • Core Rule Changes: Vibe (V) holders propose and ratify foundational changes to DAO governance and token economics—covering roles, voting parameters, and issuance/allocation policies—to sustain long‑term alignment. These proposals are subject to enhanced governance safeguards (e.g., heightened quorum or approval thresholds) to ensure broad consensus. • Access and future features: In the future, Vibe (V) might be used to unlock certain premium features or services. For example, staking of Vibe (V) to access AI resources at discounted rates or higher quotas of the AI platforms in the ecosystem. If any such feature is implemented, Vibe (V) holders would have preferential access or discounts. Disclaimer: The planned functionalities described above are indicative only and may not occur. By purchasing Vibe (V), you acquire the current functionality of the token as it exists at the time of purchase. The future of the Vibe protocol will be determined by the token holders through the Vibe protocol’s DAO governance process. |
|||
| A description of the characteristics of the other token, including the data necessary for classification of the crypto-asset white paper in the register referred to in Article 109 of Regulation (EU) 2023/1114, as specified in accordance with paragraph 8 of that Article | |||||
| F.4 Type of crypto-asset white paper | enumeration | ||||
| F.5 Type of submission | enumeration | ||||
| F.6 Other token characteristics | textBlock | ||||
| F.7 Commercial name or trading name | text | ||||
| F.8 Website of the issuer | text | ||||
| F.9 Starting date of offer to the public or admission to trading | date | ||||
| F.10 Publication date | date | ||||
| F.11 Any other services provided by the issuer | textBlock | ||||
| F.12 Language or languages of white paper | text | ||||
| F.13 Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available | text | ||||
| F.14 Functionally fungible group digital token identifier, where available | text | ||||
| F.15 Voluntary data flag | boolean | ||||
| F.16 Personal data flag | boolean | ||||
| F.17 LEI eligibility | boolean | ||||
| F.18 Home member state | enumeration | ||||
| F.19 Host member states #1 | enumerationSet | ||||
| F.19 Host member states #2 | enumerationSet | ||||
| F.19 Host member states #3 | enumerationSet | ||||
| F.19 Host member states #4 | enumerationSet | ||||
| F.19 Host member states #5 | enumerationSet | ||||
| F.19 Host member states #6 | enumerationSet | ||||
| F.19 Host member states #7 | enumerationSet | ||||
| F.19 Host member states #8 | enumerationSet | ||||
| F.19 Host member states #9 | enumerationSet | ||||
| F.19 Host member states #10 | enumerationSet | ||||
| F.19 Host member states #11 | enumerationSet | ||||
| F.19 Host member states #12 | enumerationSet | ||||
| F.19 Host member states #13 | enumerationSet | ||||
| F.19 Host member states #14 | enumerationSet | ||||
| F.19 Host member states #15 | enumerationSet | ||||
| F.19 Host member states #16 | enumerationSet | ||||
| F.19 Host member states #17 | enumerationSet | ||||
| F.19 Host member states #18 | enumerationSet | ||||
| F.19 Host member states #19 | enumerationSet | ||||
| F.19 Host member states #20 | enumerationSet | ||||
| F.19 Host member states #21 | enumerationSet | ||||
| F.19 Host member states #22 | enumerationSet | ||||
| F.19 Host member states #23 | enumerationSet | ||||
| F.19 Host member states #24 | enumerationSet | ||||
| F.19 Host member states #25 | enumerationSet | ||||
| F.19 Host member states #26 | enumerationSet | ||||
| F.19 Host member states #27 | enumerationSet | ||||
| F.19 Host member states #28 | enumerationSet | ||||
| F.19 Host member states #29 | enumerationSet | ||||
| Part G - Information on rights and obligations attached to other tokens | |||||
| G.1 Purchaser rights and obligations | textBlock | ||||
| G.2 Exercise of rights and obligations | textBlock | As a community-driven, decentralized system, the operational parameters of the protocol may evolve over time through the DAO governance process. Users who choose to interact with or build upon the Vibe (V) ecosystem do so under the understanding that all capabilities, limitations, and conditions are determined by the current version of the protocol’s code and the collective decisions of the DAO at any given point in time. |
|||
| G.3 Conditions for modifications of rights and obligations | textBlock | There is no central authority with the power to unilaterally alter the protocol’s core economic or governance logic; rather, the evolution of the Vibe ecosystem is subject to the collective decisions of its participants. While the Foundation acts as an entity to facilitate moderation and the execution of decisions, it does not hold the power to bypass the outcomes of governance votes. Users are responsible for actively monitoring governance proposals and adapting to protocol updates to remain aligned with the current version of the Vibe protocol. |
|||
| 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 | • External and Service-Level Restrictions: While the protocol itself does not restrict transfers, users may encounter limitations imposed by external parties or jurisdictional requirements, including: • Regulated Service Providers: Centralised trading platforms or Crypto-Asset Service Providers (CASPs) may apply their own terms of service, including KYC/AML verification, geographic geo-fencing, or withdrawal limits. • Jurisdictional Compliance: The transfer and possession of Vibe (V) tokens may be subject to local laws and regulations in the user’s jurisdiction. Users are responsible for ensuring their interactions with the token comply with applicable legal frameworks. |
|||
| 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 | By utilizing the OFT standard, Vibe (V) functions as a native asset on each supported chain, moving between them via a non-custodial burn-and-mint mechanism that eliminates the need for fragmented liquidity or insecure wrapped asset bridges. All transactions, including cross-chain transfers and governance interactions, are recorded transparently on the underlying blockchains and are verifiable by any participant. This technical architecture ensures that while the Vibe protocol provides its own specialized services, it inherits the decentralized security and finality of the host networks. |
|||
| H.2 Protocols and technical standards | text | • Fungibility Standards: - ERC-20: On Ethereum, Base, and Story, Vibe (V) is implemented as an ERC-20 token, the standard for fungible assets on Ethereum-based networks. - BEP-20: On BNB Smart Chain (BSC), Vibe (V) is implemented as a BEP-20 token. This standard is functionally equivalent to ERC-20 and ensures full compatibility with the BSC ecosystem's wallets, decentralized exchanges, and yield protocols. • Interoperability (LayerZero OFT V2): The protocol utilizes the LayerZero Omnichain Fungible Token (OFT) V2 standard to maintain a unified global supply. This allows Vibe (V) to exist as a native asset on all supported chains simultaneously. Cross-chain transfers are handled via a non-custodial burn-and-mint mechanism, ensuring that 1:1 parity is maintained across Ethereum, Base, BSC, and Story without the risks associated with traditional asset wrapping. • Security and Operational Standards: - Programming Language: All smart contracts are written in Solidity and utilize industry-standard libraries (such as OpenZeppelin) to ensure robust security and predictable behavior. - Transparency & Auditability: The source code for all $V token contracts and bridge adapters is verified on public block explorers (e.g., Etherscan, BscScan, Basescan, Storyscan). The protocol undergoes periodic independent security audits to identify and mitigate potential vulnerabilities. |
|||
| H.3 Technology used | textBlock | • Smart Contract Infrastructure: The protocol is developed in Solidity, utilizing the OpenZeppelin library suite for secure, industry-standard implementations of ERC-20, BEP-20, and access control modules (MultiSig and Timelocks). • Omnichain Interoperability: The protocol integrates LayerZero’s Omnichain Fungible Token (OFT) V2 standard. This allows Vibe (V) to exist as a native asset on Ethereum, Base, BSC, and Story simultaneously without the need for traditional asset wrapping or middle-chain bridges. • Oracles and Data Verification: To ensure the accuracy of external data (such as stablecoin and Vibe (V) token prices for the VXD backing), the protocol utilizes decentralized oracle networks to fetch and verify off-chain information before triggering on-chain settlement. • Development and Testing Frameworks: The codebase is managed using Foundry and Hardhat to ensure rigorous unit testing, property-based testing, and comprehensive simulation of settlement scenarios before deployment. |
|||
| H.4 Consensus mechanism | text | These networks primarily utilize staking-based consensus models: Ethereum, Base, and Story utilize Proof of Stake (PoS), while BNB Smart Chain utilizes Proof of Staked Authority (PoSA). These mechanisms ensure network integrity through a decentralized set of validators who stake native assets to secure the chain, providing the Vibe protocol with robust, energy-efficient, and battle-tested security for all Vibe (V) and related transactions. |
|||
| H.5 Incentive mechanisms and applicable fees | text | • Inherited Network Fees: The protocol does not charge a native fee for token transfers. - All interactions with the Vibe (V) smart contracts require the payment of network transaction (gas) fees in the native asset of the host chain (e.g., ETH for Ethereum/Base, BNB for BSC). - The execution of these fees is managed entirely by the host chains' inherited consensus mechanisms. • Protocol-Specific Incentives: - V/VXD Settlement Logic: The ecosystem utilizes a dual-token model where Vibe (V) acts as the native token and VXD serves as a non-transferrable and redeem-only revenue settlement token issued based on the value of V. - Permissionless Minting: The issuance of VXD is designed to be a permissionless process, incentivizing participants to interact with the Gateway contracts to facilitate revenue sharing for creators. - Governance Stewardship: The protocol incentivizes long-term alignment through DAO governance, where Vibe (V) holders oversee the allocation of the DAO Treasury and protocol parameters. • Market-Based Adjustments: - The protocol's incentive mechanism accounts for potential price fluctuations between token issuance and redemption. - To maintain stability, the Gateway contract incorporates logic to mitigate financial discrepancies during these periods. |
|||
| 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 | The audit identified technical vulnerabilities across several severity levels, all of which were subsequently remediated and verified by the audit team to ensure the protocol's security and functional integrity. The full security assessment report, detailing the scope and remediation of all findings, is publicly available for review: View Final Audit Report - https://vibe.infiniteuniverse.xyz/securityaudit.pdf |
|||
| Part I - Information on risks | |||||
| I.1 Offer-related risks | textBlock | The admission to trading of crypto-assets, including M, is subject to general risks inherent to the broader cryptocurrency market. Market Volatility The value of Vibe (V) may experience substantial fluctuations driven by investor sentiment, macroeconomic developments, and market conditions. Regulatory Risks Changes in legislation, applicable laws, compliance requirements or the implementation of new regulatory frameworks could affect the availability, trading, or use of such assets. Security Risks The risk of exploitation, hacking or security vulnerabilities of the underlying protocol and/or contracts of the token leading to a loss. Reputational Risks The potential for damage to an organization’s credibility or public trust, which can negatively impact stakeholder confidence and overall business viability. |
|||
| I.2 Issuer-related risks | textBlock | The Company’s ability to continue supporting the network is crucial and if it dissolves or withdraws, the project might stagnate. Execution Risks Deliverables like cross-chain features or governance portals could be delayed or not delivered, affecting credibility. Financial Stability Risks We may require additional capital to meet our financial obligations and support business growth, and this capital might not be available on acceptable terms or at all. Regulatory & Legal Compliance Risks Issuers of crypto assets must adhere to a wide array of regulatory requirements across different jurisdictions. If the blockchain and the protocol are unable to satisfy data protection, security, privacy, and other government- and industry-specific requirements, its growth could be harmed. Non-compliance can result in fines, sanctions, or the prohibition of the crypto asset offering, impacting its viability and market acceptance. Litigation Risks Legal uncertainties, potential lawsuits, or adverse legal rulings can pose significant risks to issuers. Legal challenges may affect the legality, usability, or value of the Vibe (V) token. Copyright/Patent Infringement Risks Assertions by third parties of infringement or other violation by us of their intellectual property rights could harm our business, operating results, and financial condition. |
|||
| I.3 Other tokens-related risks | textBlock | The crypto-asset market is subject to significant price volatility, which may affect the value of Vibe (V). Prices can fluctuate rapidly and unpredictably due to various factors, including market sentiment, economic indicators, technological developments, regulatory news, and macroeconomic trends. This high level of volatility may lead to sudden gains or losses and can impact the liquidity and tradability of the crypto-asset. Liquidity Liquidity refers to the ability to buy or sell a crypto-asset without causing significant price impact. Vibe (V) may experience periods of low liquidity, meaning that it could be difficult to enter or exit positions at desired prices or volumes. Reduced liquidity may result from limited market participation, exchange restrictions, or broader market conditions. This can lead to increased price volatility, slippage, and difficulty in executing transactions. Cybersecurity & Technology Risks Risks arising from vulnerabilities in the blockchain technology used by the project or platforms. Example risks include smart contract exploits, compromise of platforms, forking scenarios, compromise of cryptographic algorithms. Adoption Risks The risk associated with the project not achieving its goals leading to lower than expected adoption and use within the ecosystem, the impact leading to a reduced utility and value proposition. Custody & Ownership Risk The risk related to the inadequate safekeeping and control of crypto-assets e.g. loss of private keys, custodian insolvency leading to a loss. |
|||
| I.4 Project implementation-related risks | textBlock | The Company has plans to expand the Vibe (V) token’s functionality and reach. There is a risk that some of these planned developments may be delayed, scaled back, or not achieved at all. Limited Operating History The Company has a limited operating history, which makes it difficult to predict future operations. There is no assurance that the Company’s proposed activities and business plans will succeed. The Company has also encountered, and will continue to encounter, risks and uncertainties frequently experienced by growing companies in rapidly changing industries. |
|||
| I.5 Technology-related risks | textBlock | Vibe (V) uses smart contracts to facilitate automated transactions and processes. While these contracts enhance efficiency and decentralization, they also introduce specific technical risks. Vulnerabilities such as coding errors, design flaws, or security loopholes within the smart contract code may be exploited by malicious actors. Such exploits could result in the loss of assets, unauthorized access to sensitive information, or unintended and irreversible execution of transactions. Blockchain Network Risks Vibe (V) operates on a public blockchain infrastructure, which is maintained by a decentralized network of participants. The functionality and reliability of the crypto-asset are dependent on the performance and security of the underlying blockchain. Risks may include network congestion, high transaction fees, delayed processing times, or, in extreme cases, outages and disruptions. Additionally, vulnerabilities or failures in the consensus mechanism, attacks on the network (e.g., 51% attacks), or protocol-level bugs could impact the operation and availability of Vibe (V). Risk of Cryptographic Vulnerabilities Technological advancements, such as quantum computing, could pose potential risks to cryptocurrencies. Privacy Transactions involving Vibe (V) are recorded on a public blockchain, where transaction data is transparent and permanently accessible. While public addresses do not directly reveal personal identities, transaction histories can be analyzed and, in some cases, linked to individuals through data aggregation or external information sources. This transparency may pose privacy concerns for users seeking confidentiality in their financial activity. Participants should be aware that transaction data on public blockchains is not inherently private and could be subject to scrutiny by third parties, including regulators, analytics firms, or malicious actors. |
|||
| I.6 Mitigation measures | textBlock | Vibe (V) is implemented using a well-tested token standard (ERC-20 on EVM networks) which has been widely used and vetted. By adhering to a standard protocol and not using unproven custom code where unnecessary, the project reduces the likelihood of unknown bugs. Security Audits The Vibe (V) smart contract and related platform contracts have undergone security auditing by an experienced third-party auditing firm. This audit process helps identify and address potential vulnerabilities, thereby reducing the risk of smart contract failures or exploits. Multisig Controls All smart contracts and treasury wallets are controlled by multisig wallets, limiting insider or single-key risk. |
|||
| 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 | ||||
| S.5 Incentive mechanisms and applicable fees | text | ||||
| 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 energy consumption in Section S.8 of this whitepaper is calculated in accordance with the calculation guidance in point AR 32 of Appendix A to the ESRS E1 in Annex I to Delegated Regulation (EU) 2023/2772 of 31 July 2023 supplementing Directive 2013/34/EU of the European Parliament and of the Council as regards sustainability reporting standards. Calculation Framework and Formula The methodology calculates the energy consumption for each supported blockchain network by taking the total annual electricity demand of that specific host network and multiplying it by the Token’s activity ratio. This ratio is defined as the number of Vibe-related transactions divided by the total annual transaction volume recorded on the respective network. To arrive at the final figure reported in Section S.8, the sum of these individual network allocations is increased by a fifteen percent Infrastructure Buffer. This additional factor is applied to account for the electricity consumed by ancillary protocol infrastructure, including indexing services, RPC endpoints, and the operations of the VXD Gateway. These elements are essential for the maintenance of the redemption ledger but operate outside the primary energy draw of network validator nodes. Conservative Activity Projections As the Vibe token is in a pre-launch phase, these estimates utilize a Conservative High-Activity Stress Test scenario to ensure full transparency and avoid underestimation. This model assumes a total of 60,000,000 annual V-related transactions, which includes 10,000,000 transactions for VXD redemptions (representing 100 transactions per creator for 100,000 users) and 50,000,000 transactions for on-chain trading and governance (representing 50 transactions per holder for 1,000,000 users). For the purpose of this calculation, these transactions are assumed to be distributed equally across the four integrated networks: Ethereum, BNB Smart Chain, Base, and Story, resulting in 15,000,000 transactions per chain. Data Sources and Network Benchmarks The methodology relies on peer-reviewed data and indices accessed on February 27, 2026. Baseline energy data for the Ethereum (PoS) network is sourced from the Crypto Carbon Ratings Institute (CCRI) Index (v.2025.1), which reports an annual network consumption of approximately 2,600 MWh against a benchmark of 754.8 million total annual transactions. For the BNB Smart Chain (PoSA), metrics are derived from the EU Blockchain Observatory and Forum (EUBOF) 2024 Report, utilizing an energy intensity of 0.0001 kWh per transaction. The Base and Story (L2/Modular) networks are benchmarked against high-efficiency Layer-2 metrics provided by CCRI, also utilizing a standard intensity of 0.0001 kWh per transaction. Final Indicative Result and Compliance Based on these high-activity projections, the primary energy allocation for the Ethereum network is calculated at 51,669.32 kWh, while the BNB Smart Chain, Base, and Story networks contribute 1,500 kWh each. After applying the 15% infrastructure buffer (8,425.39 kWh), the total annual energy consumption is estimated at 64,594.71 kWh. This calculation is fully aligned with the guidance in point AR 32 of Appendix A to the ESRS E1 in Annex I to Delegated Regulation (EU) 2023/2772, with no identified deviations. Furthermore, in accordance with Article 6(8) of the MiCA Regulation, it is disclosed that these figures represent gross electricity consumption and do not include any reductions from carbon offsets or Renewable Energy Credits (RECs). Detailed external data provider information and methodologies for addressing underreported metrics via the 15% buffer are included to ensure a replicable and verifiable sustainability report. |
|||
| 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 | ||||