Nest Token Transparency Filing

Project & Team

Description of Project

Provide a narrative description of the purpose of the project.

nest is the Hyperliquid spot growth and yield machine: the liquidity, growth, and yield layer of the ecosystem, and the first ve(3,3) decentralized exchange that turns trading fees into amplified HYPE exposure.

Where traditional DEXs simply distribute fees, nest multiplies them through HYPE Engine treasury mechanics. Assets launch, bootstrap liquidity, and scale into HyperCore on nest, and every trade compounds HYPE accumulation and upside for the people holding it.

Known Project Team

For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the:

(a) full names,
(b) official titles,
(c) and prior experience of key team members.

For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.

Labs / DevCo

Full Name	Official Title	Prior Experience
Does not exist

Foundation

Full Name	Official Title	Prior Experience
Does not exist

DAO / Onchain Governance

Full Name	Official Title	Prior Experience
@satsyxbt	CEO of nest; member of the 3/4 Safe multisig used for nest-controlled veNEST	Founder of Blast
@Telaga	COO of nest; member of the 3/4 Safe multisig used for nest-controlled veNEST	Blast
	Individual veNEST voters execute governance on-chain by each wallet
@ace_da_book	CSO of nest; member of the 3/4 Safe multisig used for nest controlled veNEST	Aerodrome, Liquid Crypto Fund Management

DAO Structure

Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so for each sub question. Even if there is no DAO, there must be an answer to (d). Address the lettered items below.

