The $SWAN public offer is structured as a “fair-launch Initial Coin Offering (ICO)” with no pre-sale and equal access for all participants. The offer targets both retail and institutional investors, with the following key details:

Purpose/Strategy/Vision

The company aims to pioneer innovation in blockchain technology by providing cutting-edge applications and services related to crypto-assets, smart contracts, and distributed ledger technologies. This includes, inter alia, integrating blockchain solutions into everyday activities, enabling transparency, efficiency, and security in financial and non-financial ecosystems.

Products/Services

The company’s primary focus lies in the development and issuance of MiCA-compliant crypto-assets, including the $SWAN token, which is designed for compliant, transparent, and secure holding and transaction. Additionally, the company envisions developing blockchain-based software solutions and smart contract frameworks that cater to both business-to-business and business-to-consumer markets. Ancillary services may include blockchain consulting and solutions that enhance compliance and operational efficiency for entities using blockchain technologies.

Markets Served

The company’s target markets include the European Economic Area (EEA), with a special focus on Finland as the hub of operations. Activities cater to retail and institutional investors interested in crypto-assets, as well as businesses seeking innovative blockchain solutions that align with the EU’s regulatory practices and industry-standard technological implementations.

As the company was recently established in 2024, there is no historical financial data available for the past three years. However, the financial condition of the company is stable, supported by contributions from its founders and stakeholders. These resources are sufficient to meet the operational needs of the business at its current stage.

The launch of this MiCA-compliant token does not require significant financial investments. The development and issuance processes rely primarily on non-financial resources, particularly the expertise, working hours, and technical skills of the issuer and its team. These resources are readily available within the organization, ensuring that the token launch proceeds efficiently without placing substantial demands on the company’s financial resources.

Key Performance Indicators (KPIs)

Since the company is in its early stages of operation, financial KPIs are not yet applicable. Instead, the relevant KPIs for this phase include:

–       Progress on Token Development: The $SWAN token was designed from the ground-up for a MiCA-compliant launch, demonstrating adherence to regulatory requirements.

–       Operational Readiness: The company has successfully allocated the necessary internal resources (e.g. time and expertise) to facilitate the token issuance.

–       Stakeholder Support: Continued backing from founders and stakeholders ensures sufficient capital availability for ongoing operations.

Capital Resources

The company’s capital resources are derived from initial contributions by founders and stakeholders. These resources are sufficient to fund current and planned activities, including the $SWAN token launch. Given the low financial resource intensity of the token issuance process, no material changes to the company’s capital structure are anticipated in the short term.

Non-Financial Factors

The company’s reliance on highly skilled personnel and efficient resource allocation highlights the strength of its operational model. The $SWAN token issuance leverages existing blockchain technology and the team’s expertise, reducing the need for external financial input.

The White Swan project introduces the $SWAN-token, a MiCA-compliant memecoin designed to embody the playful and community-driven nature of meme culture within the crypto ecosystem, while adhering to the regulatory standards of the European Union. Launched through a fair-launch “Initial Coin Offering” (ICO) (i.e. a public offer), $SWAN ensures an equitable token distribution model, which focuses on transparency and inclusivity for all eligible participants.

The concept of $SWAN is inspired by the recent viral phenomenon sparked by Crypto Capo, a prominent memecoin influencer and trader, who shared an image of a black swan in his group chat. This imagery catalyzed the narrative of a new potential sub-category of animal-themed memecoins, combining market trends with creative storytelling.

Therefore, $SWAN positions itself as the symbolic “White Swan” of the crypto-community, which aims at conveying positivity, resilience, and the potential for regulatory-compliant innovation within the memecoin space. The project’s mission is to merge the playful spirit of meme culture with the trust and accountability demanded by the evolving regulatory landscape, making it a standout contender in this emerging niche of animal-themed tokens. The White Swan exemplifies such meme culture itself:

1.    The White Swan

The $SWAN token is a MiCA-compliant memecoin designed to blend the humor and community-driven appeal of meme coins with robust regulatory compliance. Drawing inspiration from a viral trend initiated by Crypto Capo, who posted an image of a black swan, $SWAN leverages this narrative to position itself within a potential new sub-category of animal-themed memecoins. The project aims to challenge the status quo of token launches by embracing compliance without sacrificing the playful, high-energy spirit characteristic of meme culture.

The $SWAN public offer targets various prospective, including non-institutional and other retail investors. The $SWAN public offer is construed in a way where 75% of the tokens are distributed to the public, with 10% reserved for the team, which refers to any closely affiliated legal or natural persons who have entered into an agreement with the offeror, and 15% for the development company to cover future expenses, such as market-making and listing fees. For the avoidance of doubt, the offeror/issuer may hold some of the team allocation on behalf of some team members, although it does not actually retain control of the $SWAN tokens from the team allocation, which is used solely for the purposes of compensating the core team for the development of the $SWAN project. Proceeds from the public offer will benefit the development company, funding ongoing operational and strategic initiatives.

2.   Past and Future Milestones

November 2024

–       Token Issuer Incorporation: Formal establishment of the issuing entity.

–       Grant Research: Exploration of pre-offer funding opportunities to support initial activities.

November–December 2024

–       Legal Materials Preparation: Creation of all required documentation to ensure compliance with MiCA and Finnish regulations.

–       Notification to FIN-FSA: Submission of the required notices to the FIN-FSA.

–       Technical Development: Completion of all blockchain and token-related technical components.

–       Pre-Marketing Activities: Targeting high-net-worth individuals, influencers, and market makers to build momentum.

–       Community and Marketing Setup: Establishing initial community channels and marketing outreach efforts.

January 2025

–       Initiation and conclusion of the public offer.

–       Launch and distribution of the $SWAN token.

February 2025

–       Engagement with market makers to ensure token liquidity and accessibility.

–       Possible initial listings on centralized exchanges to expand market reach.

3.   Outlook and Vision

As the first MiCA-compliant memecoin, $SWAN is positioned to capitalize on the regulatory alignment demanded by exchanges and investors starting in January of 2025. With the compliance landscape shifting, $SWAN aims to stand out as a leader in regulatory adherence while maintaining the fun and creativity of the memecoin space. The project’s unique theme —centered on swans rather than traditional animal memes like dogs or frogs — further sets it apart, signaling the emergence of a new, compliant, and innovative category of tokens.

By combining compliance with creativity, $SWAN not only aims to capture market interest but also to set a new standard for how meme coins are perceived and integrated into the broader crypto ecosystem. The timing of the launch ensures early-mover advantage, making $SWAN a pioneer in this exciting and evolving space.

The resources allocated to the $SWAN project primarily consist of non-financial contributions, including the extensive manhours and expertise provided by the development team of the issuer/offeror. These efforts have been directed towards technical development, compliance with MiCA's obligations, and project planning to ensure a successful public offer and token launch for $SWAN.

Additionally, financial investments have been made in certain key-areas, such as:

-       Website Development: Establishing an online presence and communication platform for the project.

-       Company Incorporation: Covering legal and administrative expenses associated with incorporating the issuing entity to support the token offering and ongoing operations.

The funds collected during the $SWAN token public offer will be allocated strategically to ensure the successful launch and ongoing development of the $SWAN memecoin, as well as to maintain liquidity and market presence. The planned use of funds is as follows:

1.    Development Costs:

A portion of the issued $SWAN tokens will be reserved by the development company to cover future operational expenses. These include:

–       Market-Making: Engaging professional market makers to ensure liquidity and price stability on exchanges.

–       Marketing: Engaging with and/or hiring personnel for marketing purposes.

–       Exchange Listing Fees: Covering costs associated with listing $SWAN on decentralized (DEX) and centralized (CEX) exchanges.

–       Technical Enhancements: Supporting any necessary upgrades or adjustments to maintain the token’s performance and security.

2.   Team Compensation:

–       A portion of the issued $SWAN tokens will be allocated to the team and is therefore used to compensate core contributors for their work in developing and launching $SWAN. This includes the technical, legal, and marketing teams.

–       Subject to a vesting period of 18 months, which means that the team is not able to sell the $SWAN tokens before this time period has elapsed, reducing the chance of negatively impacting $SWAN’s possible market value.

3.   Issuer/Offeror Treasury:

–       A portion of the issued $SWAN tokens will be retained by the issuer/offeror as a strategic reserve. This allocation serves as an investment incentive to further develop and grow the $SWAN ecosystem, funding initiatives such as ecosystem partnerships, platform enhancements, or community rewards.

–       Subject to a vesting period of 18 months, which means that the issuer/offeror is not able to sell the $SWAN tokens before this time period has elapsed, reducing the chance of negatively impacting $SWAN’s possible market value.

–       Additionally, these tokens may be used as leverage for securing strategic opportunities or partnerships, if deemed necessary and appropriate, ensuring the long-term success and sustainability of $SWAN.

4.   Tax Obligations (Directly Funded with the Public Offer):

–       Due to the uncertainty surrounding the taxation of crypto-assets, pre-emptive measures will be taken to ensure full compliance with applicable tax legislation.

–       A substantial portion of the Solana (SOL) raised will have to be immediately liquidated after the public offer to generate fiat currency. This is necessary to cover the tax liabilities that will arise from the public offer of $SWAN.

–       The issuer/offeror intends to seek an advance ruling from the Finnish tax authorities to obtain a binding decision on the tax implications of the public offer of $SWAN, which may require allocating funds towards tax consulting in order to ensure that the issuer/offeror of $SWAN remains compliant with applicable laws.

5.   Liquidity Provision (Directly Funded with the Public Offer):

–       A portion of the proceeds will be dedicated to bootstrapping liquidity on decentralized exchanges (DEXs), ensuring that users can trade $SWAN tokens seamlessly post-launch.

6.   Community and Marketing Efforts (Directly Funded with the Public Offer):

–       Supporting the growth of the $SWAN community through targeted marketing campaigns and influencer partnerships. This includes pre- and post-offer awareness campaigns and ongoing community-building initiatives to sustain momentum post-launch.

7.   Regulatory and Compliance Costs (Directly Funded with the Public Offer):

–       Ensuring continued adherence to MiCA and other relevant regulations, including covering any additional legal or compliance-related expenses that may arise post-offer.

8.   General Operations (Directly Funded with the Public Offer):

–       Remaining funds will be allocated to ensure the long-term viability of the project, supporting general operations, grant applications, and any unforeseen expenses required to scale the $SWAN project successfully.

The $SWAN public offer is driven by the following objectives:

1.    Regulatory Leadership:

This public offer aims to establish $SWAN as the first MiCA-compliant memecoin, setting a new standard for regulatory-compliant crypto-assets while leveraging the increased focus on compliance within the crypto industry starting in January of 2025.

2.   Market Accessibility and Liquidity:

Some of the funds raised will be dedicated for gaining broader access to $SWAN for both retail and institutional investors, facilitating active trading on decentralized (DEX) and centralized (CEX) exchanges through robust liquidity and market-making strategies.

3.   Community Growth and Engagement:

The funds raised will support the development of a vibrant and engaged $SWAN community, reinforcing its position as a leader in the emerging sub-category of animal-themed memecoins.

