W3.io
MiCAR Crypto-Asset White Paper
984500DCCFAAEC0AEC24 2026-01-01 2026-12-31

Table of Contents

General Information
00: Table of content
true
01: Date of notification

2026-07-15

02: Statement in accordance with Article 6(3) of Regulation (EU) 2023/1114

This crypto-asset white paper has not been approved by any competent authority in any Member State of the European Union. The person seeking admission to trading of the crypto-asset is solely responsible for the content of this crypto-asset white paper.

03: Compliance statement in accordance with Article 6(6) of Regulation (EU) 2023/1114

This crypto-asset white paper complies with Title II of Regulation (EU) 2023/1114 of the European Parliament and of the Council and, to the best of the knowledge of the management body, the information presented in the crypto-asset white paper is fair, clear and not misleading and the crypto-asset white paper makes no omission likely to affect its import.

04: Statement in accordance with Article 6(5), points (a), (b), (c), of Regulation (EU) 2023/1114

The crypto-asset referred to in this crypto-asset white paper may lose its value in part or in full, may not always be transferable and may not be liquid.

05: Statement in accordance with Article 6(5), point (d), of Regulation (EU) 2023/1114

false

06: Statement in accordance with Article 6(5), points (e) and (f), of Regulation (EU) 2023/1114

The crypto-asset referred to in this white paper is not covered by the investor compensation schemes under Directive 97/9/EC of the European Parliament and of the Council or the deposit guarantee schemes under Directive 2014/49/EU of the European Parliament and of the Council.

SUMMARY
07: Warning in accordance with Article 6(7), second subparagraph, of Regulation (EU) 2023/1114

Warning

This summary should be read as an introduction to the crypto-asset white paper. The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone. The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law. This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

08: Characteristics of the crypto-asset

GDP is the native utility and governance token of the W3 ecosystem, an ERC-20 token on the Avalanche L1 that functions as the economic coordination layer for the network. The token does not represent equity, debt, dividends, or ownership in any legal entity, and does not confer financial returns or claims on any pool of assets. GDP has a hard cap of 1,000,000,000 tokens with no inflation or minting beyond this cap, and an expected initial circulating supply of approximately 16.5% at TGE.

Core Token Benefits:

Governance Rights: Token holders submit and vote on Governance Improvement Proposals (GIPs) covering protocol parameters, fee structures, network contribution reward rates, treasury allocations, and new module integrations. Proposals require a 66% supermajority of participating holders to pass.

Fee Discounts: Holders receive reduced execution and settlement fees when paying for W3 services with GDP tokens.

Access, Collateral, and Staking Functions (Requiring Additional Holder Action):

Network Participation Collateral: Participants must post and lock GDP tokens in on-chain escrow contracts to activate subnets (Knights), deploy applications (Solution Builders), and unlock conversion reward eligibility (Sales Teams) for the duration of participation.

Passive Staking: Token holders may elect to participate in an optional staking program to earn network contribution rewards funded from a pre-allocated Ecosystem & Community reserve rather than new token issuance. This passive staking is separate from the collateral requirement and is not mandatory for network participation.

09: Further information about utility tokens

Not applicable as GDP is not a utility token as defined under MiCA.

10: Key information about the offer to the public or admission to trading

This white paper has been prepared for the purposes of seeking admission to trading on multiple crypto-asset trading platforms. The Issuer seeks to ensure broad accessibility for the GDP token by pursuing admission to trading across suitable venues.

Part A - Information about the Offeror or the Person Seeking Admission to Trading
A.1: Name

GDP Sup Corp

A.2: Legal form

A company limited by shares

A.3: Registered address

Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands

A.4: Head office

Trinity Chambers, PO Box 4301, Road Town, Tortola, British Virgin Islands

A.5: Registration date

2026-05-26

A.6: Legal entity identifier

984500DCCFAAEC0AEC24

A.7: Another identifier required pursuant to applicable national law

2209825

A.8: Contact telephone number

914-924-7573

A.9: E-mail address

team@w3.io

A.10: Response time (days)

001

A.11: Parent company

Hi Science, Inc.

A.12: Members of management body

1
David Post
United States
Director

2
Benjamin Murray
United States
Director

3
Audie Sheridan
United States
Director

A.13: Business activity

GDP Sup Corp is a British Virgin Islands (BVI) business company that serves as the dedicated token issuance entity for the ecosystem. Its principal business activities include the minting and issuance of the GDP token.

A.14: Parent company business activity

The parent company develops and commercializes an enterprise-grade programmable finance execution layer (including W3 Core, VaultOS, and W3 Cloud) that enables enterprises, developers, and AI agents to compose and execute verifiable financial workflows across Web2 and Web3 infrastructure. It targets high‑value markets such as programmable payments and donations, treasury management and yield infrastructure, tokenized real‑world assets, decentralized cloud storage and compute, creator‑economy infrastructure, AI‑native financial workflows, and enterprise compliance and interoperability solutions.

A.15: Newly established

true

A.16: Financial condition for the past three years

Not applicable as the offeror or person seeking admission to trading was established within the past three years.

A.17: Financial condition since registration

The person seeking admission to trading for GDP is a newly formed BVI company that has been incorporated on May 26, 2026, and therefore has existed for less than three years, with no standalone audited historical financial statements yet available. Its financial position is underpinned at group level by approximately $7 million of capital raised across three rounds (Pre-Seed $2.6m, Seed $3.1m, Strategic $1.3m), with no additional capital raises planned in the next six months and stated runway sufficient to fund operations through March 2027, indicating adequate near‑term liquidity and capital resources for development and launch activities. Development and performance indicators are primarily qualitative at this stage: the business is focused on building programmable financial infrastructure and a “recipes” model for enterprise workflows, where infrastructure providers supply modular components (“Ingredients”), developers assemble them into automated workflows (“Recipes”), and enterprises deploy end‑to‑end “Solutions,” which is expected to drive usage growth as more enterprise clients, infrastructure partners, and developers onboard. Key financial KPIs are therefore forward‑looking rather than historical and are tied to scaling enterprise workflow execution, transaction processing, assets under management in VaultOS yield vaults, decentralized compute and storage utilization, and ecosystem commercial agreements, with revenue generated via gross‑margin fees on workflow value, fees on vault AUM, and infrastructure usage; specific numerical KPIs have not yet been disclosed.

Part B - Information about the Issuer, If Different from the Offeror or Person Seeking Admission to Trading
B.1: Issuer different from offerror or person seeking admission to trading

false

B.2: Name
B.3: Legal form
B.4: Registered address
B.5: Head office
B.6: Registration date
B.7: Legal entity identifier
B.8: Another identifier required pursuant to applicable national law
B.9: Parent company
B.10: Members of management body
B.11: Business activity
B.12: Parent company business activity
Part C - Information about the Operator of the Trading Platform
C.1: Name
C.2: Legal form
C.3: Registered address
C.4: Head office
C.5: Registration date
C.6: Legal entity identifier
C.7: Another identifier required pursuant to applicable national law
C.8: Parent company
C.9: Reason for crypto-asset white paper preparation
C.10: Members of management body
C.11: Operator business activity
C.12: Parent company business activity
C.13: Other persons drawing up the crypto-asset white paper according to Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
C.14: Reason for drawing the white paper by persons referred to in Article 6(1), second subparagraph, of Regulation (EU) 2023/1114
Part D - Information about the Crypto-Asset Project
D.1: Crypto-asset project name

W3

D.2: Crypto-asset name

GDP