(a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
(b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
(c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
(d) Current tokenholder governance rights and economic arrangements — If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
(e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(f) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).

(a) IP ownership & control

veNEST tokenholders do not control or own any IP

(b) Contract/admin powers

Governance authority. veNEST confers no rights over contract or admin changes. veNEST voting directs NEST emissions across gauges only. There is no on-chain governance executor, no proposal or voting system for protocol parameters, and no veto or super-majority mechanism. All administrative authority rests with the Nest team multisig.

The team multisig. The protocol admin is a Gnosis Safe at 0x6652173b0Cb3d96d8f0198bc49670440Dec69e79, requiring 3 of 5 signatures. The method of authority is a simple majority of a fixed five-key signer set. Signers are:

0xD969e33695C1ef22F56409A04C14470aF864fE6d
0xEaf38993240Ab0a5d4823eb8410bD11bB6c23CA5
0xdB180c83029577A1Cb323542EC796Fa4cC7b8F51
0x1CA8caF5197454A9eAbE05Db3A3c80897d5516A2
0xe8c4C070baa6117eB3186F8AE6ccEB7406707ea7

These keys are held by the CEO, CSO, and COO of Nest and the CTO of Aegas. Each is an externally owned account, not a contract. Separately, six 2-of-3 Gnosis Safes hold token allocations only and carry no protocol admin rights; the sole exception is noted under Minting below.

Upgrade authority and its limit. All implementation upgrades are gated by a TimelockController at 0xFBcC128edfddb638B0939a67f6F505b37425F587 with a minimum delay of 86,400 seconds, or 24 hours. The 3-of-5 Safe is the sole holder of the PROPOSER, EXECUTOR, CANCELLER and TIMELOCK_ADMIN roles. No individual signer holds any timelock role, and the executor role is not open to the public, so no third party can execute a queued operation. The timelock owns both ProxyAdmin contracts:

0xb688d5e73777DfaaDbD7c5Fe98Aee6F35CF20124 governs the core contracts
0x45727c03B46970C64E4039B546E6bd1F9c9d92ab governs the Algebra DEX contracts

Upgradeable contracts therefore cannot be changed in under 24 hours, and any queued upgrade is publicly visible on-chain for that entire window before it can execute.

The upgradeable contracts and their current implementations are:

ContractProxyImplementationMinter0x574f6865140e6929bDed24596D78a8D9c07E356d0x13369f61c13bD809984855Ad26B1Bf7780Da8fB8Voter0x566bdc5444fd5fe5d93ec379Bd66eC861ddbA9010x2d70695c2f32C6b692370318436eF18d5c4677C1VotingEscrow0x2f2Ae07e3cc3391A2E27825652BA8DcdD54120740xF70526a0089FDC334814C3498cA1Ba30c25aBA91GaugeRewarder0xfF0124cf664240e5573282511042d7033C3f22eA0x4158958Bf30C818491b36020f4b709404ce645EeAlgebraFactory0xF77Bd082c627aA54591cF2f2EaA811fd1AB3b1F30xd99930FAE54B3Fbc237eB330527501237bB1B59E

What cannot be upgraded. The NEST token contract at 0x07c57E32a3C29D5659bda1d3EFC2E7BF004E3035 is not a proxy. It has no EIP-1967 implementation slot and its logic is immutable. Token transfer, balance and burn behaviour cannot be altered by any party, including the team multisig.

Pause authority. None exists. No pause, unpause, freeze, halt, blacklist or emergency-stop function is present in the deployed bytecode of the NEST token, Minter, Voter, VotingEscrow, AlgebraFactory or GaugeRewarder. The team cannot halt trading, freeze transfers, or block withdrawals. The only circuit breaker in the system is Voter.killGauge(address) and its counterpart Voter.reviveGauge(address), which stop and restore NEST emissions to a single liquidity gauge. Neither affects token transfers, swaps, LP withdrawals, or veNEST unlocking.

Non-timelocked authorities. The 3-of-5 Safe at 0x6652173b0Cb3d96d8f0198bc49670440Dec69e79 directly holds DEFAULT_ADMIN_ROLE on the Voter, AlgebraFactory and GaugeRewarder, and is the owner() of the VotingEscrow and AlgebraFactory. Actions under those roles, including gauge kill and revive and pool fee parameters, take effect immediately and are not subject to the 24-hour delay. Only implementation upgrades pass through the timelock.

Single-key authority. In addition to the 3-of-5 Safe, the individual key 0xD969e33695C1ef22F56409A04C14470aF864fE6d holds GOVERNANCE_ROLE on the Voter at 0x566bdc5444fd5fe5d93ec379Bd66eC861ddbA901 in its own right. Method of authority: unilateral single signer, with no threshold and no timelock delay. This key is held by the Nest team. GOVERNANCE_ROLE gates exactly two functions, killGauge(address) and reviveGauge(address), which stop and restore NEST emissions to an individual liquidity gauge. It confers no other authority: the key cannot upgrade contracts, mint or burn NEST, move treasury assets, alter allocations, change pool or emission parameters, or affect token transfers, swaps, LP withdrawals or veNEST unlocking. The same two functions are also exercisable by the 3-of-5 Safe through its DEFAULT_ADMIN_ROLE.

Minting. NEST.mint() is owner-gated, and the token's owner is the Minter proxy at 0x574f6865140e6929bDed24596D78a8D9c07E356d. Issuance is therefore programmatic per epoch rather than discretionary, and no human-controlled account can mint NEST directly. The Minter's own owner() is a 2-of-3 Gnosis Safe at 0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827, which can call setTeamRate() and setVoter() without timelock delay.

(c) Locked-token rights (conditional)

Tokenholders may lock NEST to obtain veNEST. veNEST is the on-chain economic and governance layer of the protocol, and individual holders vote directly from their own wallets. The scope of that vote is limited: veNEST holders direct NEST emissions across liquidity gauges each weekly epoch, determining which DEX pools receive incentives. veNEST does not vote on protocol parameters, contract upgrades, or administrative changes, and there is no proposal system, veto, or super-majority mechanism. Administrative authority rests with the nest team multisigs, principally a 3-of-5 Gnosis Safe; protocol-owned veNEST is held in 2-of-3 Gnosis Safes.

Holders who lock and vote share 100% of on-chain rewards in proportion to veNEST vote weight, comprising trading fees, voting incentives, and HYPE distributed through the HYPE Engine Vault. veNEST voters receive 100% of trading fees generated by the pools they vote for, distributed by smart contract, and 100% of third-party voting incentives are distributed to the voters who supported those pools.

Tokenholder rights are on-chain rights only. The token is not a claim on the profits, revenues, or assets of the Development Company. NEST issuance follows an epoch-based schedule with defined starting emissions, ramp-up and programmed decline, implemented through the Minter's inflationRate and decayRate parameters, currently 150 and 100 basis points respectively. Emissions allocation is governed by veNEST votes. The rate parameters are adjustable by the Minter's owning 2-of-3 multisig; nest's stated policy is to keep adjustments within a ±25% band, which is a policy commitment rather than a contract-enforced bound. No party can mint NEST arbitrarily, and the 5% protocol emissions cut is hard-capped in the contract at 500 basis points.

(d) Current tokenholder governance rights and economic arrangements

Tokenholder rights are on-chain only. Tokenholders may lock NEST to obtain veNEST, and veNEST is the on-chain economic and governance layer of the protocol. The scope of veNEST governance is narrow and specific: veNEST holders vote each weekly epoch to direct NEST emissions across liquidity gauges, determining which DEX pools receive incentives. veNEST does not vote on protocol parameters, contract upgrades, or administrative changes. There is no proposal system, no governance executor, no veto, and no super-majority mechanism. Administrative authority rests entirely with the nest team multisigs, principally a 3-of-5 Gnosis Safe at 0x6652173b0Cb3d96d8f0198bc49670440Dec69e79.

Individual veNEST holders vote directly from their own wallets. Protocol-owned veNEST, comprising the HYPE Engine, Team, Ecosystem Fund and Assistance Fund allocations, is held in 2-of-3 Gnosis Safe multisigs, one per allocation.

Economically, the token is not a claim on the profits, revenues, or assets of the Development Company. Any economic benefit arises solely through automatic on-chain protocol mechanisms available to holders who lock into veNEST. veNEST voters receive 100% of trading fees generated by the pools they vote for, distributed by smart contract at epoch end. Protocols may offer voting incentives to attract veNEST votes to their pools, and 100% of those incentives are distributed to the veNEST voters who supported them. Holders who lock and vote share 100% of on-chain rewards in proportion to their veNEST vote weight, comprising trading fees, voting incentives, and HYPE distributed through the HYPE Engine Vault. The HYPE Engine receives the veNEST voting rewards accruing to the HYPE Engine NFT, converts that revenue into HYPE, and distributes HYPE as a reward stream to veNEST participants.

Emissions allocation is governed by veNEST votes. Of each epoch's newly minted NEST, 5% is routed to a protocol-controlled emissions receiver for voting incentives directed at partner and ecosystem pools. This 5% is enforced in the Minter contract by teamRate, which is hard-capped at MAX_TEAM_RATE of 500 basis points and cannot be raised above 5% by any party. The protocol additionally maintains a Growth Treasury of liquid NEST.

Buybacks are performed by the Assistance Fund and the HYPE Engine Vault, and may be performed by the Ecosystem Fund at the discretion of the team.

Beyond the automatic entitlements described above, tokenholders hold no governance rights over discretionary protocol decisions. They cannot direct treasury spending, alter fee routing, set reward parameters, initiate or size buybacks, or control any protocol-held assets. Those decisions rest with the team multisigs. The fee and incentive entitlements above are automatic consequences of the smart contracts and are not subject to tokenholder vote or team discretion.

(e) Control surface reliance

Governance currently operates on-chain through individual veNEST holders voting from their own wallets, with the scope of that vote limited to directing NEST emissions across liquidity gauges. Protocol-owned veNEST is held in 2-of-3 Gnosis Safe multisigs. Contract and administrative authority sits separately with a 3-of-5 Gnosis Safe at 0x6652173b0Cb3d96d8f0198bc49670440Dec69e79 and is not subject to tokenholder vote.

The disclosed possible evolution of the control model relates to NEST emissions. Issuance follows an epoch-based schedule with defined starting emissions, a ramp-up phase, and a programmed decline. The schedule is implemented in the Minter contract at 0x574f6865140e6929bDed24596D78a8D9c07E356d through two parameters: inflationRateand decayRate, which reduces them by 1.00% per epoch. Allocation across pools is governed by veNEST votes, and distribution is community-guided.

Both rate parameters are adjustable by the Minter's owner, a 2-of-3 Gnosis Safe at 0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827, without timelock delay. The contract bounds each parameter at 100%. nest's stated policy is to confine adjustments to a ±25% band around the scheduled rate; this is a policy commitment enforced by multisig discipline, not a constraint imposed by the contract. No party can mint NEST arbitrarily: NEST.mint() is callable only by the Minter, issuance occurs only through the permissionless weekly update_period() cycle, and the 5% protocol cut is hard-capped at 500 basis points by MAX_TEAM_RATE. Future emission adjustments will be published on-chain and on a Dune analytics page.

(f) Dissolution authority

nest has no on-chain dissolution function, no wind-down module, and no emergency withdrawal or migration mechanism. There is no procedure by which the team can shut the protocol down, and none by which the protocol is formally dissolved. What governs a wind-down is instead a set of contract properties determining what survives if the team ceases operations.

User exit does not depend on the team. The protocol is non-custodial and contains no pause, freeze, blacklist or emergency-stop function. Liquidity providers can withdraw from Algebra pools at any time. veNEST holders withdraw underlying NEST through withdraw(uint256) on the VotingEscrow at 0x2f2Ae07e3cc3391A2E27825652BA8DcdD5412074, which is gated by onlyNftApprovedOrOwner and requires only that the lock has expired. No administrative action, signature, or approval from Nest or Aegas is required for any user to exit, and no party can prevent it.

Emissions continue without the team. update_period() on the Minter at 0x574f6865140e6929bDed24596D78a8D9c07E356d is permissionless and callable by any address once per weekly epoch. Emission accrual and gauge distribution continue on schedule whether or not the team remains active. Abandonment does not halt the protocol.

Voluntary relinquishment of authority. The team can permanently surrender administrative control. renounceOwnership() is present on the NEST token, Minter, VotingEscrow and AlgebraFactory, and the TimelockController roles can be renounced or revoked. Doing so would leave the contracts ownerless and the implementations permanently immutable, since all upgrade authority derives from the timelock at 0xFBcC128edfddb638B0939a67f6F505b37425F587. Method of authority: 3-of-5 majority on the core Safe, and 2-of-3 on the Minter owner Safe. The action is irreversible with no recovery mechanism.

Permanently locked allocations in a wind-down. The Team, Ecosystem Fund, HYPE Engine and Assistance Fund allocations are held as permanently max-locked veNEST. This is a policy commitment rather than a technical impossibility. unlockPermanent(uint256) on the VotingEscrow is gated by onlyNftApprovedOrOwner, so the holding Safe can convert a permanent lock into a decaying lock, which expires after at most six months, after which the NEST becomes withdrawable. Enforcement rests on multisig discipline at a 2-of-3 threshold, not on code. In a wind-down these allocations could return to circulation over a maximum six-month horizon.

Treasury assets. No mechanism compels distribution of treasury assets to tokenholders on dissolution. Growth Treasury holdings remain under the control of their 2-of-3 Safe, and disposition would be a discretionary decision of the signers.

Primary Foundation

For the Primary Foundation do the following independently. If a Foundation does not exist, state so for each sub question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary Foundation can be explained as the entity which was directly/indirectly involved in the issuance of the native token at launch. If the original Foundation has been dissolved and in its place a "new Foundation" was created, then detail the "new Foundation".

(a) Entity — Type and jurisdiction.
(b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
(d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
(e) Contract/admin powers — Pause/upgrade/governance-executor authorities, and the method/threshold for each (e.g., veto/majority/super-majority).
(f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly.

(a) Entity

No Primary Foundation exists; Nest Exchange has no Foundation. Accordingly, there is no entity type or jurisdiction to disclose for a Primary Foundation.

(b) IP ownership & control

Nest Exchange has no Foundation; therefore, there is no Primary Foundation IP ownership or control to disclose for repos/code, trademarks, or brand.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

Nest Exchange has no Foundation or Labs. Accordingly, there is no Primary Foundation with current powers over DAO governance, treasury actions, protocol-controlled resources, token administration, or reward parameters.

(d) Powers over DevCo

Nest Exchange has no Foundation. As a result, there is no Foundation that can exert direct or indirect influence over DevCo decision-making.

(e) Contract/admin powers

Nest Exchange has no Foundation. There are no Primary Foundation contract/admin powers to disclose for pause, upgrade, or governance-executor authorities.

(f) Current economic arrangements and distribution policies

Nest Exchange has no Primary Foundation. Accordingly, this sub-question is not applicable to a Foundation entity.

Primary DevCo

For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly across each sub-question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary DevCo can be explained as the entity which was directly/indirectly involved in the issuance of the native token at launch. If the original DevCo has been dissolved and in its place a "new DevCo" was created, then detail the "new DevCo".

(a) Entity — Type and jurisdiction.
(b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
(d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
(e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
(f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.

(a) Entity

There is no Primary DevCo legal entity for which an entity type or jurisdiction applies. Nest is an entirely on-chain business with no legal wrapper and has no Foundation or Labs.

(b) IP ownership & control

No Primary DevCo is disclosed. Nest is an entirely on-chain business with no legal wrapper, and Nest Exchange has no Foundation or Labs. Accordingly, no repos/code, trademarks, brand assets, or other IP owned or controlled by a Primary DevCo are disclosed.

(c) Powers over DAO, treasury, protocol-controlled resources, and token administration

Nest is an entirely on-chain business with no legal wrapper and has no Foundation or Labs. Accordingly, no Primary DevCo powers over DAO governance, treasury actions, protocol-controlled resources, token administration, or reward parameters are disclosed.

(d) Powers over Foundation

Nest Exchange has no Foundation or Labs. Nest is an entirely onchain business with no legal wrapper; therefore, there is no Foundation decision-making body disclosed over which a DevCo could exert direct or indirect influence.

(e) Contract/admin powers

No Primary DevCo exists. Nest is an entirely on-chain business with no legal wrapper, so there are no Primary DevCo contract or admin powers to disclose for pause, upgrade, or governance-executor authorities.

(f) Current economic arrangements and distribution policies

Nest Exchange has no Foundation or Labs and is an entirely on-chain business with no legal wrapper; accordingly, there is no Primary DevCo and there are no equityholders. No current mechanism exists by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions are directed to a Primary DevCo or its equityholders. The project has 100% revenue sharing with no protocol fee extraction: weekly DEX trading fees are fully distributed to veNEST holders, fees are distributed entirely through smart contracts and not by a DevCo, and voluntary on-chain voting incentives are not connected to a DevCo.

Affiliated Protocol Contributor

Definition (for this section): An Affiliated Protocol Contributor (APC) is a non-issuer company - not the protocol's primary Foundation or DevCo - that materially contributes to the protocol's code, operations, governance, or funding. For example, Blockworks Advisory would be considered an APC of Ethena because it materially contributes to its operations through Ethena's risk council. Provide a structured description per APC. If no APCs exist, state that explicitly across each sub-question. Items below apply per APC.

(a) Identity & role — Legal name, entity type, jurisdiction, and role (e.g., core development, security, infrastructure, market making, operations).
(b) Parameter control & scope — For each existing APC, if any, what major protocol parameters the APC controls; include the method of authority (e.g., veto, majority, super-majority). If none, say so.
(c) Contract/admin powers — For each existing APC, if any, provide the pause/upgrade powers (e.g., multisig pause), governance-executor authorities and limitations; include the method of authority for each (e.g. veto, majority, super-majority). If none, say so.
(d) Compensation and material economic arrangements — For each existing APC, if protocol-generated resources or economic value is dynamically routed to the APC, describe the arrangement. If applicable, include the resource sources, routing mechanism, payment frequency, and duration. If no protocol resources or resources-linked economics are routed to the APC, state that explicitly.

(a) Identity & role

The disclosed non-issuer contributor categories are: (1) a software development agency, Aegas.io (Aegas, LLC, Delaware, USA), whose role is software development and which received 1,466,705 veNEST tokens with a 6-month lock and linear vest; and (2) a marketing agency, Giga Corp (GIGA OO LTD, London, England), whose role is marketing and which received 6,252,795 veNEST tokens with a 6-month lock and linear vest.

(b) Parameter control & scope

Aegas - controls no parameters
Giga Corp - controls no parameters

(c) Contract/admin powers

Affiliated Protocol Contributors. Nest has one APC: Aegas, a contracted development and infrastructure provider engaged to build and operate protocol systems. Aegas materially contributes to code and operations. No other APCs exist. Third-party integrations (Algebra Integral, ICHI, Steer, Angle, Merkl, Fuul, OpenOcean, Orbs) are passive technical integrations and do not contribute to code, operations, governance or funding. Auditors (BailSec, Hats Finance, Code4rena) are one-off service providers. The HYPE Engine is protocol-owned infrastructure held in a Nest-controlled Safe, not a separate entity.

Aegas: contract and admin powers.

Aegas holds no protocol authority as an entity. No address controlled by Aegas as a company holds any role, ownership position, or admin key on any Nest contract. Its influence is exercised solely through personnel who sit on Nest multisigs as individual signers.

One Aegas officer, its CTO, holds one signer key. That key is one of five on the core admin Safe at 0x6652173b0Cb3d96d8f0198bc49670440Dec69e79 (3-of-5 threshold) and one of three on each of the six token-allocation Safes (2-of-3 threshold). Method of authority: minority signer within a majority-threshold multisig. Aegas cannot act unilaterally in either case. On the core admin Safe it must be joined by two of the four other signers; on an allocation Safe it must be joined by one of the two other signers. It cannot block action either, since the remaining signers meet both thresholds without it.

Aegas has no pause power, because no pause function exists anywhere in the protocol. It has no independent upgrade power. It holds no role on the TimelockController at 0xFBcC128edfddb638B0939a67f6F505b37425F587, no role on either ProxyAdmin (0xb688d5e73777DfaaDbD7c5Fe98Aee6F35CF20124 and 0x45727c03B46970C64E4039B546E6bd1F9c9d92ab), and no DEFAULT_ADMIN_ROLE on the Voter, GaugeRewarder or AlgebraFactory.

Aegas operates Nest's off-chain backend services under contract, including price feeds, reward accounting and event indexing. It holds the private key that produces EIP-712 signatures authorising reward claims; the corresponding on-chain signer address is 0x41676a3Ad52294fceF2e875e3EaB92884dbB0A7e. Limitation: this key authorises claims of rewards already accrued under on-chain accounting. It cannot mint NEST, alter allocations, move treasury assets, upgrade contracts, or change protocol parameters. It is replaceable by the 3-of-5 Safe, which holds DEFAULT_ADMIN_ROLE on the GaugeRewarder at 0xfF0124cf664240e5573282511042d7033C3f22eA.

Nest team: contract and admin powers.

The Nest team controls the core admin Safe at 0x6652173b0Cb3d96d8f0198bc49670440Dec69e79, a Gnosis Safe v1.3.0 with a 3-of-5 threshold. Method of authority: fixed-set majority. There is no veto right and no super-majority requirement. Signers are 0xD969e33695C1ef22F56409A04C14470aF864fE6d, 0xEaf38993240Ab0a5d4823eb8410bD11bB6c23CA5, 0xdB180c83029577A1Cb323542EC796Fa4cC7b8F51, 0x1CA8caF5197454A9eAbE05Db3A3c80897d5516A2 and 0xe8c4C070baa6117eB3186F8AE6ccEB7406707ea7.

That Safe is the sole holder of the PROPOSER, EXECUTOR, CANCELLER and TIMELOCK_ADMIN roles on the TimelockController at 0xFBcC128edfddb638B0939a67f6F505b37425F587, which enforces a 24-hour minimum delay on all implementation upgrades and owns both ProxyAdmins. No individual signer holds a timelock role and the executor role is not public. The Safe also holds DEFAULT_ADMIN_ROLE on the Voter, GaugeRewarder and AlgebraFactory, POOLS_ADMINISTRATOR on the AlgebraFactory, and is owner() of the VotingEscrow at 0x2f2Ae07e3cc3391A2E27825652BA8DcdD5412074. Actions under those direct roles are immediate and not timelocked; only upgrades carry the 24-hour delay.

A separate 2-of-3 Safe at 0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827 is owner() of the Minter at 0x574f6865140e6929bDed24596D78a8D9c07E356d and can call setTeamRate() and setVoter() with no timelock delay.

Pause authority: none. No pause, unpause, freeze, halt, blacklist or emergency-stop function exists in the NEST token, Minter, Voter, VotingEscrow, AlgebraFactory or GaugeRewarder. No party can halt trading, freeze transfers or block withdrawals. The only circuit breaker is Voter.killGauge(address) / reviveGauge(address), which stops emissions to a single gauge and does not affect transfers, swaps, LP withdrawals or veNEST unlocking.

veNEST holders have no authority over contract or admin changes. veNEST voting directs emissions only. There is no governance executor, proposal system, veto, or super-majority mechanism available to tokenholders.

Single-key authority disclosure. In addition to the 3-of-5 Safe, the individual key 0xD969e33695C1ef22F56409A04C14470aF864fE6d holds GOVERNANCE_ROLE on the Voter at 0x566bdc5444fd5fe5d93ec379Bd66eC861ddbA901 in its own right. Method of authority: unilateral single signer, no threshold and no timelock. This key is held by Nest.

Giga corp controls no powers. Arrangement expired as of March, 2026.

(d) Compensation and material economic arrangements

The software development agency received 1,466,705 veNEST tokens with a 6-month lock and linear vest. The marketing agency received 6,252,795 veNEST tokens with a 6-month lock and linear vest. Protocol-linked economics are not routed to these agencies through a separate off-chain payment arrangement; any protocol-generated value is available through the same veNEST mechanism applicable to tokenholders who lock tokens and participate in voting. Under that mechanism, participating veNEST holders share 100% of on-chain rewards based on veNEST vote power, including trading fees, voting incentives, and HYPE generated via the HYPE Engine Vault. veNEST voters receive 100% of trading fees generated by pools they support with votes, distributed through smart contracts, with fees delivered at the end of each epoch to veNEST holders who vote. Protocols may also provide voting incentives to attract veNEST votes toward their liquidity pools, and those incentives are paid directly to veNEST holders who vote for those pools.

Token Supply & Allocation

Initial Allocation

Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV. The table is the final answer.

Ticker	Date	Allocation Category Name	Recipient Type	Allocation %	Allocation Tokens	TGE Unlock %	TGE Unlock Tokens	Cliff Months	Cliff Unlock %	Linear Vesting Months	Cadence Months	Circulating Treatment	Notes on what each category is used for	If applicable: Contract / Wallet address
NEST	11/27/2025	HYPE Engine	Treasury	0.219832571095219	400000000	0	0	0	0	0	1	Yes	Protocol-owned permanently max-locked veNEST NFT held in a 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08). Uses veNEST voting rewards to buy HYPE and distribute it to lockers via HYPE Spring and the HYPE Engine Vault. No unlock is ever scheduled, so it is structurally outside circulating supply. Holds roughly 27% of veNEST supply. Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics	0xbA6f01324F61aD4F5997C44580CF21A80655B969
NEST	11/27/2025	Team	Insiders	0.0824372141607072	150000000	0	0	0	0	0	1	Yes	Permanently max-locked veNEST held in a 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08). No unlock is ever scheduled and the allocation does not contribute to circulating supply. Issuer confirms that as of 2025-12-07 there are no post-TGE employee token grants and no unvested or locked tokens attributable to post-TGE employees, so no post-TGE employee vesting schedule is in effect. Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics	0x90D39920c60953A96BfAAFbA55F909697F55a7cC
NEST	11/27/2025	Ecosystem Fund	Ecosystem	0.0549581427738048	100000000	0	0	0	0	0	1	Yes	Permanently max-locked veNEST NFT held in a 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08). Issuer confirms the same Safe also receives the weekly 5% emissions cut recorded on the Voting Incentives Reserve row. The shared address is intentional, one Safe holding two distinct pools, and is not a data error. Public docs describe this bucket as permanently locked veNEST. Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics	0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827
NEST	11/27/2025	Assistance Fund	Treasury	0.0549581427738048	100000000	0	0	0	0	0	1	Yes	Permanently max-locked veNEST held in a 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08). Collects voting rewards used for NEST buybacks, lock bonuses and future incentive programs at team discretion. The principal never unlocks. Public docs describe this allocation as NEST; issuer confirms it is held as permanently max-locked veNEST. Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics	0x0Ccd34Be3C5F4f905308B0eF898E870Fb7930354
NEST	11/27/2025	Growth Treasury	Treasury	0.0549581427738048	100000000	1	100000000	0	0	0	1	Conditional	Liquid NEST reserved in a 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08) for future development and growth and kept outside circulating supply per issuer docs. Conditional because deployment requires a multisig treasury decision rather than a time-based unlock. Issuer states any future contributor or employee compensation would be distributed as locked NEST under the same 6 month max-lock mechanics; no such grants have been issued to date. Issuer confirms approximately 28,000,000 NEST has been spent from this allocation since launch, leaving an on-chain balance of 72,033,536 against the 100,000,000 originally allocated when checked on 2026-09-08; the allocation figure is the initial grant, not the current balance. Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics	0xB59cd99f88cACc73adA8D7701197B1B3a7B9c6eC
NEST	11/27/2025	Fenix Airdrop	Community	0.0274790713869024	50000000	0	0	6	1	0	1	Conditional	Distributed to veFNX holders from Blast as max-locked veNEST recognising prior MetaDEX users. Issuer confirms a claim was required, with a claim deadline of 6 months after launch, 2026-05-27, coinciding with expiry of the 6 month max lock that ran from TGE. Conditional because a claim was required before tokens count as circulating. Treatment of any tokens left unclaimed at the deadline is not published. Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics
NEST	11/27/2025	Angel Round	Private / VC	0.0192353499708317	35000000	0	0	6	1	0	1	No	Raise at $20m FDV issued as max-locked veNEST (alignment-first capital), unlocking in full when the 6 month lock expired on 2026-05-27. Held in the shared raise 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08) alongside the Community and Echo rounds rather than a per-round vesting contract. Source conflict: issuer reports the raise split as Angel 3.5%, Community 1.5% and Echo 1.5% with Liquidity 3.5%; public docs show a coarser combined Raise 5% and Liquidity 5%. Issuer figures used as the more granular primary source. Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics	0x337330Ce02D9dc8f8B3493678c19C8aA0a55A201
NEST	11/27/2025	Initial Liquidity	Liquidity	0.0192353499708317	35000000	1	35000000	0	0	0	1	No	NEST seeding NEST trading pairs at TGE to ensure liquid trading conditions. Fully unlocked at TGE and freely tradeable, so counted as circulating. Source conflict: issuer reports 3.5%; public docs show a combined Liquidity 5%. Issuer figure used. Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics
NEST	11/27/2025	Community Round	Public / Sale	0.00824372141607072	15000000	0	0	6	1	0	1	No	Raise participation issued as max-locked veNEST, unlocking in full when the 6 month lock expired on 2026-05-27. Held in the shared raise 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08). Source: https://docs.usenest.xyz/nest-explained/2.7-tokenomics	0x337330Ce02D9dc8f8B3493678c19C8aA0a55A201
NEST	11/27/2025	Echo Round	Public / Sale	0.00824372141607072	15000000	0	0	3	0	3	1	No	Raise participation issued as liquid NEST subject to a 3 month cliff followed by a 3 month linear vest at monthly cadence, per issuer. The only allocation with a contractual vesting schedule rather than a veNEST lock. Held in the shared raise 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08). Source: issuer, and https://docs.usenest.xyz/nest-explained/2.7-tokenomics	0x337330Ce02D9dc8f8B3493678c19C8aA0a55A201
NEST	11/27/2025	LP Emissions	Emissions	0.427897643703813	778588253	0	0	0	0	10	1	No	New supply minted each weekly epoch and paid to liquidity providers in proportion to gauge vote weight. NEST is inflationary with no max supply. Cumulative mint through epoch 41 was 819,566,582, verified against on-chain totalSupply of 1,819,566,581.83 on 2026-09-08; this row is the 95% LP share of that mint. Modelled as a 10 month linear release from TGE to match the period over which it was actually minted, since the workbook has no continuous-emission input. This figure is a snapshot and increases every epoch. Claiming is permissionless and tokens are freely transferable, so treated as circulating. Source: https://docs.usenest.xyz/nest-explained/2.3-emissions
NEST	11/27/2025	Voting Incentives Reserve	Emissions	0.0225209285581395	40978329	0	0	0	0	10	1	Conditional	Issuer confirms 5% of each epoch's newly minted NEST is deposited to a 2-of-3 Gnosis Safe multisig (Safe v1.3.0, threshold and signer set verified on-chain 2026-09-08) and deployed as voting incentives to drive liquidity to partner and ecosystem pools. Conditional because deployment is a protocol decision, not a time-based unlock. 40,978,329 is 5% of the 819,566,582 minted through epoch 41 and is an approximation of the cumulative cut rather than a live wallet balance; the Safe held 0 NEST when checked on 2026-09-08, consistent with incentives already deployed. Shares an address with the Ecosystem Fund row; issuer confirms this is intentional, one Safe holding two distinct pools. Source: issuer, and https://docs.usenest.xyz/nest-explained/2.3-emissions	0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827

Vesting Insider Tokens

If there are no post-TGE token compensation plans, state explicitly they do not exist across each sub-question. If there are, explain each of (a)–(b) below.

(a) Post-TGE employee lock as % of total supply — State the current total amount of tokens locked attributable to post-TGE employees, expressed as a percentage of total supply.
(b) Typical post-TGE vesting schedule — Describe the standard vesting terms used for post-TGE grants, including: cliff length (or "no cliff"), vesting frequency (e.g., monthly/quarterly), and total duration.

(a) Post-TGE employee lock as % of total supply

As of December 7, 2025, 0% of total supply is locked or unvested attributable to post-TGE employees as of with token grants, and there are no tokens locked or unvested attributable to post-TGE employees. The corresponding percentage of total supply is not separately disclosed in this filing.

(b) Typical post-TGE vesting schedule

No post-TGE grants exist

Disclosure of Token Advisory Billings

Disclose current token-based compensation for external advisors and service providers (e.g., legal, marketing, technical, growth) funded from the on-chain treasury. Do not disclose individual payments to advisors receiving fiat-only compensation. If there are no advisors contracted in tokens then state across each sub-question that no token-based advisory compensation exists.

(a) Existence — Whether any such token-based payments or advisory commitments exist (or explicitly state that no token-based compensation for advisory commitments exist).
(b) Total token allocation — For all existing token-based advisors, disclose the total token allocation across all advisory services.
(c) Payer entity — For each existing token-based advisor, share the payer entity (e.g., Foundation, Labs/DevCo, DAO/treasury).
(d) Description of advisory/services — For each existing token-based advisor, provide a brief description of the advisory/services (e.g., "legal and regulatory advisory," "growth and BD support," "security advisory").

(a) Existence

Token-based payments to external service providers exist. A software development agency received 1,466,705 veNEST tokens with a 6-month lock and linear vest, and a marketing agency received 6,252,795 veNEST tokens with a 6-month lock and linear vest. The on-chain NEST mint, lock, and veNEST token transfer transaction is recorded at https://hyperevmscan.io/tx/0xe83a3d20c5813e239077e3fea066e9d0f8a7b97462fe72f816ae84b7f5c6e8a7.

(b) Total token allocation

Total 7,719,500 veNEST allocated.

Disclosed token-based service-provider allocations are 1,466,705 veNEST to the software development agency and 6,252,795 veNEST to the marketing agency, each with a 6-month lock and linear vest. Growth treasury made the payment 0xb59cd99f88cacc73ada8d7701197b1b3a7b9c6ec

(c) Payer entity

Existing token-based service-provider compensation is disclosed for a software development agency, which received 1,466,705 veNEST tokens with a 6-month lock and linear vest, and a marketing agency, which received 6,252,795 veNEST tokens with a 6-month lock and linear vest.

Payer entity is growth treasury 0xb59cd99f88cacc73ada8d7701197b1b3a7b9c6ec

(d) Description of advisory/services

The disclosed token-based service providers are a software development agency and a marketing agency. The software development agency provides software development services, and the marketing agency provides marketing services.

KOL Marketing Activities

Disclose ongoing KOL/influencer relationships that partially or fully received tokens for payment. You do not need to disclose KOL/influencers that do not receive tokens for payment. If no KOL engagements exist, state for each sub-question that no KOL engagements exist.

(a) Existence & scope — State plainly whether KOLs receive tokens for payment.
(b) Usernames & roles — List usernames/handles (with platforms) for KOLs that received token-based compensation and describe the nature of their activities. Legal names are not required.
(c) Token allocation & vesting/locks — Provide the aggregate token amount across all such arrangements and summarize vesting, lock, or release terms.

(a) Existence & scope

Yes

(b) Usernames & roles

Intern (@hypEconomist) - introductions to HyperEVM network and social media awareness on X

(c) Token allocation & vesting/locks

received 574,420 of 6month locked veNEST

Labelled Unissued & Operational Token Wallets

For each wallet that holds Unissued Tokens or is essential to operations (e.g., foundation, operations, treasury, investor reserve), disclose:

(a) A category label explaining the wallet's primary function.
(b) chain the wallet is on.
(c) The unique address of the wallet.
(d) The mechanism of control (e.g., DAO, multisig).
(e) One verification link to a blockchain explorer.

Definition: Unissued Supply = tokens authorized by the contract but not yet issued to any party; where they sit (treasury or mint authority) does not change that they are unissued. For instance: if a token has a total supply cap of 1B, and 400M tokens have been issued to investors, the team, and users (whether vested or unlocked), then those 400M count as issued supply. The remaining 600M are authorized but unissued supply, even if they are already minted into a DAO treasury wallet.

Title	Primary Function	Chain	Address	Control Mechanism	Explorer Link
HYPE Engine Vault	Automatically votes for veNEST depositors, compounds voting rewards into more veNEST and max locks weekly	HyperEVM	0x96F7b8BA7580d3E510B0Fb3F0E135a743d8eb17a	3/4 multisig using Safe for nest-controlled veNEST.	https://hyperevmscan.io/address/0x96F7b8BA7580d3E510B0Fb3F0E135a743d8eb17a
HYPE Engine	Receives voting rewards and converts these revenues into HYPE exposure, and issues HYPE as a reward stream for veNEST participants in the HYPE Engine Vault.	HyperEVM	0xbA6f01324F61aD4F5997C44580CF21A80655B969	3/4 multisig using Safe for nest-controlled veNEST.	https://hyperevmscan.io/address/0xbA6f01324F61aD4F5997C44580CF21A80655B969
Team wallet	Permanently max-locked veNEST. Votes weekly to receive voting rewards and funds team operations.	HyperEVM	0x90D39920c60953A96BfAAFbA55F909697F55a7cC	3/4 multisig using Safe for nest-controlled veNEST.	https://hyperevmscan.io/address/0x90D39920c60953A96BfAAFbA55F909697F55a7cC
Ecosystem Fund	Permanently max-locked veNEST. Votes to send emissions to ecosystem token pairs, uses revenues for NEST buybacks and growth initiatives.	HyperEVM	0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827	3/4 multisig using Safe for nest-controlled veNEST.	https://hyperevmscan.io/address/0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827
Assistance Fund	Permanently max-locked veNEST. Votes weekly to receive voting rewards used for NEST buybacks and growth initiatives	HyperEVM	0x0Ccd34Be3C5F4f905308B0eF898E870Fb7930354	3/4 multisig using Safe for nest-controlled veNEST.	https://hyperevmscan.io/address/0x0Ccd34Be3C5F4f905308B0eF898E870Fb7930354
Growth Treasury	Growth Treasury consisting of liquid NEST that could be used in the future to compensate newly onboarded contributors or employees through locked NEST distributions.	HyperEVM	0xB59cd99f88cACc73adA8D7701197B1B3a7B9c6eC	3/4 multisig using Safe for nest-controlled veNEST.	https://hyperevmscan.io/address/0xB59cd99f88cACc73adA8D7701197B1B3a7B9c6eC
Raise wallet	Received all raised funds from angels, community, and echo rounds. Funded initial protocol owned liquidity and marketing expenses	HyperEVM	0x337330Ce02D9dc8f8B3493678c19C8aA0a55A201	3/4 multisig using Safe for nest-controlled veNEST.	https://hyperevmscan.io/address/0x337330Ce02D9dc8f8B3493678c19C8aA0a55A201
5% per epoch NEST emissions receiver	Receives 5% of newly minted NEST tokens each week for voting incentives intended to drive liquidity to partner and ecosystem pools.	HyperEVM	0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827	3/4 multisig using Safe for nest-controlled veNEST.	https://hyperevmscan.io/address/0x8CE4d7F93f8A55E6d120F302C0BcCE502B640827
Fenix Airdrop Merkle distributor	On-chain Merkle distributor for the Fenix Airdrop, through which eligible veFNX holders on Blast receive max-locked veNEST allocations encoded in the airdrop Merkle distribution. Contract controlled	HyperEVM	0xB97B9217B55F322F7105f34777Af9F63B3b720A6	Contract-controlled	https://hyperevmscan.io/address/0xB97B9217B55F322F7105f34777Af9F63B3b720A6
Contract owner Gnosis safe	Protocol contract changes	HyperEVM	0xD969e33695C1ef22F56409A04C14470aF864fE6d	3/5 Gnosis Safe multisignature from the nest team.	https://hyperevmscan.io/address/0xD969e33695C1ef22F56409A04C14470aF864fE6d

Transactions & Market Structures

Market Maker Agreements & Deals

Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly. For each market maker, include in a table:

(a) Market maker's name — the market maker's name;
(b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
(c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
(d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model).

If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for (b).

Market Maker Name	Token Allocation Committed	Term Duration	Structure Name
No market maker deals exist.	$250,000 of NEST and $250,000 of WHYPE was deposited by nest to nest exchange full range liquidity pool at TGE.	Not applicable.	Not applicable.

Exchange Agreements & Deals

Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:

(a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
(b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
(c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
(d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.

If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.

Exchange Name	Token Allocation Committed	Term Duration	Native Token Listing Fees
Nest Exchange full range liquidity pool, funded with NEST and WHYPE	Initial Liquidity allocation: 35,000,000 NEST, equal to 3.5% of the supply	Deposited into nest liquidity pool at TGE. Open ended with no lockup	No listing fees were paid.

Liquidity Deals and Market Activity

If a category does not exist or is not applicable, make that clear in plain language.

(a) Token repurchases or secondary-market accumulations (if any) — Source of funds, treatment (burn, treasury retention, POL, redistribution, or other), policy controller (who can change the secondary-market accumulation strategy), and whether those tokens may be re-used, re-issued, or permanently removed from circulation.
(b) Protocol-owned liquidity (POL) (if any) — Where deployed, total token or dollar size across deployments, policy controller (who can change the POL strategy), and unwind/exit policy.
(c) Liquidity deals / purchased TVL (if any) — The total size across all deals, and where the capital participates - no counterparty names needed.
(d) Token-secured loans/lines (incl. against unissued tokens) (if any) — Principal, gross position size, collateral, counterparties, and unwind/exit policy.

(a) Token repurchases or secondary-market accumulations (if any)

The disclosed secondary-market accumulation mechanism is the HYPE Engine. A portion of protocol rewards, initially approximately 40% of veNEST voting rewards, flows into the HYPE Engine. The HYPE Engine wallet receives 100% of all veNEST voting rewards directed to the HYPE Engine NFT, converts these revenues into HYPE exposure, acquires HYPE, and issues HYPE as a reward stream for veNEST participants who lock NEST in the HYPE Engine Vault.

The HYPE Engine Vault is an automated voting strategy where users delegate their veNEST to the vault, it votes and buys back/compounds users' veNEST with rewards. Users in the HYPE Engine Vault receive HYPE bonuses from the HYPE Engine veNEST for locking new NEST each epoch.

The Assistance Fund veNEST also uses protocol rewards to buyback NEST from the secondary-market. Accumulated NEST can be locked to increase the Assistance Fund voting power or distributed to protocol liquidity or new nest growth initiatives (ex-team).

Policy controller is the nest CEO. HYPE may be reused at the team's discretion and the policy can change at the team's discretion.

(b) Protocol-owned liquidity (POL) (if any)

At TGE, nest deposited $250,000 of NEST and $250,000 of WHYPE to the Nest Exchange full-range liquidity pool.

Total POL is $575,000 as of Sep 8, 2026 on usenest.xyz liquidity pools.

Policy is controlled by CEO and they have rights to withdraw POL at any time.

(c) Liquidity deals / purchased TVL (if any)

None

(d) Token-secured loans/lines (incl. against unissued tokens) (if any)

none exist

Resource Disclosures

Prior Token Sales & Fundraising

Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:

(a) Series Name;
(b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.);
(c) Date of sale (at least month & year);
(d) Number of tokens sold (or % of total supply);
(e) Vesting schedule.

If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").

Series Name	Investment Instrument	Date Of Sale	Number of tokens sold	Vesting Schedule
Angel Round	SAFT	Closed Oct. 15, 2025	35,000,000 max locked veNEST; 3.5% of initial allocation denominator applies (1B supply)	6-month locked veNEST
Echo Round	SAFT	Closed Nov. 11, 2025	15,000,000 NEST; 1.5% of initial allocation denominator applies (1B supply)	3-month cliff and 3-month vest NEST
Community Round	Direct Sale	Closed Nov. 14, 2025	15,000,000 max locked veNEST; 1.5% of initial allocation denominator applies (1B supply)	6-month locked veNEST

Operational Funding, Economic Flows, and Resource Provisioning

Provide a narrative description of the Project's material funding sources, economic flows, and operational provisioning, broken out by entity: Foundation, Lab/DevCo, and DAO. If an entity does not exist, state that explicitly.

(a) Entity existence — Explicitly state whether each of Foundation, Lab/DevCo, and DAO exists.
(b) Material sources of funding or economic inflows — For each existing entity, describe its primary sources of operational funding or economic inflows, if any (e.g., service fees, grants, donations, treasury reserves, token reserves, staking rewards, validator/sequencer income, partnership payments, retained revenue, or other protocol-related receipts).
(c) Operational use of resources — For each existing entity, briefly describe how those resources are generally used (e.g., development, operations, security, ecosystem support, grants, liquidity support).
(d) Onchain Resource Usage — For each existing entity, provide links to public dashboards and token holder relations reports that help explain on-chain financial activity, treasury activity, fee flows, rewards, or other protocol-controlled resources. Make certain to explain what each link is for.

(a) Entity existence

Foundation: Nest Exchange has no Foundation. Lab/DevCo: Nest Exchange has no Labs and is an entirely on-chain business with no legal wrapper. DAO: veNEST holders represent the on-chain economic and governance layer of the project.

(b) Material sources of funding or economic inflows

Nest Exchange has no Foundation or Labs and is an entirely on-chain business with no legal wrapper. The on-chain economic and governance layer is represented by veNEST holders, and veNEST is the only entity that receives protocol revenue. veNEST revenue streams are generated entirely by on-chain economic activity: weekly DEX trading fees are fully distributed at the end of each epoch to veNEST holders who vote, and protocols may provide voting incentives that are paid directly to veNEST holders who vote for those pools. The project states that there is 100% revenue sharing with no protocol fee extraction. The HYPE Engine wallet receives 100% of all veNEST voting rewards directed to the HYPE Engine NFT, converts those revenues into HYPE exposure, and issues HYPE as a reward stream for veNEST participants. The protocol also maintains a Growth Treasury consisting of liquid NEST, which could be used in the future to compensate newly onboarded contributors or employees. Nest raised $670,000 in an Angel round, $150,000 in an Echo round, and $120,000 in a Community round, each at a $20 million FDV.

(c) Operational use of resources

Nest Exchange has no Foundation or Labs. veNEST holders represent the on-chain economic and governance layer of the project, and veNEST is the only entity that receives protocol revenue. Operationally, weekly DEX trading fees are fully distributed to veNEST holders who vote, and voting incentives may be provided by protocols and paid directly to veNEST holders who vote for those pools. The HYPE Engine converts revenues into HYPE exposure and issues HYPE as a reward stream for veNEST participants. The protocol maintains a Growth Treasury consisting of liquid NEST, which could be used in the future to compensate newly onboarded contributors or employees, with any such compensation distributed as locked NEST. Each week, 5% of newly minted NEST tokens are deposited to the NEST emissions receiver wallet for voting incentives intended to drive liquidity to partner and ecosystem pools. At TGE, nest deposited $250,000 of NEST and $250,000 of WHYPE to the nest exchange full range liquidity pool. Operational provisioning also included allocations to a software development agency and a marketing agency, which received 1,466,705 veNEST and 6,252,795 veNEST, respectively, each with a 6-month lock and linear vest.

(d) Onchain Resource Usage

Nest Exchange has no Foundation or Labs and is an entirely onchain business with no legal wrapper. The on-chain economic and governance layer is represented by veNEST holders, and veNEST is the only entity that receives protocol revenue.

Public resources for on-chain resource usage include:

https://nest-supply.netlify.app/ — provides clickable links to wallets and NEST supply.
https://docs.usenest.xyz/key-features/tokenomics — discloses the initial allocation.
https://docs.usenest.xyz/key-features/for-venest-lockers — documents governance rights for tokenholders.
https://hyperevmscan.io/tx/0xe83a3d20c5813e239077e3fea066e9d0f8a7b97462fe72f816ae84b7f5c6e8a7 — records the onchain NEST mint, lock, and veNEST token transfer transaction.
https://app.usenest.xyz/airdrop — allows the Fenix Airdrop to be checked and claimed.

Nest will provide ongoing and quarterly updates to tokenholders via live dashboards covering growth KPIs, token issuance, token value capture, and any additional expenses, and commits to publishing offchain financial reports detailing assets, revenue, and expenses.

Previous Exploits Affecting The Native Token

If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").

(a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
(b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
(c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
(d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
(e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
(f) References — Link(s) to post-mortem/advisory/PR.