4.   Funding for Long-Term Development:

The funds raised will support ongoing technical enhancements, market-making, exchange listings, and operational expenses to sustain and grow the $SWAN ecosystem.

The offer price of $SWAN will be determined based on the total amount of SOL raised during the public offer period, which is scheduled from 10.1.2025 to 13.1.2025.

At the conclusion of the public offer, a total of 750 000 000 $SWAN tokens will be distributed to participants in proportion to the SOL they contributed. The issue price for each $SWAN token will be calculated as follows:

Issue Price of 1 $SWAN = Total SOL Raised / 750 000 000

This ensures that the price per token dynamically adjusts based on the total subscription amount, creating a fair allocation model. Examples:

–       If only 1 SOL is raised, the issue price for all 750 000 000 $SWAN will be 1 SOL, resulting in an effective price of 1 $SWAN = 1 / 750 000 000 SOL.

–       If the maximum goal of 5000 SOL is reached, the issue price of 1 $SWAN will be 5000 SOL / 750 000 000, or approximately 0.00000667 SOL per $SWAN.

The $SWAN public offer imposes certain restriction on holders:

Maximum Contribution Per Holder:

–       Each participant in the public offer is limited to a maximum contribution of 250 Solana (SOL).

–       No individual holder or buyer is permitted to deposit more than this amount during the public offer phase.

–       The $SWAN smart contract on Solana has been designed to reject all contributions from prospective holders that exceed the 250 SOL limit.

Restricted Jurisdictions:

Individuals and entities located in jurisdictions identified as high-risk by:

1.      The European Commission under Delegated Regulation (EU) 2016/1675 and its subsequent amendments (latest being Delegated Regulation (EU) 2024/163); and

2.     The Financial Action Task Force (FATF) as high-risk jurisdictions or under increased monitoring.

As of the date of this white paper, these jurisdictions include:

–       (1) Afghanistan; (2) Barbados; (3) Bulgaria; (4) Burkina Faso; (5) Cameroon; (6) Croatia; (7) Democratic Republic of the Congo; (8) Democratic Republic of Korea; (9) Gibraltar; (10) Haiti; (11) Iran; (12) Jamaica; (13) Kenya; (14) Mali; (15) Monaco; (16) Mozambique; (17) Myanmar; (18) Namibia; (19) Nigeria; (20) Panama; (21) Philippines; (22) Russia; (23) Senegal; (24) South Africa; (25) South Sudan; (26) Syria; (27) Tanzania; (28) Trinidad and Tobago; (29) Uganda; (30) United Arab Emirates; (31) Vanuatu; (32) Venezuela; (33) Vietnam; and (34) Yemen

–       However, contrary to the above, there are certain justified exemptions to these restricted jurisdictions, which will be clarified and detailed below.

Exempt High-Risk Jurisdictions

The following high-risk jurisdictions are exempt from this restriction due to demonstrated commitments to improving their anti-money laundering (AML) and counter-terrorism financing (CFT) frameworks and/or progress in implementing FATF recommendations:

1.    Bulgaria

–       Rationale: As an EU member state, Bulgaria has made significant progress in addressing compliance deficiencies and has demonstrated high-level political commitment to work with the FATF to strengthen its AML/CFT regime.

2.   Croatia

–       Rationale: Croatia, also an EU member state, has implemented measures to address AML/CFT shortcomings, including improved licensing and monitoring of Virtual Asset Service Providers (VASPs).

3.   United Arab Emirates (UAE)

–       Rationale: The UAE has shown a sustained commitment to AML/CFT improvements, including applying effective sanctions, enhancing customer due diligence practices, and actively implementing its FATF action plan. Key progress includes:

–       Applying sanctions for non-compliance with AML/CFT and beneficial ownership obligations.

–       Improving effectiveness in investigating and prosecuting money laundering cases aligned with its risk profile.

–       Increasing the quality and quantity of suspicious transaction reports.

In the event that the public offer is cancelled or fails, participants will be refunded through the following mechanism:

1.    Custody of Funds:

–       All Solana (SOL) raised during the public offer are transferred from the smart contract into a supervised financial institution, which acts as the custodian of the collected funds throughout the public offer period on behalf of the offeror to safeguard the crypto-assets raised during the public offer.

2.   Refund Process in Case of Failure or Cancellation:

–       If the public offer fails to meet its objectives or is cancelled for any reason, the SOL collected during the offer will be transferred from the custodied account back into the smart contract by the offeror.

–       Once the SOL is returned to the smart contract, eligible buyers can reclaim their funds through a user-initiated transaction. This process ensures that only the rightful contributors can access their refunds by interacting directly with the smart contract.

–       It is important to note that the offeror will not transfer the SOL directly to buyers, as the refund process is handled transparently and completely through the smart contract via the user-initiated transactions.

3.   No Alternative Refund Mechanism:

–       No other refund mechanism is available or offered, as these methods provide a secure and direct means of reimbursing participants.

The public offer of $SWAN consists of the following phases:

1.    Pre-Offer Phase (November–December 2024)

Preparation and Compliance:

–       Incorporation of the token issuer and submission of the necessary notification to the FIN-FSA to ensure compliance with MiCA’s obligations.

–       Development of the $SWAN token, smart contract, and legal documentation.

–       Creation of the $SWAN deck and marketing materials to outline the purpose and structure of the offer.

Pre-Marketing Activities:

–       Targeted outreach to high-net-worth individuals, influencers, and market makers.

–       Establishment of community engagement channels to build awareness and interest.

2.   Public Offer Phase (10 January 2025 – 13 January 2025)

Fair-Launch public offer:

–       The $SWAN public offer is structured to ensure equal access for all participants.

–       During this period, participants can deposit Solana (SOL) into the $SWAN smart contract. The maximum subscription goal for the offer is 5000 SOL.

Offer Price Determination:

–       The public offer price of $SWAN tokens is determined based on the total SOL raised, calculated as: Price per $SWAN = Total SOL Raised / 750 000 000 $SWAN

Refund Rights:

–       Retail participants can withdraw their contributions without incurring fees by submitting a claim through the smart contract before noon (UTC) on 13.1.2025.

–       For the sake of fairness and transparency, if the ability to submit a claim within the $SWAN public offer smart contract has not yet closed and a participant submits a claim after the noon (UTC) deadline on 13.1.2025, the claim will be processed and approved. However, no reimbursement claims submitted after 13.1.2025 will be processed nor approved in any event.

3.   Post-Offer Phase and Token Distribution (16 January 2025 and forwards)

Refund Period:

–       Participants who submitted a refund claim during the public offer phase can reclaim their SOL directly from the smart contract starting from 16 January 2025.

Final Token Allocation:

–       Starting from 16.1.2025, $SWAN tokens will be distributed to participants who did not request a refund. Token distribution will be pro-rata based on the ratio of each participant’s SOL contribution to the total SOL raised.

Token Liquidity and Market Making:

–       Aim of having $SWAN tokens being listed on decentralized exchanges (DEXs) with initial liquidity bootstrapped using proceeds from the offer.

–       Engagement with market makers (MMs) and targeted centralized exchange (CEX) listings that would increace the accessibility and liquidity for $SWAN.

The $SWAN public offer includes incentives for early and large contributors:

Bonus for Early Buyers:

The first 100 investors who participate in the public offer will each receive 1000 $SWAN tokens as a bonus, in addition to their normal pro-rata allocation.

Bonus for Large Investors:

Investors contributing more than 100 SOL during the public offer will also receive 1000 $SWAN tokens as a bonus.

Stackable Bonuses:

These bonuses are cumulative, meaning that an investor who is both an early buyer and contributes more than 100 SOL will receive a total of 2000 $SWAN in bonuses on top of their normal pro-rata allocation.

Impact on Other Investors:

These bonus allocations are designed to incentivize early participation and significant contributions while having a minimal impact on other investors. The bonuses represent a small fraction of the total 750 000 000 $SWAN tokens being distributed and do not materially dilute the token supply or the pro-rata allocations for other participants.

To ensure the safeguarding of funds collected during this time-limited public offer, the following arrangements have been set in place for compliance with Article 10 of MiCA:

1.    Smart Contract Functionality:

–       All SOL contributions from participants during the public offer are collected through a secure and robust Solana smart contract.

–       The smart contract ensures that contributions are securely managed and transferred directly to a designated custodian account.

2.   Custodian Oversight:

–       The collected SOL is transferred to and held in a supervised financial institution, which acts as the custodian of the funds.

–       The custodian is responsible for safeguarding the contributions until the conclusion of the public offer and any refund processes.

3.   Refund Mechanisms:

–       In the event of cancellation or failure of the public offer, the offeror will transfer the SOL collected during the offer back into the smart contract.

–       Retail participants also have the right to withdraw their contributions during the offer period by submitting claims via the smart contract.

–       Eligible participants can then reclaim their SOL directly from the smart contract through a user-initiated transaction. This ensures that refunds are handled transparently and securely.

–       The offeror will not transfer SOL directly to participants; instead, the smart contract is designed to manage the refund process independently, ensuring fairness and accuracy.

4.   Transparent Allocation:

–       At the conclusion of the public offer, funds are allocated for their intended use, as outlined in this white paper, focusing on regulatory and operational compliance.

The only accepted payment method for purchasing $SWAN tokens during the public offer is through the designated Solana smart contract. Participants must deposit Solana (SOL) directly into the smart contract to complete their purchase of $SWAN.

No other payment methods, including fiat currencies or any other cryptocurrencies, will be accepted during this public offer in order to ensure a secure, transparent, and blockchain-native process for all transactions during the public offer.

Reimbursement to purchasers entitled to a refund will be conducted exclusively through the Solana blockchain, with specific mechanisms depending on the scenario:

1.    Refunds During the Offer Period

Smart Contract-Based Refunds:

–       Purchasers who wish to withdraw their contributions during the public offer can submit a claim for reimbursement directly through the Solana smart contract.

–       Refund requests must be submitted before noon UTC on 13.1.2025.

–       Eligible participants will be able to reclaim their Solana (SOL) from 16.1.2025 onwards via the same smart contract.

2.   Refunds in Case of Cancellation or Failure of the Public Offer

Cancellation-Based Refunds:

–       If the public offer is cancelled or fails, all SOL contributions collected during the offer period will remain safeguarded in a custodial account held by a supervised financial institution until that point.

–       In the event of cancellation or failure of the public offer, the offeror will transfer the SOL collected during the offer back into the smart contract.

–       Eligible participants can then reclaim their SOL directly from the smart contract through a user-initiated transaction. This ensures that refunds are handled transparently and securely.

3.   Exclusivity of Solana-Based Transfers

–       All value transfers for reimbursement, whether due to participant withdrawal or offer cancellation, will occur exclusively via the Solana blockchain.

–       No alternative transfer methods (e.g. fiat or other cryptocurrencies) are available, maintaining a consistent, Solana-native approach to value transfers.

Retail holders who participate in the $SWAN public offer have the right to withdraw their agreement to purchase $SWAN without incurring any fees or costs and without needing to provide any reason. The refund mechanism operates as follows:

1.    Public Offer Period:

–       The $SWAN public offer opens on 10.1.2025, at which time the Solana smart contract for purchasing $SWAN during the public offer will go live.

–       Prospective buyers can deposit Solana (SOL) into the smart contract during the offer period, which ends on 13.1.2025.

2.   Right to Claim Refund:

–       Retail holders who have deposited SOL into the smart contract have until noon (UTC) on 13.1.2025 to submit a reimbursement claim to withdraw their SOL.

–       For the sake of fairness and transparency, if the ability to submit a claim within the $SWAN public offer smart contract has not yet closed and a participant submits a claim after the noon (UTC) deadline on 13.1.2025, the claim will be processed and approved. However, no reimbursement claims submitted after 13.1.2025 will be processed nor approved in any event.

3.   Refund Process:

–       Reimbursement claims are processed through the same Solana smart contract.

–       All retail holders who submit a claim for reimbursement before the deadline can claim their SOL back directly from the smart contract starting from 16.1.2025, during and after the distribution process of $SWAN tokens.

4.   Token Distribution:

–       On 16.1.2024, the $SWAN tokens will be distributed to participants who did not submit a reimbursement claim, in proportion to their SOL contributions.

Purchased $SWAN tokens will be transferred to holders as follows:

1.    Smart Contract Distribution:

–       At the conclusion of the public offer and the refund period, the $SWAN tokens will be distributed via the Solana smart contract through user-initiated transactions.

–       The distribution is scheduled for 16.1.2025, so that focus can be on having all (or at least most of the) refunds processed before token allocation.

2.   Pro-Rata Allocation:

–       The $SWAN tokens will be allocated on a pro-rata basis calculated on the ratio of each participant’s SOL contribution to the total SOL raised during the public offer.

–       Any eligible bonuses (i.e. the early buyer and large contributor bonuses) will be added to the standard pro-rata distribution for qualifying participants.

3.   Blockchain-Based Delivery:

–       The $SWAN tokens will be distributed to eligible participants via the Solana smart contract through user-initiated transactions.

–       Tokens will be delivered directly to the Solana wallet addresses participants used to contribute to the public offer.

–       Direct delivery grants a seamless, transparent, and secure transfer of the $SWAN tokens to holders, while leveraging the efficiency of the Solana blockchain.

4.   Exclusivity of Solana Wallets:

–       Only Solana-compatible wallets can receive $SWAN tokens, as the entire process is conducted on the Solana blockchain. Participants are required to provide valid wallet addresses during the contribution process.

To participate in the public offer and hold $SWAN tokens, purchasers must meet the following technical requirements:

1.    Solana-Compatible Wallet:

–       Purchasers must have a valid Solana-compatible wallet to participate in the public offer and to receive the $SWAN tokens.

–       Examples of compatible wallets include the Backpack wallet, Phantom wallet, Solflare wallet, or practically any other wallets natively supporting the Solana blockchain.

2.   Sufficient SOL for Transactions:

–       Purchasers must have sufficient Solana (SOL) in their wallet to contribute to the public offer and cover the transaction fees associated with the Solana blockchain.

3.   Blockchain Interaction Knowledge:

–       Purchasers should be familiar with interacting with Solana smart contracts, as contributions and token refunds will be managed entirely via the smart contract.

4.   Wallet Address Submission:

–       During the public offer, participants must provide their Solana wallet address to receive the $SWAN tokens.

5.   Secure Wallet Management:

–       Purchasers are responsible for securing their wallet credentials, including private keys and recovery phrases, to ensure the safety of their assets.

The costs are minimal and limited to standard blockchain transaction fees, focusing on accessibility and fairness for all participants. No hidden or issuer/offeror-imposed fees apply to the purchase of $SWAN tokens. Therefore, only the following costs are associated with participating in the $SWAN public offer:

Transaction Fees on the Solana Blockchain:

Purchasers are responsible for paying minimal transaction fees for interacting with the Solana smart contract, including depositing SOL for the public offer and withdrawing SOL in case of a refund. These fees are standard network fees determined by the Solana blockchain and are not controlled by the issuer/offeror of $SWAN.

No Additional Purchase Fees:

There are no additional fees or charges for purchasing $SWAN during the public offer.

Future Costs (Optional):

Purchasers may incur standard Solana network fees when transferring $SWAN tokens after the public offer, such as for trading or liquidity provision on exchanges.

The resources allocated to the $SWAN public offer primarily consist of non-financial contributions, including the extensive manhours and expertise provided by the development team of the offeror. These efforts have been directed towards technical development, compliance with MiCA, and project planning to ensure a successful public offer and token launch.

Additionally, financial investments have been made in the following areas:

–       Website Development: Establishing an online presence and communication platform for the project.

–       Company Incorporation: Covering legal and administrative expenses associated with incorporating the entity provisioning the public offer in order to support the token offering and ongoing operations after the public offer concludes.

The following potential conflicts of interest have been identified in relation to the $SWAN public offer and possible future admission to trading:

1.    Team and Development Company Token Allocation:

–       The $SWAN token allocation includes 10% reserved for the development team and 5% reserved for the development company that issues $SWAN. These $SWAN tokens, however, are subject to an 18-month vesting period.

–       The development company (i.e. the issuer/offeror) additionally reserves 10% of the $SWAN tokens in instantly liquid form, which is allocated to cover future expenses, such as market making and listing fees.

–       This allocation creates a potential conflict of interest, as the team and development company may benefit from the future appreciation of $SWAN tokens. However, the allocation is clearly disclosed and integral for the project’s long-term success.

2.   Early Buyer and Large Investor Bonuses:

–       Early buyers (first 100 participants) and large investors (contributions of +100 SOL) receive a 1000 $SWAN token bonus each, with the possibility of stacking bonuses.

–       This could be perceived as favoring early or large investors. However, the bonuses are transparently communicated, limited and small in scale, and designed to incentivize participation without significantly diluting other investors.

3.   Custodian Relationship:

–       The raised SOL is held in a custodial wallet managed by a supervised financial institution. While the custodian is independent, its role may lead to minor delays or logistical considerations in refund processing if the public offer fails or is cancelled.

4.   Influencer Promotion:

–       The $SWAN public offer leverages marketing efforts that may in the future develop into involving influencers and/or community leaders in the crypto-asset space. These influencers may have personal or financial interests in the success of the project, creating potential biases in their promotion.

Mitigation Measures:

All potential conflicts of interest are transparently disclosed in this offer documentation (i.e. the white paper), and mechanisms are in place to ensure fairness, such as pro-rata token allocation and clear refunding rights. Additionally, all marketing and promotional efforts adhere to ethical standards to maintain transparency and integrity. The issuer and offeror of $SWAN is committed to managing these conflicts of interest responsibly to protect the interests of all participants in the public offer.

The crypto-asset being offered to the public is a MiCA-compliant memecoin named $SWAN (“White Swan”), which represents a new wave of regulatory-compliant crypto-assets, blending the cultural appeal of memecoins with robust adherence to regulations.

Token Classification:

The $SWAN is a non-utility token that designed primarily for trading and participation within the memecoin ecosystem, with no specific use-case in mind. While the $SWAN embodies the playful and community-driven nature of memecoins, it adheres to the regulatory requirements established by MiCA, focusing on compliance and transparency.

Blockchain:

The $SWAN operates on the Solana blockchain, leveraging its high speed and low-cost transaction infrastructure, making it perfect for a meme connoisseurs’ trading asset.

Allocation and Distribution:

A total of 750 000 000 $SWAN tokens will be distributed during a fair-launch public offer, with the focus of the initial launch being on equitable access for participants.

The $SWAN is a pure memecoin with no additional functionality beyond its existence as a tradable token on the Solana blockchain.

Purpose: $SWAN is designed to embody the humor, creativity, and cultural phenomena of the crypto community, leveraging the memecoin narrative to unite a vibrant and engaged community.

Utility: As a memecoin, $SWAN has no intrinsic use case or underlying utility beyond trading and its cultural significance as a compliant and fun crypto-asset.

In short: $SWAN is “just a meme” — a fully MiCA-compliant token created for fun and trading on Solana, and nothing else.

As the $SWAN is a pure memecoin with no additional functionalities beyond its tradable nature on the Solana blockchain, its functionality will apply immediately upon token distribution to the participators of this public offer.

Planned Application Date:

The $SWAN tokens will become tradable starting on 16.1.2025, immediately after their distribution to the public offer participants.

Initial Use Case:

The token’s sole functionality as a memecoin will be enabled from day one, allowing holders to trade and engage with the token as part of the wider memecoin ecosystem on decentralized exchanges (DEXs). With its playful yet compliant design, the $SWAN will be ready to take flight as soon as it lands in participants’ wallets:

1.    General Characteristics:

Name: White Swan ($SWAN)

Type: Crypto-asset other than asset-referenced token or e-money token (memecoin)

Blockchain: Solana

Total Supply: 1 000 000 000 $SWAN

Token Standard: SPL (Solana Program Library)

2.   Classification under MiCA (Regulation (EU) 2023/1114):

The $SWAN is classified as a crypto-asset other than asset-referenced token or e-money token with no intrinsic functionalities beyond trading and participation in the memecoin ecosystem.

3.   Functionality:

Primary Functionality:

The $SWAN is a tradable memecoin that serves no purpose other than being part of the memecoin culture on Solana. It has no additional utility or inherent features, aligning with its identity as a purely cultural and speculative asset.

Functionality Activation Date:

The token’s functionality as a tradable memecoin will be enabled upon distribution to participants on 2025-01-16.

4.   Purpose and Narrative:

Inspired by the “black swan” imagery shared by Crypto Capo, the $SWAN represents a humorous yet regulatory-compliant approach to the memecoin space. As a pioneer of MiCA-compliant memecoins, it serves as a playful critique of traditional token launches.

Rights of the Purchaser:

1.    Token Allocation:

–       Purchasers have the right to receive their pro-rata allocation of $SWAN tokens based on their SOL contribution to the public offer, adjusted for any applicable bonuses (i.e. early buyer or large contributor bonuses).

2.   Withdrawal Rights:

–       Purchasers have the right to withdraw their contribution and request a full refund of their SOL without fees or penalties by submitting a claim via the Solana smart contract before noon UTC on 13.1.2025.

3.   Participation in a Fair-Launch Public Offer:

–       Purchasers are guaranteed equal access to the public offer, with a maximum contribution limit of 250 SOL per participant to ensure fairness and prevent over-concentration (swans cannot easily digest whale meat).

4.   Refund in Case of Cancellation or Failure:

–       If the public offer is cancelled or fails, purchasers have the right to a full refund of their SOL directly from the custodian holding the funds.

5.   Ownership Rights:

–       Upon receiving the $SWAN tokens, purchasers hold full ownership rights over their tokens, which can be freely traded or held at their discretion.

Obligations of the Purchaser:

1.    Technical Requirements:

–       Purchasers are obligated to provide a valid Solana-compatible wallet address to receive the $SWAN tokens.

–       Purchasers must ensure that they have sufficient SOL to cover the transaction fees for interactions with the Solana blockchain.