D.3: Abbreviation

GDP

D.4: Crypto-asset project description

Project Description:
W3.io is a programmable finance execution layer that enables enterprises, developers, and AI agents to compose, execute, and manage verifiable financial workflows across Web2 systems, Web3 infrastructure, and over 50 pre-integrated vendors through a single platform. The protocol abstracts complex infrastructure into reusable templates and modules deployable via native MCP support and GitHub Actions syntax, allowing multi-vendor financial workflows to be assembled in hours, executed off-chain at enterprise throughput, and settled on-chain. Operating beyond experimentation, the platform processes over 200,000 workflows per day on TestNet across five active verticals (Donations, Private Credit, Private Wealth, Media & Entertainment, and the Creator Economy) and is architected around three core products: Compose (building workflows), Control (running and governing them), and Consume (distributing solutions to end users).

Purpose and Goals:
GDP is an ERC-20 utility and governance token on the Avalanche L1 designed as the economic coordination layer of a programmable finance ecosystem, aligning infrastructure providers, enterprises, developers, operators, and users around network growth and security. It tightly couples token demand with real workflow execution across payments, RWAs, treasury management, storage, compute, and AI-driven systems so that utility and demand scale alongside actual transaction and enterprise usage rather than speculation.

Key Features and Operation:

Native Token Properties: Fixed maximum supply hard-capped at 1,000,000,000 GDP tokens with no inflation mechanism, no inflationary block rewards, and no conditions under which new tokens may be minted. Initial circulating supply at TGE is targeted at approximately 16.5% of the total supply, originating exclusively from the Ecosystem & Community allocation, meaning zero insider or team tokens enter circulation during the first 12 months.

Governance Rights: Token holders submit and vote on Governance Improvement Proposals (GIPs) covering protocol parameters, fee structures, network contribution reward rates, treasury allocations, and new module integrations, requiring a 66% supermajority of participating holders to pass. During the initial post-TGE phase, the core team retains a narrowly scoped administrative veto for compliance and security that automatically expires within 24 months or upon achieving decentralization milestones.

Fee Discounts: Holders receive reduced execution and settlement fees when paying for W3 ecosystem services with GDP tokens.

Network Participation and Collateral Functions (Requiring Additional Holder Action):

Network Participation Collateral: Participants must post and lock GDP tokens in on-chain escrow contracts to activate subnets (Knights), deploy applications (Solution Builders), and unlock conversion reward eligibility (Sales Teams) for the duration of participation. This collateral is subject to programmatic slashing for non-performance or compliance failures. When operators are penalized, forfeited collateral is redistributed to remaining active participants through a closed-loop supply reduction mechanism.

Workflow Execution: Developers, infrastructure providers, and enterprises must stake or lock GDP to access workflows and execution resources, integrating directly into the programmable finance stack. Demand for this collateral scales structurally and reflexively with ecosystem growth, as every new vendor and client deployment increases the required collateral across the network.

Passive Staking: Token holders may elect to participate in an optional staking program to earn network contribution rewards funded from a pre-allocated Ecosystem & Community reserve based on activity and usage, rather than passive token holding. This program removes additional supply from active circulation.

Protocol Revenue Participation: When activated via the on-chain governance framework and subject to full regulatory review, a protocol revenue-funded buyback mechanism or a system directing a portion of protocol fees generated by enterprise workflow volume to participating token holders can be implemented.

D.5: Details of all natural or legal persons involved in implementation of crypto-asset project

1

Development team, Porter Stowell

2
Development team, Audie Sheridan

3
Development team, Chad Itskowitz

4
Development team, Cory Gabrielsen

5
Development team, David Post

6
Development team, Benjamin Murray

7
Development team, Robbert van Renesse

8

Advisor, Adeline Zhou

9
Advisor, Nate Holiday

10
Advisor, Devon Ferreira

11
Advisor, Shyam Nagarajan

D.6: Utility token classification

false

D.7: Key features of goods or services for utility token projects
D.8: Plans for the token

W3.io operates as a programmable finance execution layer that enables enterprises, developers, and AI agents to compose, execute, and manage verifiable financial workflows across Web2 systems, Web3 infrastructure, and over 50 pre-integrated infrastructure vendors through a single platform. The architecture abstracts technical infrastructure complexity into reusable templates and workflow modules deployable via native MCP support and GitHub Actions syntax. The GDP token is designed as the protocol's native access, coordination, and collateral layer. Intrinsic token benefits include access to integrated fee discounts on ecosystem services and native on-chain governance rights. Functions requiring separate actions by holders include posting GDP tokens into on-chain escrow contracts to activate subnets, deploying applications, entering operational participation tiers, or voluntarily engaging in the optional passive staking program.

The platform is currently in its TestNet phase, processing over 200,000 workflows per day across five active verticals: Donations, Private Credit, Private Wealth, Media & Entertainment, and the Creator Economy. It maintains a network of 300+ active node operators and has secured line of sight to over $2B in transaction volume over the next 12 months, supported by signed and late-stage enterprise opportunities.

Planned milestones (future):

June 2026 - Pre‑TGE growth and distribution design: Active onboarding of final pre-launch infrastructure partners targeting 100+ Tier-1 vendors by end of year; calibration of KYC-compliant community distribution frameworks; scaling of three initial distribution partners to validate post-launch selling motions.

August 2026 - Public Platform Release: Public release of the "Compose" product module, opening self-service platform access for outside builders to create and publish financial recipes, initiating tracked developer adoption metrics. September 3rd, 2026 - Token Generation Event (TGE): Initial GDP token launch with ~16.5% of the 1,000,000,000 fixed maximum supply entering circulation, originating exclusively from the Ecosystem and Community allocation (encompassing public TGE participants, liquidity provisioning, and a small operational reserve). Launch of immediate intrinsic token features, including fee discounts and on-chain voting rights. All Team (20%) and Investor (14%) allocations enter a strict 12-month cliff with zero insider tokens unlocked at launch.

Fall/Late 2026 - Mainnet & Core Product Expansion: Full activation of extrinsic network participation functionalities, including mandatory on-chain collateral lockups for subnets ("Knights"), application deployment ("Solution Builders"), and sales onboarding. Public rollout of the remaining "Control" and "Consume" operational platform modules.

September 2027 (12 Months Post-TGE): Expiration of the 12-month insider cliff. Team and Investor allocations commence a 36-month linear monthly vest (~9.4M tokens combined per month), while the remaining Ecosystem and Community allocation continues its programmatic 48-month linear monthly unlock schedule (~10.3M tokens per month).

D.9: Resource allocation

Financial resources / funding raised

~$7M raised across three rounds: Pre-Seed 2024 ($2.6M), Seed 2025 ($3.1M), Strategic 2025 ($1.3M).

Runway currently sufficient for operations through March 2027.

TGE proceeds planned for protocol engineering/audits, market making and liquidity, foundation setup (Cayman-based GDP Foundation), ecosystem grants, and marketing/enterprise client acquisition.

Human resources / team

Core team, engineering, research, and operations operations are managed under Hi Science, Inc.

The organizational structure is scaling three active distribution partners pre-TGE to manage the post-launch global selling motion and client origination.

Technological resources / technology developed

Network is in advanced pre-mainnet stage with live infrastructure processing 200,000+ verifiable workflows per day on TestNet across five active verticals: Donations, Private Credit, Private Wealth, Media & Entertainment, and the Creator Economy.

Core product architecture developed across three distinct layers: Compose (workflow builder active on TestNet), Control (governance/execution framework), and Consume (distribution gateway), with native MCP support and GitHub Actions syntax.