2.   Compliance with Contribution Limits:

–       Purchasers must adhere to the maximum contribution limit of 250 SOL per individual during the public offer.

3.   Secure Wallet Management:

–       Purchasers are responsible for securely managing their wallet credentials, including private keys and recovery phrases, to safeguard their assets.

Exercise of Purchaser Rights:

1.    Right to Token Allocation:

Procedure:

–       Tokens will be distributed to the Solana-compatible wallet address that was provided by the purchaser at the time of contribution.

–       Distribution is scheduled for 16.1.2025, following the conclusion of the refund period and the conclusion of the public offer.

Condition:

–       Purchasers must contribute SOL via the Solana smart contract during the public offer period (10.1.2025 to 13.1.2025) and not submit a refund claim by the refund deadline (13.1.2025, by noon UTC).

2.   Right to Withdraw from Purchase:

Procedure:

–       Purchasers who wish to withdraw their contributions must submit a claim for reimbursement via the Solana smart contract before noon UTC on 13.1.2025.

–       Refunds will be processed and available for retrieval directly from the smart contract starting 16.1.2024.

Condition:

–       Refunds are only available to those who request them before the refund deadline and consequently do not receive their $SWAN tokens during the distribution period.

3.   Right to Refund Upon Offer Cancellation or Failure:

Procedure:

–       If the public offer is cancelled or fails, the SOL contributions will be refunded directly from the supervised custodian account holding the funds.

–       Refunds will be initiated promptly by the custodian and purchasers will be informed of the process.

Condition:

–       Applies automatically to all purchasers in the event of offer cancellation or failure.

4.   Right to Trade Tokens:

Procedure:

–       Purchasers can freely trade $SWAN tokens after receiving them in their wallets. Initial liquidity for trading should be provided on decentralized exchanges (DEXs).

Condition:

–       Tokens must be held in a Solana-compatible wallet to facilitate trading.

5.   Fulfillment of Purchaser Obligations:

Technical Requirements:

–       Purchasers are required to provide a valid Solana-compatible wallet address and ensure they have sufficient SOL for network transaction fees.

Compliance with Contribution Limits:

–       Purchasers must adhere to the maximum contribution limit of 250 SOL during the public offer period.

Secure Wallet Management:

–       Purchasers are obligated to securely manage their wallet credentials, including private keys, to prevent unauthorized access to their funds and tokens.

No modifications to the rights and obligations of purchasers are anticipated or planned due to the short duration of the public offer, which runs from 10.1.2025 to 13.1.2025.

The terms of the public offer, including purchaser rights (e.g. refund rights, token allocation) and obligations (e.g. contribution limits, technical requirements), are fixed and transparently communicated in advance. This ensures stability and predictability for all participants. In the unlikely event of unforeseen circumstances requiring modifications, participants will be notified promptly, and any changes will comply with applicable regulatory requirements to protect purchaser interests.

No future public offers of $SWAN tokens will ever take place. This is a one-time-only event, just like spotting a real white swan in a world of memecoin frogs and dogs.

Between 10.1.2025 and 13.1.2025, the entire supply of 750 000 000 $SWAN tokens will be distributed, and that’s it — no more minting, no future sales, no second chances. Once this swan takes flight, there’s no catching it.

“Miss the $SWAN ICO? Too bad, now you’ll have to chase it across the pond on DEXs. 🦢💨” – Someone, somewhere (probably).

After the conclusion of the public offer on 13.1.2025, the $SWAN tokens should soon be tradable on decentralized exchanges (DEXs) operating on the Solana blockchain, with potential centralized exchange (CEX) listings to follow, depending on the funds raised.

How and Where $SWAN Tokens Can Be Purchased or Sold:

1.    Decentralized Exchanges (DEXs):

–       Starting 16.1.2025, initial liquidity will be bootstrapped on popular Solana-based DEXs, such as Raydium or Orca.

–       Token holders can use their Solana-compatible wallets to trade $SWAN directly in a decentralized, peer-to-peer environment.

2.   Centralized Exchange (CEX) Listings (If Funded):

–       If the public offer raises sufficient funds to cover listing fees and associated costs, the $SWAN tokens will be submitted for listing on centralized exchanges.

–       CEX listings will enhance accessibility and liquidity for $SWAN, catering to a broader audience beyond the Solana ecosystem.

3.   Market Access and Liquidity:

–       Market-making efforts should enable robust liquidity for $SWAN tokens, regardless of the trading venue.

“Missed the $SWAN ICO? Don’t worry, whether it’s swimming gracefully on a DEX or landing on a CEX runway (if we raise enough), the graceful $SWAN will be there, gliding into your portfolio. 🦢💸” (/s: for legal reasons, this is a joke)

While the $SWAN tokens distributed to public participants will be freely transferable immediately upon receipt starting on 16.1.2025, the issuer and team allocations are subject to a lock-up period to ensure alignment with the community and avoid conflicts of interest:

Lock-Up Period for the Issuer and Team:

1.    18-Month Vesting Period:

–       Certain tokens allocated to the issuer (5% of total supply) and all tokens allocated to the team (10% of total supply) will be subject to an 18-month vesting period.

–       This means that these tokens will not be immediately tradable and will be unlocked after the vesting period, ensuring the issuer and team remain committed to the project’s long-term success.

–       However, contrary to the above, 10% of the total supply of $SWAN will be retained by the issuer/offeror in immediately liquid form for ecosystem development purposes, which may include, but is not necessarily limited to, market making, paying of salaries, listing fees, technical development costs, consulting fees, and so on.

2.   Purpose of Lock-Up:

The vesting arrangement is designed to:

–       Mitigate potential conflicts of interest.

–       Prevent actions such as a “rug pull,” where the issuer or team could sell large amounts of tokens immediately post-launch.

–       Align the issuer and team incentives with those of the community and public investors.

3.   Community Trust:

–       By implementing this lock-up period, the issuer demonstrates its commitment to the $SWAN project’s longevity and the community’s trust.

“No quick exits here—this swan is committed to gliding with the flock for the long haul. Rug pull? Not in this pond. 🦢🔒”

General Information on Distributed Ledger Technology and Blockchain

Distributed Ledger Technology (DLT) describes a decentralized and distributed network system architecture where multiple participants maintain and verify a shared database. Unlike traditional databases, DLT systems do not rely on a central authority to ensure data consistency and security. Rather, they distribute control across a network of computers (nodes) and require all changes to be recorded and agreed by the nodes. This distributed approach enhances the resilience and security of such a system, and transparency of the data stored in it without the need for trust between the actors of the systems.

Blockchain technology is a subset of DLT, where the distributed database maintains a continuously growing list of records, called blocks, which are linked together in chronological order and secured using cryptographic techniques. A blockchain generally has the following key characteristics:

–       Distribution: A blockchain operates on a network of nodes, each holding a copy of the ledger and each participating in the transaction verification and synchronization process.

–       Security: Blockchain employs advanced cryptographic methods to secure data. Each block contains a cryptographic hash (a ‘digital fingerprint’) of the previous block, a timestamp, and transaction data. This structure ensures that once data is recorded, it cannot be altered retroactively without also changing all subsequent blocks, which would require consensus from the majority of the network nodes.

–       Transparency and Immutability: Transactions on a blockchain are usually visible to all participants in the network, providing transparency. Once a transaction is confirmed and added to the blockchain, it is virtually immutable due to the cryptographic methods used, meaning it cannot be changed or deleted.

The Solana Blockchain

The Solana blockchain is a high-performance, permissionless, decentralized blockchain built to support scalable applications and crypto-assets. It employs unique innovations to achieve high throughput and low latency, making it well-suited for projects like $SWAN.

Key Characteristics of the Solana Blockchain:

1.    High Throughput and Scalability:

–       Solana is designed to process up to 65 000 transactions per second (TPS), far exceeding many other blockchains.

–       This scalability is achieved through a novel implementation of a concensus mechanism called Proof of Stake (PoS), combined with Proof of History (PoH) technology.

Low Transaction Costs:

–       Transaction fees on Solana are significantly lower compared to other major blockchains, making it an attractive platform for microtransactions and high-frequency trading.

–       This ensures accessibility for retail participants in projects like $SWAN, where transaction costs could otherwise be a significant barrier to such activities.

Proof of History (PoH):

–       PoH is a cryptographic technique that creates a historical record to prove that transactions occurred in a specific sequence.

–       PoH serves as a “cryptographic clock”, providing a historical record, which proves that events occurred in a specific sequence, enhancing throughput and efficiency.

–       This enables high-speed transaction verification and minimizes delays in network synchronization.

Energy Efficiency:

–       Solana is known for its energy-efficient operations due to its combination of PoH and PoS, making it an environmentally conscious choice for blockchain projects.

Developer and User Ecosystem:

–       Solana supports a robust ecosystem of decentralized applications (dApps) and projects, facilitated by the Solana Program Library (SPL) for token standards, including the one used for building $SWAN.

–       Solana’s growing community ensures ongoing improvements, widespread adoption, and support for new crypto-assets.

Why Solana for $SWAN?

–       Speed and Efficiency: The ability to handle high transaction volumes with minimal latency ensures that $SWAN can operate smoothly, even during high demand.

–       Cost-Effectiveness: Low fees make trading $SWAN accessible for a broad range of users, aligning with the project’s goal of inclusivity.

–       Ecosystem Compatibility: Solana’s thriving ecosystem provides the infrastructure necessary for $SWAN to thrive as a memecoin, with decentralized exchanges and wallets readily available for participants.

Protocols and Consensus Mechanisms:

1.    Proof of History (PoH):

–       A unique innovation of the Solana blockchain – PoH serves as a cryptographic timestamp that establishes a historical record of transactions.

–       PoH optimizes transaction validation by enabling nodes to agree on the order and time of transactions without extensive communication overhead, allowing for high-speed processing.

2.   Proof of Stake (PoS):

–       Solana’s network operates on a PoS consensus mechanism, where validators are selected based on the number of SOL tokens staked.

–       This mechanism enhances security, energy efficiency, and scalability by requiring validators to commit resources to participate in the network.

Technical Standards:

1.    Solana Program Library (SPL):

–       $SWAN adheres to the SPL token standard, the Solana blockchain’s equivalent of ERC-20 used within the Ethereum blockchain.

–       This standard ensures compatibility with Solana’s ecosystem, including decentralized exchanges (DEXs), wallets, and decentralized applications (dApps).

2.   Transaction Efficiency:

–       Transactions are optimized for minimal latency, with the blockchain capable of processing up to 65 000 transactions per second (TPS).

–       $SWAN benefits from Solana’s low transaction fees, making it ideal for high-frequency trading and broad accessibility.

3.   Secure Token Transfers:

–       Solana utilizes advanced cryptographic techniques, including elliptic curve cryptography, to ensure the security of token transfers.

Why These Standards Matter for $SWAN:

–       The use of Solana’s protocols and technical standards enables $SWAN to provide a fast, secure, and cost-effective experience for participants. These features ensure that $SWAN operates efficiently within the Solana ecosystem, supporting its goals of accessibility, scalability, and compliance in the crypto-asset space.

Technology Enabling Holding, Storing, and Transfer

1.    Solana-Compatible Wallets:

–       The $SWAN tokens can be held and stored in any Solana-compatible wallet, such as Phantom, Solflare, or other wallets supporting the Solana Program Library (SPL) token standard.

–       These wallets provide secure storage and user-friendly interfaces for managing $SWAN and other Solana-based tokens.

2.   Decentralized Ledger:

–       The Solana blockchain serves as the decentralized ledger for all $SWAN transactions.

–       It maintains an immutable record of token ownership and transfers, ensuring transparency and security.

3.   SPL Token Standard:

–       The $SWAN is an SPL token, which is Solana’s equivalent to Ethereum’s ERC-20 standard.

–       This standard ensures compatibility across Solana’s ecosystem, enabling seamless integration with decentralized exchanges (DEXs), wallets, and decentralized applications (dApps).

4.   Smart Contracts:

–       All token issuance, refund mechanisms, and transfers during the public offer are managed by audited Solana smart contracts, ensuring transparency and security.

–       The smart contract infrastructure guarantees accurate token distribution and the enforcement of vesting schedules for the issuer and team allocations.

5.   Blockchain Scalability:

–       Solana’s high throughput (up to 65 000 transactions per second) and low fees allow $SWAN to be transferred efficiently, even during periods of high network activity.

Security Measures for Holding and Transfers

1.    Private Key Management:

–       Users must securely store their wallet private keys and recovery phrases to maintain control over their $SWAN tokens.

2.   Cryptographic Integrity:

–       Solana uses elliptic curve cryptography to ensure that all transactions and transfers are securely verified and executed.

Please refer further to the information provided in section H.1 above.

Please refer further to the information provided in section H.1 above.

Please refer further to the information provided in section H.1 above.

1.    Regulatory Risks:

Compliance with MiCA:

Although the $SWAN is designed to be fully compliant with MiCA, future changes to regulatory requirements could affect the token’s status or its ability to be traded.

Jurisdictional Limitations:

Purchasers must ensure compliance with local laws in their respective jurisdictions, as regulatory treatment of crypto-assets may vary.

2.   Market and Liquidity Risks:

Volatility:

As a memecoin, $SWAN’s value is likely to be highly volatile and subject to market speculation. The token’s price may fluctuate significantly, resulting in potential losses.

Liquidity Risk:

The availability of liquidity depends on the level of trading activity on decentralized exchanges (DEXs) and, if funded, on centralized exchanges (CEXs). Insufficient trading volume could hinder the ability to buy or sell the $SWAN tokens.

3.   Operational and Technical Risks:

Blockchain Dependency:

The $SWAN relies entirely on the Solana blockchain. Downtime, congestion, or security vulnerabilities in the Solana network could negatively impact token functionality.

Smart Contract Risks:

Although the $SWAN smart contract is robustly built, there is a risk of unforeseen vulnerabilities or bugs that could affect the offer or token distribution.

4.   Custodial and Reimbursement Risks:

Custodial Fund Management:

Contributions during the public offer are safeguarded by a supervised financial institution. However, operational delays or unforeseen circumstances at the custodian could impact the speed of reimbursements in the event of a failed or cancelled offer.

Refund Timing:

Participants who request refunds or if the offer fails/cancels must wait until the specified dates for their contributions to be reimbursed, potentially impacting short-term liquidity.

5.   Team and Issuer Vesting Risks:

Conflicts of Interest Mitigation:

While all of the team’s and a substantial portion of the issuer’s $SWAN tokens are subject to an 18-month vesting schedule to prevent ‘rug pulls’ and significant conflicts of interest, the expected unlocking of tokens could introduce selling pressure over time.

6.   Speculative Nature of Memecoins:

Lack of Intrinsic Value:

The $SWAN has no inherent utility beyond its role as a memecoin. Its value is primarily driven by community interest, speculative trading, and market sentiment. This poses a significant risk to long-term value stability.

1.    Market Volatility Risks:

High Volatility:

The value of $SWAN is expected to be highly volatile, driven by speculation, meme culture trends, and market sentiment. Prices can fluctuate significantly, leading to potential losses for holders.

Speculative Nature:

The $SWAN has no intrinsic utility or underlying value beyond its role as a memecoin. Its valuation depends entirely on market demand and community interest.

2.   Liquidity Risks:

Liquidity Dependency:

The liquidity of $SWAN relies on trading activity on decentralized exchanges (DEXs) and, potentially, centralized exchanges (CEXs) if listing goals are achieved. Insufficient liquidity could make it difficult for holders to buy or sell tokens at desired prices.

3.   Blockchain Risks:

Solana Network Dependency:

The $SWAN operates exclusively on the Solana blockchain. Any issues with Solana, such as network downtime, congestion, or security vulnerabilities, could disrupt the transfer, trading, or functionality of $SWAN.

Transaction Costs:

While Solana offers low transaction fees, significant network congestion or other technical issues could lead to increased costs or delays for token transfers.

4.   Security Risks:

Smart Contract Vulnerabilities:

Although the $SWAN smart contract is robustly built, there is always a risk of undiscovered vulnerabilities or exploits that could affect token security or distribution.

Private Key Management:

Holders must securely manage their wallet private keys and recovery phrases. Loss of wallet credentials would result in the permanent loss of $SWAN tokens, as blockchain transactions are irreversible.

5.   Community and Narrative Risks:

Dependence on Community Interest:

The $SWAN’s success and market value are heavily dependent on its community and the popularity of the memecoin narrative. Declining interest or negative sentiment could significantly impact the token’s value.

Emerging Trends:

The memecoin market is influenced by rapidly changing trends and narratives. Competing tokens or shifts in market attention could overshadow the $SWAN despite its massive wing-span and impressive flying capabilities.

6.   Regulatory Risks:

Evolving Legal Frameworks:

While the $SWAN is MiCA-compliant, future regulatory changes or interpretations could impact its classification, trading availability, or use.

Jurisdictional Restrictions:

Holders in certain jurisdictions may face restrictions or obligations related to holding or trading crypto-assets like the $SWAN.

7.   Vesting and Token Release Risks:

Team and Issuer Tokens:

While subject to an 18-month vesting schedule, the ultimate release of team and issuer allocations may introduce selling pressure, potentially impacting token value over time.

8.   Technological Obsolescence:

Innovation Risk:

The crypto-asset space evolves rapidly. New technologies or platforms could render Solana or $SWAN’s design less competitive, impacting adoption and value.

Participants should approach the $SWAN with a clear understanding of its speculative and volatile nature and be prepared to accept these risks.

1.    Funding Risks:

Insufficient Funding from the Public Offer:

The project relies on the public offer to raise sufficient funds. If the offer raises insufficient funds, planned initiatives, such as centralized exchange (CEX) listings or extensive marketing campaigns, may be delayed or scaled back.

2.   Technical Development Risks:

Smart Contract Issues:

While the $SWAN smart contracts are robust, unforeseen bugs or vulnerabilities could disrupt token distribution, refunds, or vesting mechanisms.

Blockchain Dependency:

As the project operates exclusively on the Solana blockchain, any network issues such as downtime, congestion, or security breaches could impact the implementation.

3.   Regulatory and Compliance Risks:

Regulatory Delays or Changes:

Although $SWAN complies with MiCA, changes to the legal framework or additional requests by authorities (e.g. further information requests by the FIN-FSA connected to this white paper) could hinder the project’s implementation.

4.   Operational Risks:

Resource Allocation:

The success of $SWAN depends on the issuer and team allocating sufficient resources (both financial and non-financial) to ensure timely project delivery. Any mismanagement could delay or compromise key milestones.

Team Vesting Schedule:

While the team’s 18-month vesting period aligns interests with the community, the unlocking of tokens may impact focus or long-term commitment if team members divest significant holdings.

5.   Market Adoption Risks:

Memecoin Saturation:

The memecoin market is highly competitive and driven by trends. There is a risk that $SWAN may fail to capture sufficient market interest, limiting its adoption.

Community Engagement:

The success of $SWAN relies heavily on community-driven marketing and engagement. Failure to build or sustain an active community could hinder the project’s growth and long-term tradeability.

6.   Timeline and Milestone Risks:

Delayed Milestones:

Key deliverables, such as token distribution, decentralized exchange (DEX) liquidity bootstrapping, or market-making efforts, may face delays due to technical, operational or market challenges, or if insufficient amount of funds are raised.

Centralized Exchange (CEX) Listings:

CEX listings depend on achieving the necessary funding to cover listing fees. Delays or insufficient funding could postpone broader market access.

7.   Ecosystem Risks:

Dependency on External Partners:

The project relies on partnerships with decentralized exchanges, market makers, and potential centralized exchanges. Any failure or delay by these partners could disrupt implementation plans.

8.   Narrative and Meme-Driven Risks:

Loss of Market Momentum:

The project capitalizes on the popularity of meme culture. Shifts in market sentiment or the emergence of competing narratives could reduce interest.

9.   Mitigating these Risks

Participants should carefully consider these risks and understand that successful implementation of $SWAN depends on various interrelated factors, including technical development, market adoption, and regulatory compliance.

“The $SWAN’s flight is planned, but the winds of crypto can be unpredictable. 🦢⚠️”

The $SWAN token relies on the Solana blockchain and associated technologies, which present certain risks:

1.    Blockchain Dependency Risks

Solana Network Downtime:

The Solana blockchain may experience outages, downtime, or congestion, which could disrupt token transfers, trading, or other functionalities.

Scalability Challenges:

While Solana is designed for high throughput, unexpected network demand or technical issues could reduce its efficiency.

2.   Smart Contract Risks

Vulnerabilities:

Although the $SWAN smart contracts are meticulously designed, there always exists a risk of undiscovered vulnerabilities or bugs that could be exploited, potentially affecting token distribution or vesting schedules.

Immutability Risks:

Errors in the smart contract code cannot be changed once deployed, leading to potential operational or security issues.

3.   Wallet and Storage Risks

Private Key Management:

Holders must securely manage their private keys and recovery phrases. Loss of these credentials would result in permanent loss of access to their $SWAN tokens.

Compatibility Issues:

The $SWAN tokens can only be held in Solana-compatible wallets. Any incompatibility or wallet-specific technical issue may affect access or transfers.

4.   Network Security Risks

Attack Risks:

The Solana blockchain could be targeted by various attacks, such as denial-of-service (DoS) attacks or exploits on the consensus mechanism, affecting overall network integrity.

Centralization Concerns:

While Solana is decentralized, its relatively smaller validator set compared to some blockchains may pose centralization risks, potentially impacting network resilience.

5.   Ecosystem Dependency Risks

DEX and CEX Integration Issues:

Integration of $SWAN with decentralized exchanges (DEXs) and potential centralized exchange (CEX) listings relies on the compatibility and reliability of these platforms. Any technical issues on these platforms could disrupt trading or liquidity.

6.   Evolving Technology Risks

Technological Obsolescence:

The rapid pace of innovation in blockchain technology could render Solana or the SPL token standard less competitive or outdated, impacting $SWAN’s usability or adoption.