50+ pre-integrated ingredient partners across payments, custody, compliance, identity, data, storage, compute, yield, and interoperability (including live integrations with Stripe, PayPal, BitGo, Privy, Circle, WisdomTree, OpenTrade, Franklin Templeton, Inca Digital, x402, Chainlink, and Morpho) already utilized for workflow composition.

300+ active node operators currently running infrastructure and supporting network operations ahead of mainnet, alongside a public Dune Dashboard tracking protocol metrics transparently.

D.10: Planned use of collected funds or other tokens

Planned use of funds and crypto-assets focuses on protocol engineering and completion of security audits, market-making and liquidity provisioning around the token generation event, establishment and operation of a foundation as custodian of the treasury, ecosystem and community incentives (including airdrops, grants, marketing campaigns, and strategic partnerships to drive product adoption), and marketing and enterprise client acquisition.

Part E - Information about the Offer to the Public of Crypto-Assets or their Admission to Trading
E.1: Public offering or admission to trading

ATTR

E.2: Reasons for public offer or admission to trading

Enable EU market access for GDP holders.

E.3: Fundraising target

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.4: Minimum subscription goals

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.5: Maximum subscription goals

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.6: Oversubscription acceptance

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.7: Oversubscription allocation

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.8: Issue price

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.9: Official currency determining issue price

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.10: Subscription fee

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.11: Offer price determination method

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.12: Total number of offered or traded other tokens

1,000,000,000

E.13: Targeted holders

All

E.14: Holder restrictions

There are no restrictions.

E.15: Reimbursement notice

There are no reimbursement rights.

E.16: Refund mechanism

There is no refund mechanism.

E.17: Refund timeline

There is no refund mechanism.

E.18: Offer phases

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.19: Early purchase discount

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.20: Time-limited offer

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.21: Subscription period beginning

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.22: Subscription period end

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.23: Safeguarding arrangements for offered funds or other tokens

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.24: Payment methods for other token purchase

Fiat or other crypto-assets.

E.25: Value transfer methods for reimbursement

There are no reimbursement rights.

E.26: Right of withdrawal

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.27: Transfer of purchased other tokens

Via crypto-asset trading platforms on which GDP is admitted to trading.

E.28: Transfer time schedule

There is no relevant time schedule.

E.29: Purchaser's technical requirements

There are no technical requirements.

E.30: Other token service provider (CASP) name

Not applicable.

E.31: CASP identifier

Not applicable.

E.32: Placement form

NTAV

E.33: Trading platforms name
E.34: Trading platforms market identifier code (MIC)
E.35: Trading platforms access

Online via the platform.

E.36: Involved costs

Not applicable.

E.37: Offer expenses

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.38: Conflicts of interest

The issuer is not aware of any potential conflict of interest of the persons involved in its admission to trading.

E.39: Applicable law

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

E.40: Competent court

British Virgin Islands

Part F - Information about the Crypto-Assets
F.1: Other token type

The Token is a crypto-asset under Regulation (EU) 2023/1114 of the European Parliament and of the Council which is not an e-money token, an asset-referenced token or a utility token, each as defined under such Regulation. Therefore, it falls in the "Other" category.

F.2: Other token functionality

Intrinsic Token Benefits (Arising directly from holding the token):

Governance rights: Token holders may submit and vote on Governance Improvement Proposals (GIPs) covering protocol parameters, fee structures, network contribution reward rates, treasury allocations, and new module integrations. Proposals require a 66% supermajority of participating token holders to pass, subject to a time-limited compliance/security veto by the core team during the initial 24 months.

Fee discounts: Reduced execution and settlement fees when paying for W3 services with GDP tokens.

No equity or cash‑flow rights: The token does not represent equity, debt, dividends, or ownership in any legal entity, and does not confer financial returns or claims on any pool of assets. (Potential future protocol revenue participation features, such as buybacks or fee-sharing, can only be activated via full governance and regulatory clearance).

Functions Requiring Additional Action (Extrinsically tied to active network participation):

Network participation collateral: Participants must post and lock GDP tokens in on-chain escrow contracts to activate subnets (Knights), deploy applications (Solution Builders), and unlock conversion reward eligibility (Sales Teams) for the duration of participation. Collateral is subject to programmatic slashing for non-performance or compliance failures, with forfeited tokens redistributed to remaining active participants.

Passive staking: Token holders may elect to participate in an optional staking program to earn network contribution rewards funded from a pre-allocated Ecosystem & Community reserve rather than new token issuance, removing additional liquid supply from active circulation.

Access to workflows and resources: Required to stake or lock the token to access programmable financial workflows, execution resources, and integration into the broader ecosystem. Required collateral scales reflexively with network growth, as each new vendor and enterprise deployment increases the value and resource requirement of access.

Activity‑based rewards: Participants can earn rewards based on activity, usage, and contribution to the network rather than passive token holding, with emissions structurally capped to prevent network inflation.

F.3: Planned application of functionalities

The GDP token's functionalities are planned to activate in stages, anchored to the Token Generation Event (TGE) scheduled for 27 July 2026.

At TGE (03 September 2026): GDP is created and initial circulation begins from the Ecosystem and Community allocation. Approximately 16.5% of total supply is unlocked and becomes transferable, originating exclusively from ecosystem and community pools (including public TGE participants, approved airdrops, liquidity provisioning, and a small Foundation operating reserve). No Team or Investor tokens unlock at TGE. From this point, core token benefits apply directly to holders: GDP can be held, transferred, traded on venues where it is admitted to trading, used to access available fee discounts on W3 services, and utilized for intrinsic on-chain governance rights to vote on Governance Improvement Proposals (subject to a time-limited 24-month administrative compliance/security veto by the core team).

From TGE onward: the remaining portion of the Ecosystem and Community allocation vests programmatically and linearly each month over 48 months (~10.3M tokens per month), enforced on-chain via audited smart contracts.

At mainnet launch (Q4 2026): separate functions and utilities that require additional actions by holders activate across the platform's product layers (Compose, Control, Consume). This includes active network functions such as use as access and collateral (locking GDP in on-chain escrow to activate subnets/"Knights", deploy applications via "Solution Builders", and unlock revenue/conversion reward eligibility for "Sales Teams"), as well as entering staking and participation tiers to earn activity-based network contribution rewards subject to programmatic slashing controls.

From September 2027 (12 months after TGE): the cliff on the Team (20%) and Investor (14%) allocations ends, and those allocations begin vesting linearly each month over the following 36 months (~9.4M tokens combined per month), ensuring zero insider selling pressure during the first year.

Around September 2030 (approximately 48 months after TGE): vesting completes for all allocations, being the Ecosystem and Community allocation over 48 months and the Team and Investor allocations over a 12-month cliff plus a 36-month vest, maintaining a strict hard cap of 1,000,000,000 GDP tokens with no unilateral ability for any party to accelerate unlocks or override parameters.

F.4: Type of crypto-asset white paper

OTHR

F.5: Type of submission

NEWT

F.6: Other token characteristics

GDP is a fixed-supply utility and governance token on the Avalanche L1, with a hard cap of 1,000,000,000 tokens and no inflation or minting beyond this cap. The token's characteristics and functionalities are structured based on whether they represent intrinsic benefits of the token itself or functions that require separate actions by the holders:

Intrinsic Token Characteristics & Benefits:

Core Benefits: Holding GDP tokens directly grants access to available fee discounts on W3 ecosystem services and intrinsic governance rights, allowing holders to submit and vote on Governance Improvement Proposals (GIPs) regarding protocol parameters, fee structures, and network integrations.

Supply Structure: Initial circulating supply at TGE is drawn exclusively from ecosystem and community allocations. The asset does not represent equity, debt, dividends, or ownership in any legal entity, and does not confer financial returns or claims on any pool of assets.

Functions Requiring Additional Holder Action:

Network Collaboration & Collateral: To participate directly in network infrastructure, participants must actively post and lock GDP tokens in on-chain escrow to activate subnets, deploy applications, and unlock revenue or conversion reward eligibility.

Staking and Rewards: Holders may voluntarily choose to participate in an optional staking program to earn network contribution rewards funded from a pre-allocated reserve based on active network contribution, rather than passive holding.

Compliance and Oversight Posture:

Regulatory Controls: All token distributions and validator onboarding are intended to be KYC/AML-gated with sanctions screening, geographic restrictions for certain jurisdictions, and transaction monitoring.

Governance Oversight: Operations are overseen initially alongside a Cayman-based GDP Foundation, utilizing a governance framework that includes a time-limited security and compliance veto by the core team to safeguard the network during its initial phases.

F.7: Commercial name or trading name

W3

F.8: Website of the issuer

https://w3.io/

F.9: Starting date of offer to the public or admission to trading

2026-08-12

F.10: Publication date

2026-08-12

F.11: Any other services provided by the issuer

Nothing other than already stated in the white paper.

F.12: Language or languages of white paper

English.

F.13: Digital token identifier code used to uniquely identify the crypto-asset or each of the several crypto assets to which the white paper relates, where available

RMTG1K0L0

F.14: Functionally fungible group digital token identifier, where available

F0Z4DG05W

F.15: Voluntary data flag

false

F.16: Personal data flag

true

F.17: LEI eligibility

true

F.18: Home member state

Ireland

F.19: Host member states

Austria, Belgium, Bulgaria, Croatia, Republic of Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, Italy, Latvia, Liechtenstein, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden.

Part G - Information on the Rights and Obligations attached to the Crypto-Assets
G.1: Purchaser rights and obligations

Intrinsic Purchaser Rights (Arising directly from holding the token):

Governance rights: Eligible token holders possess the right to participate in on-chain governance by submitting and voting on Governance Improvement Proposals (GIPs) covering protocol parameters, fee structures, network contribution reward rates, treasury allocations, and new module integrations. Proposals require a 66% supermajority of participating token holders to pass, subject to a time-limited security and compliance veto retained by the core team during the initial phases.

Fee discounts: Token holders have the right to access reduced execution and settlement fees when paying for W3 services with GDP tokens.

No structural financial claims: Purchasers do not receive equity, debt, dividends, or ownership in any legal entity. The token does not confer financial returns, passive cash-flow rights, or legal claims on any underlying pool of assets.

Purchaser Obligations:

Functional compliance: There are no financial obligations to contribute capital or provide ongoing funding beyond the initial purchase price required to acquire the asset.

Separation of operational tasks: There are no mandatory operational obligations imposed on mere holders of the token. Any separate actions - such as posting collateral to activate subnets, deploying applications, or locking tokens to access specific participation tiers - are strictly voluntary, optional activities required only for users choosing to operate as functional service providers within the network layer.

G.2: Exercise of rights and obligations
  1. KYC/AML onboarding (Precondition for exercising rights)
    All token distribution at or after TGE requires identity verification through the designated third-party KYC provider plus OFAC sanctions and AML screening. Restricted-jurisdiction users (including US residents without an applicable exemption, OFAC-sanctioned, and other restricted regions) are excluded from purchase and platform access. Only a wallet that has cleared compliance checks can hold, transfer, or transact with the token, and on-chain activity remains subject to ongoing monitoring.

  2. Fee Discounts on Services
    To exercise the right to fee discounts, holders must connect a compliant, KYC-cleared wallet to the W3 platform interfaces when paying for ecosystem services. When transaction, execution, or settlement fees are processed and paid using GDP tokens, the integrated discount is applied automatically at the point of execution.

  3. Governance (GIPs: Submitting and Voting)
    Holders meeting the minimum token threshold may exercise their voting rights by interacting with the official on-chain governance interface. Eligible holders vote "For" or "Against" on Governance Improvement Proposals (GIPs) covering protocol parameters, fee structures, network contribution reward rates, treasury allocations, and new module integrations. Voting power is determined proportionally based on token balance. A proposal passes upon securing a 66% supermajority of participating holders and executes on-chain after any applicable timelock.

During the initial post-TGE period, the core team holds a limited administrative veto, restricted strictly to instances where a proposal would compromise smart-contract security, regulatory compliance, or token classification. This veto expires automatically no later than 24 months post-TGE, or earlier upon reaching defined decentralization milestones, as governance transitions toward a community-governed DAO structure administered alongside the GDP Foundation.

  1. Separation of Extrinsic Network Participation Functions
    Procedures relating to external operational roles—such as posting collateral to activate subnets, deploying applications, entering participation tiers, or engaging in voluntary staking programs—are separate from the intrinsic rights of holding the token. These activities require holders to actively lock their GDP tokens into specific on-chain escrow or protocol smart contracts. Participants in these roles must fulfill separate functional and operational rules to remain eligible for activity-based network contribution rewards funded from the pre-allocated reserve.
G.3: Conditions for modifications of rights and obligations

Intrinsic Rights and Obligations:

Governance-Driven Modifications: The intrinsic rights of token holders (such as the scope of voting rights, fee discount parameters, and protocol fee structures) may be modified through on-chain Governance Improvement Proposals (GIPs). Eligible token holders can submit proposals to adjust protocol parameters, fee structures, network contribution reward rates, treasury allocations, and module integrations. These modifications only take effect if approved by a 66% supermajority of participating token holders.

Core Team Safeguard Guardrail: During the initial post-TGE period, proposals that would compromise smart contract security, applicable regulatory compliance, or token classification characteristics remain subject to a narrowly scoped administrative veto by the W3 core development team. This guardrail is time-limited and expires automatically no later than 24 months after TGE, or earlier once specific decentralization milestones are achieved.

Modifications to Extrinsic Network Participation Functions:

Operational Adjustments: Modifications affecting external operational activities—such as changes to required collateral amounts for subnets, application deployment parameters, or participation tier rules—are separate from intrinsic holder rights. While these parameters are governed and modified via the same 66% supermajority GIP process, adjustments to these operational features only bind or affect holders who voluntarily choose to execute additional actions to participate in those active network infrastructure roles.

G.4: Future public offers

There are no future offers planned.

G.5: Issuer retained other token

200,000,000

G.6: Utility token classification

false

G.7: Key features of goods or services utility tokens

Not applicable as GDP is not a utility token.

G.8: Utility tokens redemption

Not applicable as GDP' is not a utility token.

G.9: Non-trading request

true

G.10: Other tokens purchase or sale modalities

Not applicable. This whitepaper is published solely in relation to the admission to trading of the GDP token and does not relate to any public offering.