The $SWAN project implements several measures to mitigate the risks associated with the technology used to deploy the $SWAN public offer as follows:

1.    Blockchain Dependency Risks

Choice of Solana Blockchain:

The Solana blockchain was selected for its proven high throughput, low transaction costs, and active developer community, reducing the likelihood of performance or scalability issues that could negatively impact participants.

Ecosystem Engagement:

The project actively engages with Solana’s robust ecosystem, including wallets, decentralized exchanges (DEXs), and development tools, while focusing on equal access to ongoing updates and improvements.

2.   Smart Contract Risks

Comprehensive Testing:

The smart contracts were extensively tested in multiple scenarios to ensure reliability and correctness during token distribution and refunds.

3.   Wallet and Storage Risks

User Education:

The project provides clear guidance to participants on securely managing their private keys and using Solana-compatible wallets, minimizing risks related to loss of access.

Compatibility Assurance:

The $SWAN token is built to comply fully with the Solana Program Library (SPL) token standard, ensuring compatibility with widely used Solana wallets and applications.

4.   Network Security Risks

Validator Network Diversity:

Solana’s validator network continues to grow and diversify, enhancing resilience against potential centralization or targeted attacks.

Monitoring and Updates:

The team monitors Solana’s network health and smart contracts as necessary to maintain compatibility with network improvements.

5.   Ecosystem Dependency Risks

Partnerships with Established Platforms:

The $SWAN implementing team aims to collaborate with established and reliable DEXs to ensure a smooth trading experience. Any potential future CEX listings shall always prioritize reputable platforms to reduce operational risks.

6.   Evolving Technology Risks

Adoption of Updates:

The $SWAN project team actively monitors advancements in blockchain technology and commits to adopting improvements in the Solana ecosystem to maintain competitiveness.

“This swan isn’t just flying blind — we’ve got the tech ducks in a row too. 🦢✨”

As $SWAN has not yet launched at the time of publishing this white paper, all information regarding potential adverse impacts on the climate and the environment is based on estimates and projections. These estimates are derived from the technology stack and operational framework selected for the project; the Solana blockchain.

The Solana blockchain is recognized for its energy-efficient Proof of Stake (PoS) consensus mechanism, which significantly reduces the environmental footprint compared to traditional Proof of Work (PoW) blockchains. Despite this, the $SWAN project acknowledges that blockchain operations inherently consume energy, and some level of environmental impact may arise from the creation and distribution of $SWAN tokens.

Further assessments of $SWAN’s actual environmental impact will be provided below.

J.1      Mandatory information on principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism

1.    General information and key indicators

Number Go Up Technologies Oy acting as the issuer and offeror of crypto-assets other than asset-referenced tokens or e-money tokens is providing information on principal adverse impacts on the climate and other environment-related adverse impacts of the consensus mechanism used to validate transactions in $SWAN and to maintain the integrity of the distributed ledger of transactions.

The information covers the period from 01.01.2024 to 31.12.2024 with estimates used for the period from 01.01.2025 to 31.12.2025.

The validation of transactions in $SWAN and the maintenance of the integrity of the distributed ledger of transactions has led to a total energy consumption of 0 kWh during 2024.

The validation of one transaction in $SWAN has led to a total energy consumption of 0 kWh/Tx on average during 2024.

The validation of transactions in $SWAN and the maintenance of the integrity of the distributed ledger of transactions has resulted in 0 tonnes GHG emissions, with 0 tCO2e/year resulting from scope 1 GHG emissions and 0 tCO2e/year resulting from scope 2 GHG emissions, calculated based on sources owned or controlled by the DLT network nodes (scope 1), and indirect emissions from energy purchased by the DLT network nodes (scope 2), during 2024.

2.   Features of the consensus mechanism[s] relevant for principal adverse impacts on the climate and other environment-related adverse impacts

For general description of the Solana blockchain’s consensus mechanism, please refer to section H.1 above, which can be accessed here.

ANNEXES

A.        Climate and other environment-related indicators

Rationale for the Selected Methodologies

1.    Alignment with Indicator Definitions

The selected methodologies align directly with the definitions provided in the ESMA consultation package. This ensures that calculations and descriptions meet regulatory expectations.

2.   Consistency Across Indicators

Many indicators build on one another (e.g. Scope 1, 2, and 3 emissions). By using cross-compatible methodologies, calculations for related indicators (e.g. energy mix, carbon intensity) remain consistent and comparable.

3.   Flexibility for Data Availability

The methodologies are adaptable to scenarios where data availability may be limited. For instance, regional averages for energy mix or water consumption can be applied when validator-specific data is unavailable.

4.   Lifecycle Perspective

For indicators such as hazardous waste or natural resource impact, methodologies incorporate a lifecycle approach that considers production, use, and disposal phases of validator hardware.

A.1     Methodology for Energy Consumption

1.    General Approach

For Proof of Stake (PoS) blockchain networks, the total electricity consumption is determined by analyzing two key factors:

–       Number of validating nodes in the network.

–       Power demand of individual validating nodes.

These metrics provide the foundation for calculating the energy used for transaction validation and the maintenance of the distributed ledger.

2.   Steps for Calculating Total Energy Consumption

a.   Determining the Number of Validating Nodes:

The number of validating nodes is obtained from block explorers or other data providers that monitor the peer-to-peer (P2P) network.

Only validating nodes are considered, as these nodes are responsible for validating transactions and maintaining the integrity of the distributed ledger. Full nodes that only store or relay data are excluded from this calculation.

b.   Measuring Power Demand of Individual Validating Nodes:

Since the specific power consumption of validating nodes is not directly available, estimates are generated based on:

–       Common hardware requirements of the blockchain network.

–       Empirical measurements using reference hardware setups in controlled environments.

–       The reference hardware includes a range of devices from low-power nodes (e.g. Raspberry Pi) to high-performance server-grade machines.

c.   Marginal Electricity Consumption Per Transaction:

The marginal electricity consumption per transaction is calculated based on:

–       The power demand of an average validating node.

–       The transaction throughput of the node over a specific measurement period.

–       This allows for a nuanced estimation of how individual transactions contribute to overall electricity usage.

3.   Formula for Total Energy Consumption

Total Energy Consumption = Number of Validating Nodes x Average Power Demand per Node

Where:

–       Number of Validating Nodes: Retrieved from network monitoring tools.

–       Average Power Demand per Node: Based on empirical measurements using a representative hardware set.

A.2     Methodology for Non-Renewable Energy Consumption

1.    Overview

The calculation of the share of non-renewable energy consumption in blockchain networks is independent of the specific blockchain type or consensus mechanism. It directly builds upon the total energy consumption metrics. The primary data required includes:

Total Energy Consumption: As determined by prior methodologies.

Geographical Distribution of Energy Consumption: Identifying the locations of entities consuming electricity within the network.

2.   Steps for Calculating Non-Renewable Energy Consumption

a.   Determining the Geographical Distribution of Energy Consumption:

–       Node Location Data: Utilize external data providers to gather information on the geographical locations of nodes within the blockchain network. This data helps in understanding where energy consumption is occurring.

–       Assumptions in Absence of Data: If specific location data is unavailable for a network, apply a global average for energy consumption distribution.

b.   Assessing Energy Mix by Region:

–       Regional Energy Profiles: Obtain data on the energy mix (proportion of renewable vs. non-renewable energy sources) for each identified region. This information is typically available from national energy statistics or international energy agencies.

c.   Calculating Non-Renewable Energy Consumption:

–       Weighted Calculation: Multiply the total energy consumption by the percentage of non-renewable energy in each region. Sum these values to obtain the overall non-renewable energy consumption for the network.

3.   Formula for Non-Renewable Energy Consumption

Non-Renewable Energy Consumption = {i=1}^{n} (Energy Consumption in Region i x Percentage of Non-Renewable Energy in Region i) 

Where:

–       n  = Number of regions with identified energy consumption.

–       Energy Consumption in Region  i : Total energy consumed by nodes located in region  i.

–       Percentage of Non-Renewable Energy in Region  i : Proportion of energy from non-renewable sources in region  i.

4.   Data Sources

–       Node Location Data: Third-party data providers specializing in blockchain network analysis.

–       Regional Energy Mix Data: National energy statistics, reports from international energy agencies, and databases such as the International Energy Agency (IEA) or the U.S. Energy Information Administration (EIA).

A.3     Methodology for Energy Intensity

1.    Overview

MiCA distinguishes between energy consumption for securing the integrity of the distributed ledger and for validating transactions. To accurately assess energy consumption per activity, it’s essential to avoid attributing the entire energy usage solely to transactions. This methodology outlines three approaches to energy allocation: holding-based, transaction-based, and a hybrid approach, with the hybrid approach being preferred for its alignment with MiCA.

2.   Allocation Approaches

a.   Holding-Based Approach:

–       Definition: This approach allocates the total energy consumption of the network to the total supply of the cryptocurrency.

–       Calculation: Energy Consumption per Unit Held = Total Energy Consumption / Total Supply

–       This method assumes that holdings are the primary driver of energy consumption, particularly relevant in Proof of Work (PoW) systems where holders indirectly compensate miners through mechanisms like inflation or block rewards.

Limitations:

–       It overlooks the impact of transactions as contributors to energy consumption.

–       It’s most applicable when transaction fees are minimal or non-existent.

b.   Transaction-Based Approach:

–       Definition: This method divides the total energy consumption of the network by the number of transactions over a specific period.

–       Calculation: Energy Consumption per Transaction = Total Energy Consumption / Number of Transactions

–       While straightforward, this metric can misrepresent the actual energy usage driven by transactions.

Limitations:

–       It may overstate the energy consumption attributable to transactions, especially in networks where ledger maintenance consumes significant energy regardless of transaction volume.

–       It doesn’t account for non-transactional activities, such as data storage in certain networks.

c.   Hybrid Approach (Preferred):

Definition: The hybrid approach distributes total energy consumption between transactions and holdings, providing individual metrics for each activity.

Calculation:

Marginal Electricity Consumption for Transactions: Derived from Indicator 1, this measures the additional energy required for validating transactions.

Remaining Energy Consumption for Holdings: After accounting for transaction-related energy use, the remaining energy consumption is allocated to holdings.

Total Energy Consumption = Transaction-Related Energy + Holding-Related Energy

3. Application to PoS Networks

Characteristics:

–       In Proof of Stake (PoS) systems, regular ledger maintenance is the primary energy driver, with transactions contributing a smaller marginal energy cost.

Methodology for PoS:

–       Utilize the marginal electricity consumption per transaction (as indicated in Indicator 1) to estimate transaction-driven energy use.

–       Attribute the remaining energy consumption to holders, reflecting their role in maintaining the ledger’s integrity.

3.   Formula for Hybrid Energy Allocation

For Transactions:

Energy per Transaction = Marginal Energy per Transaction (from Indicator 1)

For Holdings:

Energy per Unit Held = Remaining Energy Consumption / Total Supply

Where:

–       Marginal Energy per Transaction is derived from empirical data.

–       Remaining Energy Consumption equals Total Energy Consumption minus Transaction-Related Energy.

5.   Benefits of the Hybrid Approach

–       Alignment with MiCA: Provides metrics that comply with MiCA’s requirements to differentiate between ledger maintenance and transaction validation.

–       Fairness: Balances energy attribution between transactions and holdings, offering a comprehensive view of energy impacts.

–       Flexibility: Accounts for advancements like Layer 2 networks and varying consensus mechanisms.

This methodology ensures accurate, fair, and regulatory-aligned energy allocation metrics, addressing the distinct roles of transactions and holdings in blockchain energy consumption.

A.4     Methodology for Scope 1 - Controlled GHG Emissions

1.    Overview

Scope 1 - Controlled GHG emissions include direct greenhouse gas emissions resulting from activities that are controlled by the blockchain network’s node operators. For Proof of Stake (PoS) networks, Scope 1 emissions are generally associated with the direct fuel consumption of validating nodes that may rely on on-site energy generation (e.g. backup generators or self-operated systems).

2.   Steps for Calculating Scope 1 GHG Emissions

a.    Identify Nodes with Direct Emissions:

–       Collect data on validating nodes that operate infrastructure producing direct emissions (e.g. diesel generators for backup power or self-generated electricity).

–       Node-specific data may include the number of nodes with on-site power generation and their estimated fuel consumption.

b.   Measure Fuel Consumption:

–       Estimate or obtain data on the type and quantity of fuel used by the identified nodes.

–       Common fuels include diesel, natural gas, or other fossil fuels used for power generation.

c.    Calculate Emissions Using Standard Emission Factors:

–       Apply the appropriate emission factors for each fuel type to convert fuel consumption into greenhouse gas emissions.

The emissions are calculated using the formula:

–       GHG Emissions (tCO2e) = Fuel Consumption (in liters or cubic meters) × Emission Factor (kgCO2e/unit of fuel)

–       Emission factors are typically sourced from international organizations such as the Intergovernmental Panel on Climate Change (IPCC) or national environmental agencies.

d. Aggregate Total Emissions:

- Sum up the emissions from all identified nodes to calculate the total Scope 1 GHG emissions for the network.

3.   Formula for Scope 1 GHG Emissions

Total Scope 1 GHG Emissions (tCO2e) = Σ [Fuel Consumption (Node i) × Emission Factor (Fuel Type i)]

Where:

–       Fuel Consumption (Node i): The total quantity of fuel used by a specific validating node.

–       Emission Factor (Fuel Type i): The standard GHG emission factor for the specific fuel type used.

4.   Data Collection and Assumptions

–       Node Data Sources: Information about nodes and their energy sources can be obtained from network operators, blockchain-specific research, or external data providers.

–       Emission Factors: Use globally recognized emission factors, such as those provided by the IPCC or national energy agencies, to standardize calculations.

–       Assumptions: In cases where specific data is unavailable, assumptions based on typical node setups and industry averages may be applied. These assumptions must be clearly documented for transparency.

5.   Considerations for Blockchain-Specific Scope 1 Emissions

–       Decentralized Nodes: Decentralized networks may include geographically dispersed nodes with varying emission profiles. Averages or representative samples may need to be used in such cases.

–       Direct Emissions Contribution: For PoS networks, Scope 1 emissions are generally low compared to energy-intensive Proof of Work (PoW) networks, as the energy demands are significantly reduced.

–       Backup Power Sources: The prevalence of backup power sources (e.g. generators) in node infrastructure can contribute to Scope 1 emissions and should be included in calculations.

6.   Limitations

–       Data Availability: The decentralized nature of blockchain networks can make it challenging to obtain granular data on node-specific fuel usage and emissions.

–       Estimations: When direct data is unavailable, reliance on estimates may reduce precision.

A.5     Methodology for Scope 2 – Purchased GHG Emissions

1.    Overview

Scope 2 GHG emissions represent indirect greenhouse gas emissions resulting from the generation of electricity consumed by validating nodes in blockchain networks. These emissions are indirectly tied to network activities such as transaction validation and ledger maintenance.

The methodology for calculating Scope 2 emissions builds on data from energy consumption (Indicator 1) and the location-based energy mix (Indicator 2). It leverages two complementary reporting methods as defined by the GHG Protocol: the location-based method and the market-based method. For this methodology, the location-based method is applied due to the absence of specific contractual data on energy sourcing by validators.

2.   Steps for Calculating Scope 2 GHG Emissions

a.    Location-Based Method:

This method reflects the average emissions intensity of the electrical grids where energy consumption occurs.

Determine Total Electricity Consumption:

–       Use the total electricity consumption data obtained for each validating node from Indicator 1.

–       Group nodes by their geographical location to map their energy usage to specific regional grids.

Obtain Grid-Average Emission Factors:

–       Collect grid-average emission factors (e.g., kg CO2e per kWh) for each region where validators operate.

Data sources include state authorities or international agencies, such as:

–       United States Environmental Protection Agency (EPA) for U.S. states.

–       European Environment Agency (EEA) for European grids.

Calculate Emissions per Region:

–       Multiply the total electricity consumed in each region by the grid-average emission factor for that region.

Formula:

–       Scope 2 Emissions (per region) = Electricity Consumption × Grid-Average Emission Factor

Aggregate Total Scope 2 Emissions:

–       Sum emissions from all regions to determine the network-wide Scope 2 emissions.

b.   Market-Based Method (Optional):

This method accounts for emissions based on electricity contracts chosen by validators. It includes renewable energy certificates (RECs) or unbundled attribute claims.

Identify Contractual Data:

–       If validators provide data on specific energy contracts, use these to identify the energy source.

–       Include emission factors associated with the residual mix for electricity not covered by contracts meeting Scope 2 quality criteria.

Calculate Contract-Based Emissions:

–       Use the contractual emission factors to calculate emissions for the validated nodes.

Formula:

Scope 2 Emissions (per contract) = Electricity Consumption × Contractual Emission Factor

Combine with Residual Mix:

Add emissions for electricity not covered by contracts using the residual mix emission factors.

Note: In the absence of sufficient data on contractual energy sourcing, the market-based method is excluded, and only the location-based method is applied.

A.6     Methodology for GHG Intensity

1.    Overview

GHG intensity measures the average greenhouse gas emissions (Scope 1 and Scope 2) per validated transaction in blockchain networks. This indicator reflects the environmental impact of each transaction by combining direct emissions (Scope 1) and indirect emissions from purchased electricity (Scope 2). The methodology builds on the energy consumption and emissions data derived from Indicator 1 (Energy Consumption), Indicator 4 (Scope 1 GHG Emissions), and Indicator 5 (Scope 2 GHG Emissions).

2.   Steps for Calculating GHG Intensity

a.   Obtain Total GHG Emissions:

–       Use the combined total of Scope 1 and Scope 2 GHG emissions for the blockchain network over a given timeframe (e.g., one calendar year).

Formula:

Total GHG Emissions = Scope 1 Emissions + Scope 2 Emissions

b.   Count Validated Transactions:

–       Determine the total number of validated transactions on the network during the same timeframe.

–       Transaction data can typically be sourced from block explorers or other blockchain monitoring tools.

c.   Calculate GHG Intensity Per Transaction:

–       Divide the total GHG emissions by the total number of validated transactions.

Formula:

GHG Intensity (kg CO2e/transaction) = Total GHG Emissions (kg CO2e) ÷ Total Validated Transactions

3.   Formula for GHG Intensity

GHG Intensity (kg CO2e/transaction) = (Scope 1 Emissions + Scope 2 Emissions) ÷ Total Number of Validated Transactions

Where:

–       Scope 1 Emissions: Direct emissions from node-controlled activities (e.g., backup generators).

–       Scope 2 Emissions: Indirect emissions from purchased electricity used by nodes.

–       Total Validated Transactions: The total number of transactions validated over the same period.

4.   Data Sources

GHG Emissions Data:

–       Derived from Scope 1 and Scope 2 calculations in Indicators 4 and 5.

Transaction Data:

–       Collected from blockchain block explorers or network-specific data providers.

5.   Considerations for Blockchain-Specific GHG Intensity

PoS Networks:

–       Since transactions in Proof of Stake (PoS) systems represent a small portion of overall network energy consumption, the GHG intensity metric provides a fair estimate of the emissions impact per transaction.

Timeframe Alignment:

–       Ensure the timeframe for emissions data and transaction data matches (e.g., one calendar year).

Marginal Emissions:

–       Consider separating marginal GHG emissions caused directly by transactions from the base emissions required to maintain the ledger, if relevant.

6.   Limitations

Assumptions in Data Gaps:

–       In cases where granular data is unavailable, averages or assumptions may need to be used, which could affect precision.

Influence of Low Transaction Volumes:

–       Networks with low transaction throughput may exhibit higher GHG intensity per transaction due to fixed energy requirements for maintaining the ledger.

A.7     Methodology for Generation of Waste Electrical and Electronic Equipment (WEEE)

1.    Overview

The generation of WEEE captures the total amount of electrical and electronic equipment waste generated by validating nodes in the network. This waste arises from the replacement or disposal of hardware used for the validation of transactions and maintenance of the distributed ledger.

For blockchain networks, WEEE generation depends on the type of hardware used by validating nodes and the frequency of hardware replacement due to depreciation, performance decline, or operational requirements. This methodology applies a two-step approach to estimate the total WEEE generated.

2.   Steps for Calculating WEEE

a.   Understand Hardware Composition and Weight:

Identify Representative Hardware:

–       Use a reference hardware set to represent the typical devices used by validating nodes in the network. The reference set may include:

–       Low-power devices (e.g. Raspberry Pi).

–       Mid-tier devices (e.g. personal computers).

–       High-performance server-grade hardware.

Determine Hardware Weights and Network Share:

–       Obtain the weight of each hardware type and estimate their relative share in the network.

Formula:

WEEE Contribution (Device Type) = Weight of Device × Share of Network Using Device.

b.   Define the Depreciation Timeframe:

Set Depreciation Period:

–       For Proof of Stake (PoS) networks, assume a depreciation timeframe of three years for hardware. This reflects industry practices and ensures alignment with environmental sustainability benchmarks.

Calculate Daily or Annual WEEE Generation:

–       Use the total weight of devices in the network and divide by the depreciation period to estimate the amount of WEEE generated per day or year.

Formula:

WEEE (Tonnes) = Total Weight of Devices in Network ÷ Depreciation Timeframe (Years).

3.   Formula for Total WEEE Generation

Total WEEE (Tonnes per Year) = Σ [(Weight of Device × Share in Network) ÷ Depreciation Timeframe]

Where:

–       Weight of Device: Physical weight of each hardware type used in the network.

–       Share in Network: Percentage of validating nodes using a specific hardware type.

–       Depreciation Timeframe: Assumed to be three years for PoS networks.

4.   Data Collection and Assumptions

Hardware Data:

–       Obtain hardware specifications and weights from manufacturers or technical documentation.

–       Use network statistics or external data providers to estimate the share of hardware types used in the network.

Depreciation Period:

–       Assumed to be three years, based on average hardware lifespans in PoS networks.

Assumptions for Missing Data:

–       If detailed network hardware data is unavailable, use averages from similar networks or industry benchmarks.

5.   Considerations for Blockchain-Specific WEEE Generation

PoS Networks:

–       Hardware in PoS networks typically experiences slower depreciation compared to PoW networks due to lower energy and computational demands.

Device Upgrades and Replacements:

–       WEEE generation increases if node operators frequently upgrade hardware to improve performance or adapt to new network requirements.

Environmental Impact:

–       Proper recycling and disposal practices can mitigate the environmental harm associated with WEEE generation.

6.   Limitations

Data Availability:

–       Detailed information on hardware usage and replacement rates may not always be accessible for decentralized networks.

Estimation Variability:

–       Assumptions about depreciation periods and hardware composition may introduce variability in WEEE estimates.

A.8     Methodology for Non-Recycled WEEE Ratio

1.    Overview

The non-recycled WEEE ratio measures the percentage of electrical and WEEE generated by validating nodes that is not recycled per calendar year. This indicator reflects the environmental inefficiency in recycling practices and the potential contribution to electronic waste pollution.

The calculation requires information on the total WEEE generated (Indicator 7) and the recycling rates for WEEE in the locations where validators operate.

2.   Steps for Calculating the Non-Recycled WEEE Ratio

a.    Calculate Total WEEE Generated:

–       Use the methodology from Indicator 7 to estimate the total WEEE generated for the network over the calendar year.

b.   Determine Local Recycling Rates:

–       Identify the geographical locations of validating nodes (as outlined in Indicator 2).

–       Obtain local recycling rates for WEEE from authoritative sources such as:

–       National or regional environmental agencies.

–       Global organizations like UNITAR, UNU-ViE Sustainable Cycles (SCYCLE), or the International Telecommunication Union (ITU).

–       Published reports on e-waste production and recycling statistics.

c.    Estimate Recycled WEEE:

–       Multiply the total WEEE generated in each location by the local recycling rate to estimate the amount of WEEE recycled.

Formula:

Recycled WEEE (per location) = Total WEEE × Local Recycling Rate

d.   Calculate Non-Recycled WEEE:

–       Subtract the recycled WEEE from the total WEEE generated to estimate the non-recycled portion.

Formula:

Non-Recycled WEEE (per location) = Total WEEE - Recycled WEEE

e.    Determine the Non-Recycled WEEE Ratio:

–       Divide the total non-recycled WEEE by the total WEEE generated across all locations.

Formula:

Non-Recycled WEEE Ratio (%) = (Total Non-Recycled WEEE ÷ Total WEEE Generated) × 100

3.   Formula for Non-Recycled WEEE Ratio

Non-Recycled WEEE Ratio (%) = [(Total WEEE - Recycled WEEE) ÷ Total WEEE] × 100

Where:

–       Total WEEE: Calculated using Indicator 7.

–       Recycled WEEE: Derived from local recycling rates applied to the total WEEE generated.

4.   Data Collection and Assumptions

Recycling Rates:

–       Sourced from state or regional authorities and global organizations specializing in e-waste monitoring.

–       If specific data is unavailable, use regional or global averages for recycling rates.

Validator Location Data:

–       Obtained from Indicator 2 to map validator locations to regional recycling rates.

Assumptions:

–       In the absence of specific location data, apply average recycling rates based on the global or regional context.

5.   Considerations for Blockchain-Specific WEEE Recycling

Decentralized Networks:

–       Validator nodes may be geographically dispersed, requiring a weighted average of recycling rates across multiple regions.

WEEE Recycling Infrastructure:

–       The effectiveness of WEEE recycling depends on the availability and efficiency of local recycling infrastructure, which can vary significantly between countries or regions.

6.   Limitations

Data Gaps:

–       The availability of precise recycling rates for all validator locations may be limited, requiring reliance on approximations or averages.

Assumption of Recycling Practices:

–       Local recycling rates may not accurately reflect the practices of individual node operators, introducing variability in estimates.

A.9     Methodology for Generation of Hazardous Waste

1.    Overview

The generation of hazardous waste measures the amount of waste containing hazardous substances resulting from the disposal of electronic and electrical equipment used by validating nodes in blockchain networks. This indicator builds upon the total WEEE calculated in Indicator 7 and estimates the hazardous component as a share of the total WEEE, expressed in tonnes per year.

Hazardous waste is defined in accordance with the European Union Waste Electrical and Electronic Equipment Directive (WEEE Directive) (2012/19/EU) and the Restriction of Hazardous Substances Directive (RoHS 2) (2011/65/EU), which identify hazardous substances such as lead, mercury, cadmium, and others within electronic devices.

2.   Steps for Calculating Hazardous Waste

a.    Calculate Total WEEE:

–       Use the methodology from Indicator 7 to determine the total WEEE generated by the network for the calendar year.

b.   Identify Hazardous Components in WEEE:

–       Use vendor-specific Restriction of Hazardous Substances (RoHS) Reports to determine the share of hazardous substances in the electronic devices used as validating node hardware.

–       Hazardous substances may include materials such as:

            •           Lead (Pb).

            •           Mercury (Hg).

            •           Cadmium (Cd).

            •           Hexavalent chromium (Cr6+).

            •           Polybrominated biphenyls (PBBs).

            •           Polybrominated diphenyl ethers (PBDEs).

c.    Calculate Hazardous Waste Share:

–       Multiply the total WEEE by the percentage of hazardous components identified in the RoHS reports.

Formula:

–       Hazardous Waste (tonnes) = Total WEEE × Hazardous Component Share

d.   Aggregate Hazardous Waste Across Hardware Types:

–       Repeat the calculation for each hardware type in the network and sum the results to estimate the total hazardous waste generated.

3.   Formula for Hazardous Waste Generation

Total Hazardous Waste (tonnes per year) = Σ (Total WEEE × Hazardous Component Share for each hardware type)

Where:

–       Total WEEE: Calculated in Indicator 7.

–       Hazardous Component Share: Percentage of hazardous substances in each hardware type, derived from RoHS reports or similar data sources.

4.   Data Collection and Assumptions

RoHS Reports:

–       These are vendor-provided documents that disclose the hazardous material content of electronic devices.

–       Use these reports for each hardware type employed in the network.

–       Device-Specific Data:

–       Gather information on the hardware types used by validating nodes, including their WEEE contribution and hazardous material composition.

–       Assumptions for Missing Data:

–       If vendor-specific RoHS reports are unavailable, use average hazardous waste shares based on industry benchmarks or similar devices.

5.   Considerations for Blockchain-Specific Hazardous Waste

PoS Networks:

–       As Proof of Stake (PoS) networks use less energy-intensive and often smaller-scale hardware, the hazardous waste component is typically lower compared to Proof of Work (PoW) networks.

Lifecycle and Replacement:

–       The hazardous waste generation rate depends on hardware depreciation and replacement cycles. A three-year depreciation period is assumed for most hardware, as described in Indicator 7.

Impact of Recycling Practices:

–       Proper recycling practices can mitigate the environmental harm caused by hazardous waste, emphasizing the importance of robust WEEE recycling infrastructure.

6.   Limitations

Data Gaps:

–       Availability of RoHS reports or hazardous material composition for all hardware types may vary, requiring reliance on estimates or benchmarks.

Geographical Variation:

–       Recycling rates and hazardous material handling practices differ by region, affecting the accuracy of hazardous waste calculations.

A.10   Methodology for Impact of the Use of Equipment on Natural Resources

1.    Overview

This indicator addresses the lifecycle impact of devices used by validating nodes in blockchain networks on natural resources, encompassing production, use, and disposal phases. Unlike the specific quantitative metrics outlined in other indicators, this indicator currently calls for a qualitative description of impacts, with potential for further definition as regulatory requirements evolve.

The lifecycle assessment considers impacts on natural resources such as water, fossil fuels, and critical raw materials during three distinct phases:

–       Production phase: Extraction and processing of raw materials for hardware manufacturing.

–       Use phase: Energy and water consumption during hardware operation.

–       Disposal phase: Resource losses and potential environmental harm from improper recycling or disposal.

2.   Steps for Assessing the Impact on Natural Resources

a.    Production Phase:

Identify Materials Used in Hardware:

–       Analyze the hardware composition of validating nodes to identify critical raw materials (e.g. cobalt, lithium, rare earth metals).

–       Use manufacturer-provided data or lifecycle assessment (LCA) databases to estimate the resource intensity of device production.

Estimate Resource Extraction Impacts:

–       Evaluate the environmental impacts of mining and processing raw materials, such as land degradation, fossil fuel use, and greenhouse gas emissions.

–       Reference global LCA studies and industry benchmarks for resource-intensive components like batteries or chips.

b.   Use Phase:

Energy Consumption and Water Footprint:

–       Link the energy consumption data (Indicator 1) to the regional water intensity of electricity generation.

–       Example: Regions relying on thermoelectric power plants may have a higher water footprint compared to renewable energy sources like wind or solar.

Assessment Approach:

–       Utilize regional electricity water footprint databases to calculate water consumption associated with validator energy use.

–       Factor in cooling water needs for server-grade hardware where applicable.

Raw Material Depletion During Use:

–       Evaluate resource depletion during operations, such as wear-and-tear on components requiring replacement (e.g. storage media or batteries).

c.    Disposal Phase:

Recycling and Resource Recovery:

–       Assess the recovery rates of critical raw materials through recycling processes, using data from Indicator 8 (Non-Recycled WEEE Ratio).

Environmental Harm from Improper Disposal:

–       Highlight the loss of recoverable materials and environmental impacts from landfilling or incineration of e-waste.

3.   Lifecycle Assessment Framework

Water Consumption:

–       Use phase water impacts are calculated by linking validator energy use to regional electricity water footprints.

Fossil Fuel Use:

–       Production phase impacts on fossil fuels include resource extraction for hardware manufacturing.

–       Use phase impacts are derived from non-renewable energy sources identified in Indicator 2 (Energy Mix).

Critical Raw Materials:

–       Assess resource usage across all lifecycle phases, focusing on non-renewable and environmentally intensive materials like rare earth metals and lithium.

4.   Data Collection and Assumptions

Production Data:

–       Use manufacturer reports or global lifecycle databases for material usage and resource impacts.

Regional Energy and Water Data:

–       Obtain electricity water footprint and non-renewable energy mix data for validator locations.

–       Sources include regional environmental agencies or global research databases.

Assumptions for Missing Data:

–       When data is unavailable, use industry averages or benchmarks from comparable devices and regions.

5.   Limitations

Qualitative Nature:

–       Current regulatory guidance for this indicator emphasizes qualitative descriptions rather than specific metrics, making direct comparisons difficult.

Data Gaps:

–       Comprehensive data on resource usage across all lifecycle phases may not be consistently available, requiring reliance on averages or secondary sources.

6. Potential Future Developments

This indicator may evolve into a more quantitatively defined metric as regulatory bodies, such as ESMA, release updated requirements. Researchers and organizations should monitor developments to ensure compliance with emerging standards.

B.        Additional climate and other environment-related indicators

C.        calculating the climate indicators

First Set of Sustainability Indicators

Second Set of Sustainability Indicators