G.11: Other tokens transfer restrictions
  • Lock-ups and Structural Vesting: Initial circulating supply at TGE is targeted at approximately 16.5% of the total 1,000,000,000 fixed supply, originating exclusively from the Ecosystem & Community allocation (which vests its remaining portion linearly over 48 months at ~10.3M tokens per month). Team (20%) and Investor (14%) allocations have 0% circulating supply at TGE and are subject to a strict 12-month cliff, followed by a 36-month linear monthly vest (~9.4M tokens combined per month). This structural vesting is programmatically enforced on-chain by audited smart contracts using a 3-of-4 multi-signature control structure, making tokens in locked allocations technically non-transferable until their exact unlock dates.
  • Collateral and Escrow Locks: To participate in active network layer infrastructure roles, participants must voluntarily post and lock GDP tokens into on-chain escrow contracts. These tokens are non-transferable for the duration of network participation. Furthermore, this collateral is subject to programmatic slashing for non-performance or compliance failures; forfeited tokens are redistributed directly to remaining active participants via a closed-loop mechanism rather than being released to the open market, restricting standard transferability.
  • KYC/AML-Based Transfer Restrictions: All token distributions at or following TGE (including public TGE participants, approved airdrop recipients, and validator operators) require mandatory identity verification through a designated third-party KYC provider and AML screening. Primary transfers and token holdings are strictly restricted to wallets that have cleared these compliance checks.
  • Geographic Restrictions and Sanctions Screening: Token purchase, holding, and platform access are geographically restricted. Residents of the United States (absent applicable exemptions), OFAC-sanctioned jurisdictions, and other restricted regions are legally and technically excluded. Continuous transaction monitoring and OFAC sanctions screening are integrated at the application layer to block transfers to sanctioned persons or regions.
  • Fees and Contract Restrictions Beyond the Above: There are no explicit on-chain transfer taxes or arbitrary transfer fees. Beyond the programmatic KYC/AML gates, sanctions-based enforcement, and voluntary collateral/staking lockups, no additional blacklists or whitelists are applied to standard peer-to-peer transfers.
G.12: Supply adjustment protocols

false

G.13: Supply adjustment mechanisms

There are no supply adjustment protocols.

G.14: Token value protection schemes

false

G.15: Token value protection schemes description

There is no protection scheme available.

G.16: Compensation schemes

false

G.17: Compensation schemes description

There are no compensation schemes.

G.18: Applicable law

British Virgin Islands

G.19: Competent court

British Virgin Islands

Part H - Information on the underlying technology
H.1: Distributed ledger technology (DTL)

GDP runs on an Avalanche-based proof‑of‑stake network with its own BOSCO consensus layer, which lets validators securely agree on off‑chain workflow results and then anchor them on‑chain as cryptographic receipts, creating an auditable trail of activity.
Token distribution is fixed‑supply, with most GDP reserved for ecosystem and community use and the rest allocated to team and investors under long‑term, on‑chain vesting schedules that unlock gradually over several years.
Security comes from audited smart contracts, multi‑signature control over treasuries and protocol keys, validator collateral requirements, and KYC for validator operators to limit any single entity’s control.
Immutability and transparency are supported by committing BOSCO consensus results as Merkle‑tree roots on‑chain and publicly labeling all major allocation addresses, so anyone can independently verify state changes and token flows over time.

H.2: Protocols and technical standards

Protocols/standards used for GDP / W3

  • Base L1 and token standard
  • Avalanche C‑chain (EVM L1) used as the canonical settlement layer.
  • GDP token specified as an ERC‑20 token deployed on Avalanche.
  • Workflow‑layer consensus and execution
  • BOSCO: purpose‑built Byzantine fault‑tolerant (BFT) consensus protocol operating at the workflow layer above Avalanche, used to independently verify multi‑step, multi‑vendor workflows and extend settlement‑grade guarantees beyond single transactions.
  • Off‑chain workflow execution with on‑chain settlement on Avalanche to achieve enterprise‑grade throughput and cost while preserving blockchain verifiability.
  • Interoperability primitives
  • JSON–Solidity unification: workflows can coordinate traditional JSON APIs and Solidity smart contracts as interoperable components in a single execution environment, allowing progressive integration of Web2 and Web3 systems without “rip and replace”.
  • Unified execution layer that orchestrates Web2 APIs, Solidity contracts, off‑chain compute, decentralized storage, AI agents, and other infrastructure as peers within one programmable system.
  • Agentic / orchestration standards
  • MCP (Model Context Protocol) used as the orchestration layer for composing financial workflows and enabling AI/agentic actors to discover and execute those workflows.
  • GitHub Actions syntax adopted as the workflow description language, so financial workflows are expressed using a familiar CI/CD‑style standard while abstracting chain selection, gas, key management, and bridging.
  • Wallets / SDKs / bridges
  • In the available materials, specific wallet standards (e.g., WalletConnect versions), concrete SDK packages, or named bridge protocols are not explicitly specified.
H.3: Technology used

The GDP treasury and protocol control wallets utilize a 3‑of‑4 multisignature setup, meaning control transactions require approval from any three of the four designated signers. This multisig structure is intended to mitigate single‑key compromise risk around treasury movements and protocol‑level administrative actions. The specific signatories for this 3‑of‑4 multisig and the operational details are still being finalized ahead of TGE. The available documentation does not specify particular wallet types (hardware vs. software), key‑management systems (such as HSMs or MPC), or any third‑party custodians for either team or user holdings. As a result, apart from the planned multisig for treasury and protocol control, no further technical detail on wallet/key storage and transfer mechanisms is currently disclosed.

H.4: Consensus mechanism

GDP runs on the W3 protocol, which uses Avalanche as a Proof‑of‑Stake L1 settlement layer plus a BOSCO Byzantine Fault Tolerant (BFT) consensus layer for application/workflow execution.
Avalanche PoS provides a large validator set, sub‑second finality, and economic security via staked collateral, while BOSCO forms deterministic validator committees per workflow, aggregates BLS signatures into verifiable receipts, and commits Sparse Merkle Tree roots on‑chain, making execution tamper‑evident and auditable.
This layered design is secure because it combines Avalanche’s PoS validator security with BFT verification of each workflow step, and efficient because consensus rounds are lightweight, committees are small and randomly selected, and finalization is batched into time‑bounded epochs with aggregate signatures, reducing on‑chain overhead while preserving verifiability.

H.5: Incentive mechanisms and applicable fees

Incentive mechanisms and rewards

Participants must post the native token as collateral to activate subnets ("Modules"), deploy applications (“Solution Builders”), and unlock conversion reward eligibility for sales-related roles; this collateral is locked in on‑chain escrow for the duration of participation.
There is an optional “passive staking” program where any token holder can stake and earn network contribution rewards from a pre‑allocated staking reserve, separate from the collateral requirement.
Network contribution rewards are funded from a fixed Ecosystem & Community reserve rather than new token issuance; there are no inflationary block rewards and no token minting beyond the hard cap.
When operators exit or are penalised, their forfeited collateral is redistributed to remaining active participants, creating an additional rewards channel and a closed‑loop supply reduction mechanism.
Participants are rewarded based on activity, usage, and contribution to the network (e.g., operating subnets, building, or sales participation), not merely for passively holding the token.

Fees and value accrual

The platform’s revenue model centres on enterprise workflow execution and real transaction volume, including fees from transaction processing, treasury and yield infrastructure, decentralized cloud services, and composable applications.
Explicit sources of protocol revenue include: (i) gross‑margin fees on economic value created when reusable “recipes” are executed in enterprise workflows, (ii) technology fees on assets under management in programmable yield vaults (USDC, RWAs, private credit, Bitcoin vaults), (iii) fees tied to decentralized compute and storage utilization, and (iv) commercial agreements with ecosystem partners.
Users who pay for W3 services with the native token receive reduced execution and settlement fees, creating a fee‑discount utility for the token.
The documentation does not yet specify granular per‑transaction fee formulas, exact percentages, or the detailed split of each fee between protocol treasury, operators, and other parties; only the high‑level revenue categories and discount mechanism are described.

Burns, buybacks, and supply handling

There is no token burn program currently planned.
There is also no active buyback program; a future buyback funded by protocol revenue is only contemplated as a possible governance proposal subject to a 66% supermajority and regulatory review.
Value accrues primarily via collateral lockups that constrain circulating supply and via redistribution of forfeited collateral to active participants, rather than via burns or ongoing inflation.

Network security model

The materials explicitly state there is no token inflation and no inflationary block rewards, and they do not describe any proof‑of‑work style mining; network security and alignment instead rely on collateral staking for participation tiers, optional passive staking, and activity‑based rewards funded from the pre‑allocated reserve and forfeited collateral.

H.6: Use of distributed ledger technology

false

H.7: DLT functionality description
H.8: Audit

false

H.9: Audit outcome
Part I - Information on Risks
I.1: Offer-related risks

Market and Liquidity Risks

  • As a pre-launch token with an initially low circulating float (~16.5% of total supply at TGE), secondary market liquidity may be limited, leading to high price volatility and significant bid–ask spreads.
  • Target TGE valuation may not be sustained by market demand; adverse market conditions or negative sentiment could cause the token price to trade materially below the implied fully diluted valuation.
  • Large, scheduled unlocks for ecosystem, team, or investors over time may increase sell pressure around vesting dates, negatively impacting market price and liquidity.

Legal and Regulatory Risks

  • The legal classification of the token remains subject to final legal opinions and evolving regulation; there is a risk that regulators could deem the token to be a security or otherwise regulated instrument, which could restrict trading, marketing, or holding in certain jurisdictions.
  • MiCA and other regulatory regimes may impose additional disclosure, governance, or operational obligations; failure to comply could delay or prevent listings, or result in enforcement actions, fines, or compulsory changes to the token design or usage.
  • Geographic restrictions (e.g., for US persons, OFAC-sanctioned jurisdictions, and other restricted regions) may limit participation in the offering or protocol usage, which can reduce demand and liquidity and create uneven access across jurisdictions.

AML / KYC Risks

  • Mandatory KYC/AML checks for TGE participants, airdrop recipients, and validator operators introduce onboarding friction; failure or delay in passing verification may prevent or postpone participation in the offering or token receipt.
  • Reliance on third‑party KYC providers and sanctions‑screening tools creates operational and privacy risks, including potential data breaches, service outages, or misclassifications that could affect user access.
  • Ongoing transaction monitoring and enforcement of geographic restrictions may lead to account limitations, blocked transfers, or forced off‑boarding where suspicious activity or regulatory conflicts are identified.

Technical and Operational Risks

  • The protocol relies on Avalanche L1 infrastructure and associated smart contracts; failures, congestion, changes, or security incidents at the base layer could disrupt settlement, validator operations, or token transfers.
  • Bugs, vulnerabilities, or misconfigurations in core contracts (including the ValidatorSet, vesting, and treasury contracts) could lead to loss or lock‑up of funds, incorrect vesting behaviour, or governance failures, even if audits have been conducted.
  • Treasury and protocol controls are managed via a 3‑of‑4 multisig; compromise, collusion, or unavailability of signatories could result in unauthorized changes, delayed emergency responses, or inability to execute required protocol upgrades.
  • As a developing network, the project remains dependent on a relatively small core team and service providers; key‑person risk, operational errors, or inadequate processes could affect uptime, roadmap delivery, or incident response.

Tokenomics and Vesting Risks

  • The supply is fixed with no inflation mechanism, but a large majority of tokens (~83.5%) will be locked at TGE and released over time; if market demand does not grow proportionally, progressive unlocks can exert sustained downward price pressure.
  • Ecosystem and community allocations (66% of total supply) are controlled by foundation/DAO structures; concentration of undistributed tokens in treasury wallets creates governance and sell‑pressure risk depending on how and when these tokens are deployed.
  • Team (20%) and investor (14%) allocations are subject to 12‑month cliffs followed by 36‑month linear vesting; significant unlocks following cliffs and during the vesting schedule could cause price volatility and dilute early public participants.
  • Although vesting is enforced via audited smart contracts without unilateral override, any undiscovered vulnerabilities or governance upgrades could alter vesting behaviour or create unforeseen distribution outcomes.

Governance and Centralization Risks

  • Governance is based on token‑holder voting through Governance Improvement Proposals, with decisions driven by token‑weighted participation; large holders (including foundation, team, and investors) may exert outsized influence on protocol direction and resource allocation.
  • During an initial period post‑TGE, the core team retains a narrow administrative veto over proposals affecting security, compliance, or token classification; this introduces a temporary centralization and key‑man risk until the veto sunsets (no later than 24 months post‑TGE or upon decentralisation milestones).
  • Validator participation is constrained by staking and concentration limits (e.g., caps preventing any single entity from controlling ≥1/3 of active validator weight at launch), but practical decentralization depends on actual distribution of stake and operator diversity; concentration among a few operators would increase censorship and outage risk.
  • The GDP Foundation (Cayman) and future DAO are expected to manage large treasuries and ecosystem programs; governance failures, misaligned incentives, or regulatory actions against these entities could materially impact protocol development and token value.
I.2: Issuer-related risks
I.3: Other tokens-related risks

Market & Liquidity Risks:
GDP is a pre-launch, illiquid token with no observable secondary market or trading history; price discovery, volatility and slippage risks are therefore high and initial liquidity will depend heavily on market-making and exchange support.
Insider allocations (team 20%, investors 14%, ecosystem/community 66%) are subject to cliffs and long vesting, but future unlocks may create concentrated sell‑pressure once markets exist.
There is no current market data; all assessments are forward‑looking and based on planned tokenomics only.

Legal & Regulatory Risks:
Token distribution, governance, and ecosystem participation are still being structured and rely on ongoing legal and compliance work; final treatment across jurisdictions (e.g., as a security or other regulated instrument) remains uncertain.
Dedicated issuance and foundation entities are still in formation (BVI sub‑co and Cayman foundation), so governance, liability allocation, and regulatory responsibilities may evolve and introduce documentation or execution risk.
No past or current regulatory or law‑enforcement actions are reported, but this is self‑reported and may not capture future or non‑public investigations.

AML / Privacy Risks:
The protocol does not implement anonymity features, mixers, or privacy tech; all transactions are recorded on-chain and publicly verifiable, which reduces typical “privacy coin” AML concerns but increases on‑chain traceability of user activity.
The project intends to implement KYC/AML processes, geographic restrictions, and onboarding controls, but these frameworks are not yet fully deployed or tested at scale, creating execution and enforcement risk.

Technical & Security Risks:
As a pre‑mainnet protocol, GDP/W3 faces smart contract risk in core protocol and vesting contracts; audits are planned as a mitigation but cannot guarantee absence of vulnerabilities.
Validator concentration and protocol‑control risk exist; these are to be mitigated via a ValidatorSet contract (capping any entity at <1/3 of active validator weight) and a 3‑of‑4 multisig for treasury/protocol control, both of which introduce reliance on correct configuration and operational security of a small keyholder set.

Governance Risks:
A large share of tokens (ecosystem/community 66%, team 20%, investors 14%) will sit initially with the foundation/treasury and locked insiders, creating potential governance centralization until tokens are broadly distributed and on‑chain governance (GIPs) is active.
On‑chain governance and DAO structures are planned but not yet live; parameters, quorum thresholds, and actual community participation levels remain untested and may lead to governance capture or slow reaction to critical issues.

Listings & Venue Risks:
GDP is not yet listed; active discussions with exchanges are ongoing, so listing timelines, venue quality, and geographic coverage are uncertain and subject to exchange risk assessments and regulatory conditions.
Any future CEX listings will concentrate liquidity and market integrity risk in a small number of venues and designated market‑makers, with associated counterparty, delisting, and liquidity‑withdrawal risks.

I.4: Project implementation-related risks

Technical risks:
Smart contract vulnerabilities in core protocol, ValidatorSet, vesting, and collateral contracts could result in loss of funds, incorrect vesting, or validator misconfiguration, even with planned audits and bug bounties.
Validator concentration or BOSCO consensus failure under adversarial conditions could degrade liveness or safety if on-chain concentration limits and BFT assumptions fail in practice.
Dependency on Avalanche L1 as canonical settlement layer introduces chain-level performance or outage risk, even though the execution layer is intended to be chain-agnostic.

Operational / resource risks:
Delays in completing audits, finalising multi‑sig signatories, and productionising BOSCO consensus, ValidatorSet, and workflow execution contracts could push back mainnet launch and TGE.
Execution risk in standing up and coordinating KYC‑verified validator operators, internal treasury controls, and on-chain vesting processes could hinder stable network operations at launch.

Third‑party dependency risks:
Reliance on external KYC/AML providers and sanctions‑screening tools introduces risks of outages, false positives/negatives, data breaches, or policy changes that could disrupt onboarding and token distribution.
Security audit firms are not yet confirmed; delays or shortcomings in third‑party audits would increase residual smart contract risk at launch.
Dependency on public infrastructure (Avalanche validators, explorers, GitHub, cloud services) may affect uptime, monitoring, and transparency if these services degrade.

Market / liquidity risks:
Targeting sub‑$1B FDV with ~16.5% initial float concentrates supply, which can amplify price volatility and make it harder to build deep, organic liquidity in early markets.
Large ecosystem and community allocations (with ongoing vesting) and investor/team unlocks after cliffs may create sustained sell‑pressure if product adoption or demand lags, even though vesting is linear.
As a pre‑launch token with no live markets yet, there is execution risk around exchange listings, market‑maker support, and achieving sufficient secondary‑market liquidity at or after TGE.

Legal / compliance risks:
Token classification remains subject to final legal opinions; if regulators view GDP as a security or as falling under stricter regimes than anticipated, this could impose additional disclosure, licensing, or distribution constraints.
MiCA and global compliance plans (e.g., geographic restrictions, AML/KYC and transaction monitoring) may be insufficient or need revision as regulations evolve, creating risk of enforcement actions or forced changes to token utility and access.
Mandatory KYC/AML for all token distributions, validators, and airdrops increases data‑protection and operational‑compliance risk, particularly if third‑party providers fail to meet regulatory or security expectations.

Governance / tokenomics risks:
On‑chain governance requiring 66% supermajority may hinder timely parameter changes or upgrades, especially if token distribution is concentrated or voter participation is low.
The initial, time‑limited team veto over proposals introduces centralisation risk and potential misalignment between core contributors and token holders until decentralisation milestones are met and the veto sunsets.
Fixed‑supply design with large allocations to ecosystem, team, and investors, enforced via vesting contracts, concentrates governance power and may delay practical decentralisation if these stakeholders retain effective control over voting and treasury.

I.5: Technology-related risks

Smart contracts

  • Core protocol, ValidatorSet, and vesting contracts are not yet open-sourced and are only planned to be audited prior to mainnet, leaving current code and audit coverage opaque and increasing residual bug/exploit risk at launch.
  • ValidatorSet on Avalanche enforces validator registration, staking, and concentration limits and vesting is enforced on-chain, but both mechanisms depend on correct contract implementation and governance over the 3-of-4 multisig controlling treasury/protocol parameters.

Cross‑chain / interoperability

  • The platform is explicitly chain‑agnostic and designed to orchestrate workflows across multiple chains and infrastructure providers, including cross‑chain settlement, which introduces standard bridge/interoperability risks (complex execution paths, dependency on multiple providers, and harder incident isolation) if any integrated chain or service fails or is compromised.
  • BOSCO, a BFT coordination layer above Avalanche, independently verifies multi‑step, multi‑vendor workflows; bugs or consensus failures in this additional layer could cause inconsistent workflow outcomes even if underlying chains are functioning correctly.

Scalability / performance

  • Architecture is explicitly designed for enterprise‑scale programmable finance, separating workflow orchestration from settlement and leveraging Avalanche L1 plus BOSCO for coordination, but actual throughput and latency at scale remain unproven in production given the pre‑launch status.
  • The need to coordinate payments, identity, compliance, storage, compute, and cross‑chain settlement within single workflows could create performance bottlenecks at the orchestration layer or at external providers under high load.

Wallet / privacy

  • Current materials emphasize orchestration of payments, identity, compliance, storage, and compute rather than a native user wallet; users will likely rely on third‑party wallets, inheriting their key‑management and UX risks, while GDP/W3 focuses on backend workflows.
  • Integration of identity and compliance services into multi‑step workflows increases the sensitivity of off‑chain and on‑chain data flows; misconfiguration, insecure integrations, or compromise of any provider could expose financial or identity data, and no explicit end‑user privacy guarantees are yet documented.

L2 / base‑layer dependencies

  • Settlement currently depends on Avalanche L1 infrastructure, so GDP inherits Avalanche’s consensus, network, and bridge risks (including potential outages, reorgs, or critical vulnerabilities) in addition to BOSCO’s workflow‑layer consensus; no explicit L2/rollup dependency is described so far.
  • Validator participation is KYC‑gated and constrained by a concentration limit (no entity ≥1/3 of validator weight at launch), which reduces some centralization risk but also introduces regulatory and operational dependence on the validator admission process and associated off‑chain checks.

Audits / security posture

  • Audit plans cover vesting contracts, the ValidatorSet contract, and core protocol contracts before mainnet, but audit firms and reports are not yet published, so independent assurance on security and correctness is currently unavailable.
  • Treasury and protocol controls use a 3‑of‑4 multisig and on‑chain, programmatic vesting, which are positive controls, yet they concentrate governance power in a small set of keys whose operational security (key storage, rotation, incident response) is not detailed in public materials.
I.6: Mitigation measures

Smart contract vulnerability
Mitigation measures:

  • Commission independent third‑party audits of all core protocol and vesting contracts before mainnet/TGE.
  • Launch a public bug bounty program at or before mainnet to incentivise external security research.
    Limitations: Audits and bounty cannot guarantee absence of vulnerabilities; status currently “In progress”, so pre‑launch code may still change and not yet be fully reviewed.

Validator concentration (≥1/3 stake)
Mitigation measures:

  • Enforce on-chain concentration limits via a ValidatorSet smart contract so that no entity or affiliated group controls ≥1/3 of active validator weight at launch.
  • Require KYC verification for validator operators to identify and limit affiliated entities.
    Limitations: Controls are strongest at launch; over time stake could reconcentrate unless periodic monitoring and parameter updates occur. KYC reduces but does not eliminate the risk of hidden affiliations.

BOSCO consensus failure under adversarial conditions
Mitigation measures:

  • Use a BFT-style consensus design that is tolerant to a bounded number of Byzantine validators.
  • Select committees deterministically from on-chain randomness to reduce predictability and targeted corruption of specific validators.
    Limitations: BFT guarantees depend on honest-majority and network assumptions; extreme network partitions or >1/3 collusion can still cause safety or liveness failures. Formal verification or adversarial testing beyond design claims is not documented.

Avalanche L1 dependency
Mitigation measures:

  • Architect the W3 execution layer to be chain‑agnostic so settlement is not irrevocably tied to Avalanche.
  • Design routing so settlement can be redirected to alternative L1s if Avalanche becomes unavailable or unsuitable.
    Limitations: Current mitigation is described as “Designed”, indicating that multi‑chain settlement and fail‑over may not yet be implemented or tested in production; operational and governance processes for executing a migration/fail‑over are not specified in the available materials.
Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
S.1: Name

GDP Sup Corp

S.2: Relevant legal entity identifier

984500DCCFAAEC0AEC24

S.3: Name of the crypto-asset

GDP

S.4: Consensus mechanism

GDP runs on the W3 protocol, which uses Avalanche as a Proof‑of‑Stake L1 settlement layer plus a BOSCO Byzantine Fault Tolerant (BFT) consensus layer for application/workflow execution.
Avalanche PoS provides a large validator set, sub‑second finality, and economic security via staked collateral, while BOSCO forms deterministic validator committees per workflow, aggregates BLS signatures into verifiable receipts, and commits Sparse Merkle Tree roots on‑chain, making execution tamper‑evident and auditable.
This layered design is secure because it combines Avalanche’s PoS validator security with BFT verification of each workflow step, and efficient because consensus rounds are lightweight, committees are small and randomly selected, and finalization is batched into time‑bounded epochs with aggregate signatures, reducing on‑chain overhead while preserving verifiability.

S.5: Incentive mechanisms and applicable fees

Incentive mechanisms and rewards

Participants must post the native token as collateral to activate subnets (“Modules”), deploy applications (“Solution Builders”), and unlock conversion reward eligibility for sales-related roles; this collateral is locked in on‑chain escrow for the duration of participation.
There is an optional “passive staking” program where any token holder can stake and earn network contribution rewards from a pre‑allocated staking reserve, separate from the collateral requirement.
Network contribution rewards are funded from a fixed Ecosystem & Community reserve rather than new token issuance; there are no inflationary block rewards and no token minting beyond the hard cap.
When operators exit or are penalised, their forfeited collateral is redistributed to remaining active participants, creating an additional rewards channel and a closed‑loop supply reduction mechanism.
Participants are rewarded based on activity, usage, and contribution to the network (e.g., operating subnets, building, or sales participation), not merely for passively holding the token.

Fees and value accrual

The platform’s revenue model centres on enterprise workflow execution and real transaction volume, including fees from transaction processing, treasury and yield infrastructure, decentralized cloud services, and composable applications.
Explicit sources of protocol revenue include: (i) gross‑margin fees on economic value created when reusable “recipes” are executed in enterprise workflows, (ii) technology fees on assets under management in programmable yield vaults (USDC, RWAs, private credit, Bitcoin vaults), (iii) fees tied to decentralized compute and storage utilization, and (iv) commercial agreements with ecosystem partners.
Users who pay for W3 services with the native token receive reduced execution and settlement fees, creating a fee‑discount utility for the token.
The documentation does not yet specify granular per‑transaction fee formulas, exact percentages, or the detailed split of each fee between protocol treasury, operators, and other parties; only the high‑level revenue categories and discount mechanism are described.

Burns, buybacks, and supply handling

There is no token burn program currently planned.
There is also no active buyback program; a future buyback funded by protocol revenue is only contemplated as a possible governance proposal subject to a 66% supermajority and regulatory review.
Value accrues primarily via collateral lockups that constrain circulating supply and via redistribution of forfeited collateral to active participants, rather than via burns or ongoing inflation.

Network security model

The materials explicitly state there is no token inflation and no inflationary block rewards, and they do not describe any proof‑of‑work style mining; network security and alignment instead rely on collateral staking for participation tiers, optional passive staking, and activity‑based rewards funded from the pre‑allocated reserve and forfeited collateral.

S.6: Beginning of period to which disclosed information relates

2026-05-08

S.7: End of period to which disclosed information relates

2026-05-21

S.8: Energy consumption

12.70084

S.9: Energy consumption sources and methodologies

Data provided by CCRI; all indicators are based on a set of assumptions and thus represent estimates; methodology description and overview of input data, external datasets and underlying assumptions available at: https://carbon-ratings.com/dl/whitepaper-mica-methods-$gdp and https://docs.mica.api.carbon-ratings.com. We do not account for any offsetting of energy consumption or other market-based mechanism as of today.

S.10: Renewable energy consumption

Not applicable as the annual energy consumption is less than 500 kWh.

S.11: Energy intensity

Not applicable as the annual energy consumption is less than 500 kWh.

S.12: Scope 1 DLT GHG emissions - controlled

Not applicable as the annual energy consumption is less than 500 kWh.

S.13: Scope 2 DLT GHG emissions - purchased

Not applicable as the annual energy consumption is less than 500 kWh.

S.14: GHG intensity

Not applicable as the annual energy consumption is less than 500 kWh.

S.15: Key energy sources and methodologies

Not applicable as the annual energy consumption is less than 500 kWh.

S.16: Key GHG sources and methodologies

Not applicable as the annual energy consumption is less than 500 kWh.

S.17: Energy mix

Not applicable as the annual energy consumption is less than 500 kWh.

S.18: Energy use reduction

Not applicable as the annual energy consumption is less than 500 kWh.

S.19: Carbon intensity

Not applicable as the annual energy consumption is less than 500 kWh.

S.20: Scope 3 DLT GHG emissions - value chain

Not applicable as the annual energy consumption is less than 500 kWh.

S.21: GHG emissions reduction targets or commitments

Not applicable as the annual energy consumption is less than 500 kWh.

S.22: Generation of waste electrical and electronic equipment (WEEE)

Not applicable as the annual energy consumption is less than 500 kWh.

S.23: Non-recycled WEEE ratio

Not applicable as the annual energy consumption is less than 500 kWh.

S.24: Generation of hazardous waste

Not applicable as the annual energy consumption is less than 500 kWh.

S.25: Generation of waste (all types)

Not applicable as the annual energy consumption is less than 500 kWh.

S.26: Non-recycled waste ratio (all types)

Not applicable as the annual energy consumption is less than 500 kWh.

S.27: Waste intensity (all types)

Not applicable as the annual energy consumption is less than 500 kWh.

S.28: Waste reduction targets or commitments (all types)

Not applicable as the annual energy consumption is less than 500 kWh.

S.29: Impact of the use of equipment on natural resources

Not applicable as the annual energy consumption is less than 500 kWh.

S.30: Natural resources use reduction targets or commitments

Not applicable as the annual energy consumption is less than 500 kWh.

S.31: Water use

Not applicable as the annual energy consumption is less than 500 kWh.

S.32: Non recycled water ratio

Not applicable as the annual energy consumption is less than 500 kWh.

S.33: Other energy sources and methodologies

Not applicable as the annual energy consumption is less than 500 kWh.

S.34: Other GHG sources and methodologies

Not applicable as the annual energy consumption is less than 500 kWh.

S.35: Waste sources and methodologies

Not applicable as the annual energy consumption is less than 500 kWh.

S.36: Natural resources sources and methodologies

Not applicable as the annual energy consumption is less than 500 kWh.