Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
GVNR focuses on BTCFi: unlocking the economic value of Bitcoin inside DeFi without forcing holders to sell, wrap, or bridge their BTC. Selling Bitcoin exits the position and can create unfavorable taxable events depending on jurisdiction. Centralized lenders take custody and introduce rehypothecation and counterparty risk. Wrapped or bridged BTC is typically an IOU on another chain and inherits bridge-attack risk. GVNR’s approach is permissionless and self-custodial: holders keep native Bitcoin exposure while using it as collateral in DeFi (via GVNR Diamond Hands to mint overcollateralised UCD), rather than handing assets to a custodian or relying on vulnerable bridges.
(b) Operational priorities
GVNR’s near-term operational priority is BTCFi: shipping and scaling products that put native Bitcoin to work in DeFi without selling, wrapping, or bridging. Flagship focus is GVNR Diamond Hands — Bitcoin-native borrowing against self-custodial BTC vaults, minting overcollateralised UCD so holders unlock liquidity while keeping BTC exposure. Next is expanding BTC yield on native Bitcoin exposure, led by Diamond Hands Carry — delta-neutral yield on minted UCD, credited back in Bitcoin (projected 6%+ in BTC; not guaranteed; fee model TBD) — alongside continued product and protocol work that supports permissionless BTCFi.
Ongoing development and operations are expected to be funded primarily by protocol product fees (principally UCD fees from Diamond Hands and future BTCFi products) once material revenue exists. A fee waterfall (operations and reserves before staking rewards and The Furnace) is designed but not operative today — Diamond Hands is newly launched and is not yet generating material fee flow. Day-to-day product and protocol development is carried out by the GVNR core team under GVNR DAO LLC, authorised under the current member-managed Operating Agreement (MM OA). $GVNR holders do not presently set protocol or fee policy; any holder governance of fee / Furnace parameters is intended after adoption of a Token Operating Agreement (Token OA). Intended burn intensity on eligible fees is a theoretical path from roughly 25% toward just over 90% over time, subject to operating realities.
(c) High-level project overview
GVNR is a BTCFi-focused protocol that unlocks Bitcoin’s economic value in DeFi without selling, wrapping, or bridging native BTC. The flagship product, GVNR Diamond Hands, lets holders keep Bitcoin in self-custodial vaults on Bitcoin L1 while minting overcollateralised UCD (an Ethereum Mainnet stablecoin backed by that BTC collateral). Each loan has its own isolated vault; no third party, including GVNR, can move the user’s Bitcoin.
Beyond borrowing, GVNR’s product roadmap expands BTC yield while holders keep Bitcoin exposure — notably Diamond Hands Carry (delta-neutral yield on minted UCD, credited back in Bitcoin; projected 6%+ in BTC, not guaranteed; fee model TBD).
$GVNR is the governance and value-accrual token of GVNR DAO LLC. Today, company control sits with the Managing Member under the current member-managed Operating Agreement (MM OA). Planned, a Token Operating Agreement (Token OA) would let holders participate in governance (including fee and Furnace buy-and-burn policy on burn-eligible surplus). Protocol fees are intended to buy $GVNR on the open market and burn it under that policy once the fee waterfall is operative and operations are covered — not as a live holder-set policy today.
Public references:
• Token docs / Token Paper: https://gvnr.xyz/#token
• Diamond Hands: https://diamondhands.credit
• Diamond Hands app: https://app.diamondhands.credit/
• Etherscan (GVNR): https://etherscan.io/token/0xfc60fc0145d7330e5abcfc52af7b043a1ce18e7d
• Contract: 0xfc60fc0145d7330e5abcfc52af7b043a1ce18e7d
• CoinGecko: https://www.coingecko.com/en/coins/gvnr
• X: https://x.com/gvnrdao and https://x.com/diamondhandsai
• Legal wrapper (MiDAO): https://midao.org
• GitHub: closed / private; available on request only
(d) Primary token functions
$GVNR is a scarce, fixed-supply governance and value-accrual token (max 20,000,000) designed around long-term scarcity and deflation. Primary functions:
(1) Governance (planned) — $GVNR is designed as the governance token of GVNR DAO LLC. Holders do not presently set protocol policy under a Token Operating Agreement; company decisions today are under the current member-managed Operating Agreement (MM OA). A Token OA is planned so holders may in future set protocol policy, including fee waterfall and Furnace burn intensity on burn-eligible surplus.
(2) Product-funded value accrual — protocol fees from BTCFi products (primarily UCD fees from GVNR Diamond Hands) are intended to enter a fee waterfall under GVNR DAO LLC (operations and reserves first, then staking rewards and The Furnace). That waterfall is not operative today.
(3) The Furnace — burn-eligible surplus is designed to buy $GVNR on the open market and burn it as adoption grows, once fees flow and operations are covered.
(4) Staking — a locking/staking path exists for long-term holders (entry for new stakers turned off in Q2 2026; $GVNR already deposited remains locked until February 2027; locked or staked tokens confer no additional governance rights beyond the lock itself at this time). Near-term demand ties to BTCFi product usage rather than gas abstraction.
(e) Control surface reliance
Governance and control are expected to evolve over time.
Today, under the certified GVNR DAO LLC Operating Agreement, the Company is member-managed: ordinary and fundamental company decisions for the legal wrapper are made through the membership / Managing Member structure (not by a separate Foundation board).
Over time, the Company intends to move toward greater tokenholder control by adopting a Token Operating Agreement (or equivalent decentralized governance arrangement) so that governance and control decisions increasingly rest with $GVNR holders rather than the current Managing Member model. Until that change is effected in the governing documents, the Managing Member / member-managed structure remains in force. Separate fee or Furnace parameter choices, if and when made under a future Token OA, are not themselves a change to who controls the Company until that Token OA is in force.
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 |
|---|---|---|
N/A | No DevCo entity exists |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
Andrew Needham | Managing Member - Regulation and Compliance | Regulatory compliance / financial structuring; co-founded Cayman bank and trust; multi-billion AUM experience. |
Cynan Rhodes | Technical Architect | Blockchain systems, decentralization, scalable systems. |
Robert Olsen | Commercial Development | Multi-billion AUM Business development, ops, revenue growth |
Tim Jones | Treasury | Treasurer; ~20 years capital markets; risk, liquidity, tokenization. |
Rufus Round | Sales | Investment management / fintech / digital assets; leads sales and OTC. |
Benjamin Whitby | Protocol Lead | Web3 Compliance/capital markets (MiFID, Dodd-Frank); crypto advocate since 2013. |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
N/A | No separate on-chain / tokenholder DAO body at submission. “DAO” in GVNR DAO LLC is the Primary Foundation’s legal name only (member-managed OA today; Token OA planned). |
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
No DAO exists as a separate on-chain / tokenholder governance body at submission. Accordingly, no DAO owns or controls protocol IP. “DAO” in GVNR DAO LLC is the Primary Foundation’s legal name only. All intellectual property relevant to the protocol is owned and controlled by GVNR DAO LLC (Primary Foundation). Control of that LLC IP sits with the Managing Member under the current member-managed OA; a Token OA is planned. Further license detail is set out under Primary Foundation IP (Q4b) and at https://app.diamondhands.credit/legal/license.
(b) Contract/admin powers
No separate on-chain / tokenholder DAO body at submission. Contract and administrative powers that bind the protocol are exercised for GVNR DAO LLC as Primary Foundation under the Managing Member OA today (concrete pause/upgrade/governance-executor paths in Q4e). Token OA may shift tokenholder control later.
(c) Locked-token rights (conditional)
A locking / staking contract was put in place to reward long-term $GVNR holders. Entry for new stakers was turned off in Q2 2026. $GVNR already deposited in those contracts remains locked until February 2027. Locked or staked tokens confer no additional governance or economic rights beyond the lock itself at this time.
(d) Current tokenholder governance rights and economic arrangements
No separate on-chain / tokenholder DAO body at submission (“DAO” in GVNR DAO LLC is the Primary Foundation’s legal name only). Tokenholders have no current governance rights under a Token OA. Tokenholders have no current operative economic rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. Governance and economic rights will be defined within the future Token Operating Agreement. Until then, company-level control remains with the Managing Member under the current OA (see Q3e).
(e) Control surface reliance
Governance and control are expected to evolve over time.
Today, under the certified GVNR DAO LLC Operating Agreement (MM OA), the entity is member-managed: ordinary and fundamental company decisions for the legal wrapper are made through the membership / Managing Member structure (not by a separate Foundation board). Tokenholders do not presently exercise protocol governance rights under a Token OA (see Q3d).
Over time, the entity intends to adopt a Token Operating Agreement (or equivalent decentralized governance arrangement). Following that move, governance and control decisions — including any rights over fee and Furnace parameters — are expected to rest increasingly with $GVNR holders rather than the current Managing Member model. Until that change is effected in the governing documents, the Managing Member / member-managed structure remains in force. Separate parameter changes are not themselves a change to who controls the Company unless and until the Token OA so provides.
(f) Dissolution authority
No separate on-chain / tokenholder DAO dissolution vote at submission. Dissolution / wind-up of GVNR DAO LLC sits with the Managing Member under the current OA and applicable MiDAO / RMI process (not an on-chain Council vote). A Token OA may change this later.
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 is directly involved in the issuance of the native token at launch.
- (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
For the purpose of this disclosure, GVNR DAO LLC (a Marshall Islands MiDAO DAO LLC) may be considered the Primary Foundation. GVNR DAO LLC is the entity directly involved in the issuance of the native $GVNR token at launch. There is no separate Foundation wrapper besides GVNR DAO LLC; “DAO” in the company name is the legal entity name only. Today the Company is governed under the current member-managed Operating Agreement (MM OA): the Managing Member authorises company activities. A Token Operating Agreement (Token OA) is planned so control may increasingly rest with $GVNR holders over time.
(b) IP ownership & control
The Primary Foundation is GVNR DAO LLC. GVNR DAO LLC owns and controls the protocol IP associated with GVNR / Diamond Hands, including:
(1) source code and smart-contract materials under the publicly available license notice;
(2) designs and protocols covered by that notice;
(3) the Diamond Hands application and materials at https://app.diamondhands.credit/ and https://app.diamondhands.credit/legal/license;
(4) documentation and Token Paper at https://gvnr.xyz/#token;
(5) primary web properties https://gvnr.xyz , https://diamondhands.credit/ and https://app.diamondhands.credit.
The entity GVNR DAO LLC also owns and controls the GVNR and Diamond Hands names, logos, trademarks, and other associated brand assets used by the project. License terms: © GVNR DAO LLC, 2026; except as otherwise in a specific source-file header, IP is published for informational purposes only; no license, reproduction, or distribution right is granted or implied; all rights reserved; provided AS IS as stated on https://app.diamondhands.credit/legal/license (IPFS ipfs://bafkreigunb4phugonefe66by524nhnrgrpol4233ytg7e7eg7qomhy3s3a).
Control of that IP sits with the Managing Member under the current MM OA; a Token OA is planned.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
There is no separate on-chain / tokenholder DAO body at submission. GVNR DAO LLC is the Primary Foundation (“DAO” is in the legal name only). Under the current MM OA, the Managing Member authorises company activities. Current authority is as follows:
(1) Entity governance — Managing Member authorisation under the current MM OA; no separate tokenholder voting threshold today.
(2) Treasury actions — Managing Member authorisation under the current MM OA; no separate tokenholder threshold today.
(3) Protocol-controlled resources, including revenue and fee burns — Managing Member authorisation under the current MM OA; no separate tokenholder threshold today. Where related configuration is also executed on-chain, the Safe / role thresholds in Q4e apply as operational security controls only (see Q4e).
(4) Token administration — Managing Member authorisation under the current MM OA; on-chain execution thresholds as in Q4e where applicable, as security controls only.
(5) Reward parameters — Managing Member authorisation under the current MM OA; no separate tokenholder threshold today.
On-chain multisig / role thresholds referenced in Q4e increase execution security. They do not change who governs the Company today under the MM OA, and they are not a substitute for tokenholder / Token OA governance.
GVNR DAO LLC plans to evolve toward a Token OA when appropriate. Until then, the MM OA remains the governing approval framework for the legal wrapper.
(d) Powers over DevCo
There is no separate DevCo. GVNR DAO LLC is the Primary Foundation and holds all IP. GVNR DAO LLC’s authority over its own activities is exercised through the Managing Member under the current MM OA.
(e) Contract/admin powers
GVNR DAO LLC is the Primary Foundation: a single-entity MiDAO / Marshall Islands DAO LLC (“DAO” is in the legal name only; no separate Foundation wrapper). Contract and administrative powers that bind the Primary Foundation are exercised for GVNR DAO LLC as follows. For security, wallet and contract addresses are withheld; further details available on request.
Today (MM OA): the Managing Member authorises exercise of these powers under the current member-managed Operating Agreement. On-chain execution uses the concrete Safe / role thresholds below. There is no separate tokenholder “DAO super-majority” vote controlling the legal entity at submission.
The Safe and role thresholds below increase execution security (who can push a transaction). They do not impact governance at this point: governance of the legal wrapper remains Managing Member authorisation under the current MM OA. A Token OA may later introduce tokenholder approval standards; until then, these n-of-m paths are not a governance model change.
Planned (Token OA): once adopted, approval for these actions is expected to move toward a $GVNR holder / Token OA–defined super-majority. Until that change is effected in the governing documents, treat Token OA thresholds as forward-looking.
1. Pause authority (Primary Foundation / GVNR DAO LLC)
- What: Emergency pause and unpause of Diamond Hands modules gated to EMERGENCY_PAUSE_ROLE (including UCDController pause/unpause), and PSM pause/unpause via PAUSER_ROLE where applicable.
- Who / role: EMERGENCY_PAUSE_ROLE and, for SimplePSMV2, PAUSER_ROLE, held by Foundation-designated multisig operators on behalf of GVNR DAO LLC.
- Method / threshold: Managing Member authorisation under the current MM OA. On-chain, the path is role-gated to EMERGENCY_PAUSE_ROLE / PAUSER_ROLE and is not timelocked; MultisigRequired is No on the role matrix for UCDController pause/unpause (security / execution control, not a separate governance threshold under the MM OA).
2. Upgrade authority (Primary Foundation / GVNR DAO LLC)
- What: UUPS _authorizeUpgrade on core contracts (UCDToken, UCDController, SimplePSMV2, PriceFeedConsumer, PositionManager, LoanOperationsManager, CollateralManager); UpgradeValidator approveImplementation / revokeImplementationApproval / updateValidationParameters; validateUpgrade.
- Who / role: DEFAULT_ADMIN_ROLE for UUPS authorisation (must differ from day-to-day ADMIN_ROLE); ADMIN_ROLE / VALIDATOR_ROLE for UpgradeValidator steps.
- Method / threshold: Managing Member authorisation under the current MM OA, plus on-chain execution at 2-of-6 for the DEFAULT_ADMIN_ROLE / upgrade super-admin path (Safe label “Admin Role 1”) as a security control, not a governance threshold under the MM OA. Selected follow-on admin module/parameter changes may also use a 24-hour propose → co-sign → execute path after approval.
3. Governance-executor authority (Primary Foundation / GVNR DAO LLC)
- What: Execution of Primary Foundation administrative and governance decisions affecting the legal wrapper and protocol configuration, including ADMIN_ROLE configuration (UCD controls, fees/caps, module wiring) and Managing Member authorisation of company activities under the current MM OA.
- Who / role: Managing Member under the MM OA (legal wrapper); ADMIN_ROLE for day-to-day on-chain admin execution; DEFAULT_ADMIN_ROLE for super-admin / role-admin actions.
- Method / threshold: Managing Member authorisation under the current MM OA, plus on-chain execution at 1-of-3 for ADMIN_ROLE administrative actions (Safe label “Admin_Role”) and 2-of-6 for DEFAULT_ADMIN_ROLE super-admin actions (Safe label “Admin Role 1”) as security controls, not governance thresholds under the MM OA.
The Primary Foundation (GVNR DAO LLC) therefore holds pause, upgrade, and governance-executor powers under the MM OA today, with the concrete on-chain security thresholds above.
(f) Current economic arrangements and distribution policies
The Primary Foundation exists: it is GVNR DAO LLC. GVNR uses a single-entity structure — there is no separate Foundation legal wrapper besides GVNR DAO LLC, which is also the MiDAO / Marshall Islands DAO LLC involved in native $GVNR issuance at launch.
Fee waterfall — not operative today. The protocol app (GVNR Diamond Hands at diamondhands.credit) is newly launched and is not yet generating material revenue to fund a live fee waterfall. In early phases, any fees that do arise may be required to boost liquidity incentives or other initiatives to address the cold-start problem. Once fees are flowing and operations are covered, buy-and-burn via the Furnace can begin without impairing protocol operations.
Intended allocation (forward-looking / theoretical). When the waterfall is operative, the objective is to move from roughly 25% of eligible fees toward burn / Furnace, scaling toward just over 90% of eligible fees burnt over time, with the balance toward operations and reserves. These figures are theoretical targets and may need to be adjusted in light of operating realities. Company-level authorisation under the current MM OA remains with the Managing Member. Tokenholders may influence Furnace / fee-burn parameters in future under a Token OA; there is no explicit holder-control commitment at this time (see Q3d / Q3e).
Distributions to members / Managing Member / contributors. GVNR DAO LLC is organised as a not-for-profit entity: fees and protocol resources may not be extracted upward as dividends or profit distributions to LLC members, the Managing Member, or contributors. Once operations are covered, value is intended to flow into the ecosystem and GVNR tokenholders via the Furnace.
Further details available on request.
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 is directly involved in the issuance of the native token at launch.
- (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
Primary DevCo does not exist.
(b) IP ownership & control
Primary DevCo does not exist.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
Primary DevCo does not exist.
(d) Powers over Foundation
Primary DevCo does not exist.
(e) Contract/admin powers
Primary DevCo does not exist.
(f) Current economic arrangements and distribution policies
Primary DevCo does not exist.
Token Supply & Allocations
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.
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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
GVNR | 2025-06-25 | Launch & Staking | Emissions | 0.1 | 2000000 | 1.0 | 2000000.0 | 0 | 0.0 | 0 | 0 | No | Staking Position: 100% allocated at TGE and loaded to staking contracts; not free-trading while staked. | |
GVNR | 2025-06-25 | Claim Drops | Community | 0.05 | 1000000 | 0.8 | 800000.0 | 0 | 0.0 | 3 | 1 | Yes | Claim drops: approximately 80% unlocked at TGE, then to 100% by Month 3. | |
GVNR | 2025-06-25 | KOL Sales | Other | 0.01 | 200000 | 0.5 | 100000.0 | 0 | 0.0 | 18 | 1 | Yes | KOL / ambassador allocation (200,000 $GVNR): 50% at TGE plus 18-month linear monthly vesting. Allocated to GVNR wallets; KOLs did not purchase these tokens. | |
GVNR | 2025-06-25 | Liquidity | Liquidity | 0.02 | 400000 | 0.5 | 200000.0 | 0 | 0.0 | 18 | 1 | Yes | Liquidity / market-maker fund (400,000 $GVNR under Treasury3). Vesting Graph schedule: 50% at TGE plus 18-month linear. Historical DLP.Group 300,000 $GVNR call option (see Q8) was funded from this Market Maker Fund allocation (sent to DLP from Treasury3 after mint). Of this 400,000, 0.4% of total supply is shown on named DEX rows in Q9 (0.2% Carbon + 0.2% Uniswap); the remainder sits in this Liquidity schedule. Historical MM arrangement terminated; MEXC delisted 15 Dec 2025. | |
GVNR | 2025-06-25 | Treasury | Treasury | 0.08 | 1600000 | 0.5 | 800000.0 | 0 | 0.0 | 18 | 1 | Yes | Treasury (1,600,000 $GVNR): 50% at TGE plus 18-month linear. | |
GVNR | 2025-06-25 | Ecosystem | Ecosystem | 0.261055 | 5221100 | 0.5 | 2610550.0 | 0 | 0.0 | 18 | 1 | Yes | Ecosystem (grants, hackathons, airdrop builders, and related programs): approximately 50% at TGE plus 18-month linear. Includes Funding sub-allocations for hackathons, AI grants, developer grants, and airdrop builders, plus residual inventory mapped from the Vesting Graph. | |
GVNR | 2025-06-25 | Team | Insiders | 0.2825 | 5650000 | 0.0 | 0.0 | 6 | 0.6944 | 12 | 1 | Yes | Core Contributors: no unlock Months 0–5; approximately 69.44% cliff unlock at Month 6; then linear Months 6–18. Fully vested by 25 Dec 2026. | |
GVNR | 2025-06-25 | Public Sales | Public / Sale | 0.11410725 | 2282145 | 0.4870 | 1111385 | 0 | 0.0 | 18 | 1 | Yes | Public Sales allocation bucket (2,282,145 $GVNR). Only Republic Reg S and Reg D offerings (approximately 59,375 $GVNR) were sold to the public. The remainder is Future Public / Other Public inventory vesting to GVNR for future use (originally earmarked for a further public sale; that use remains under discussion). TGE unlock approximately 48.70% (1,111,385 tokens) equals 50% of the non-Republic portion; Republic sold-token vesting is disclosed separately in Q10 and differs by offering. Full circulating supply by 25 Dec 2026. | |
GVNR | 2025-06-25 | Private Sales | Private / VC | 0.08233775 | 1646755 | 0.0 | 0.0 | 6 | 0.7001 | 12 | 1 | Yes | Private Sales (1,646,755 $GVNR): Angel Round 1,291,395 + Discount Hero Round 205,360 + Public Runway Sale 53,000 + Partners, Backers and VC Sale 97,000. Public Runway was a follow-on to the private sale group at a discount to unblock the MEXC listing fee and rolls into this Private Sales category. Schedule: no unlock Months 0–5; approximately 70.01% cliff unlock at Month 6; then linear Months 6–18. Per-round legal vesting is disclosed in Q10 (Angel / Discount Hero fully vested by Month 18; Partners fully vested by Month 12). |
Airdrop Process
State the project's airdrop status plainly, and back it up:
- Never conducted and none planned for TGE: state so plainly.
- Planned but not yet executed: state the target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to balance or net position), and commit to publishing a recipient wallet list in a public channel and providing it to Blockworks quarterly until the initial TGE airdrop is fully completed.
- Already executed: state the covered user segments and the allocation method, and point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count.
Already executed: GVNR airdrops / claimdrops were distributed via Sablier smart contracts on Ethereum using Sablier vesting / claimdrop streams.
Eligible user segment: participants who completed the applicable protocol tasks in the related Galxe campaign(s), where applicable.
Allocation method: Airdrop allocations for the executed drop were calculated proportional to the number of points accumulated by each user on the Galxe campaign https://app.galxe.com/quest/GVNR (https://app.galxe.com/quest/GVNR?sort=Trending).
Execution/delivery was via Sablier claimdrops on Ethereum.
Per-address source remains https://app.sablier.com/vesting/search/ethereum?s=0xb363ae6d6941b7102ab9b09b82bd5da04ae8b4ad — Sablier Vesting Search on Ethereum for streams associated with 0xb363ae6d6941b7102ab9b09b82bd5da04ae8b4ad. It surfaces valid public per-recipient vesting/claimdrop stream data, including recipient, amounts, and claim status as shown in the Sablier UI / indexer.
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 |
|---|---|---|---|
DLP.Group (historical; terminated — no MM agreements live today). Call option explicitly tied to the MEXC GVNR/USDT listing. DLP.Group fronted the fiat; GVNR committed the token option. MEXC listing fee was USD 60,000 paid to MEXC (no $GVNR tokens to MEXC). | 300,000 $GVNR (1.5% of 20,000,000 max supply) | 6 months from MEXC listing (listed 25 Jun 2025 11:00 UTC; delisted 15 Dec 2025). Arrangement ended with delisting; no MM live today. | Call option |
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 |
|---|---|---|---|
Carbon DeFi (Ethereum) — GVNR/USDT; DEX organic; base 0xfc60fc0145D7330e5abcFc52AF7B043a1cE18e7d, quote USDT 0xdAC17F958D2ee523a2206206994597C13D831ec7; https://app.carbondefi.xyz/trade/market?base=0xfc60fc0145D7330e5abcFc52AF7B043a1cE18e7d&direction=buy"e=0xdAC17F958D2ee523a2206206994597C13D831ec7 | 0.2% | Organic trading only; no listing agreement | None |
Uniswap V4 (Ethereum) — USDT/GVNR (1% fee); pool 0x172511668d01451a4543bb9e609282e6237274f577c7d338c7b27bcc5b6a63be; https://app.uniswap.org/explore/pools/ethereum/0x172511668d01451a4543bb9e609282e6237274f577c7d338c7b27bcc5b6a63be | 0.2% | Organic trading only; no listing agreement | None |
MEXC (historical) — GVNR/USDT listed 25 Jun 2025 11:00 UTC (https://x.com/Alpha_MEXC/status/1937441011191677436); delisted 15 Dec 2025. No $GVNR tokens were provided to MEXC for the listing. MEXC required GVNR to appoint a market maker (DLP.Group). DLP.Group fronted the fiat; GVNR committed a 300,000 $GVNR call option to DLP.Group, explicitly tied to the MEXC listing (see also Q8 when unlocked). No CEX listing live now — DEX only. | none (0% of supply to MEXC). Related MM: 300,000 $GVNR (1.5%) call option to DLP.Group, tied to this listing — not an allocation to MEXC. | Listed 25 Jun 2025; delisted 15 Dec 2025. DLP.Group call option term: 6 months from listing, ended with delisting. | USD 60,000 listing fee paid to MEXC. No native-token ($GVNR) listing fee paid to MEXC or intermediaries. No tokens transferred to MEXC. |
Financial Disclosures & Risks
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 | GVNR SAFT | August 2024 | 1,291,395 | 50% locked for 6 months; remainder vesting so fully vested by Month 18. All $GVNR fully vested by 25 Dec 2026. |
Discount Hero Round | GVNR SAFT | Sept-Dec 2024 | 205360 | 50% locked for 6 months; remainder vesting so fully vested by Month 18. All $GVNR fully vested by 25 Dec 2026. |
Republic Sale (Reg S & Reg D) | Reg S & Reg D SAFT with Republic | June 2025 | 59,375 | Reg S: 3-month cliff, then 50% unlock + 9-month linear (fully vested by Month 12). Reg D: 12-month cliff then 100% (fully vested by Month 12). These differ from Q6 Public Sales aggregate TGE (~47.68% / 611,385 on the 1,282,145 allocation bucket, which is mostly Future Public inventory to GVNR — only ~59,375 Republic tokens were sold). |
Partners, Backers and VC Sale | GVNR SAFT / OTC | Sept 2025 - March 2026 | 2,980,339 | Includes Funding Partners round 97,000 + OTC/Bespoke 2,883,339. Partners round maps to Q6 Private Sales; OTC maps to Q6 Public Sales (Other Public / Future Public) / Treasury / Ecosystem — not the Private round. Vesting: 50% locked for 6 months; fully vested by Month 12. All $GVNR fully vested by 25 Dec 2026. |
Core Contributors | GVNR SAFT | June 2024 | 5,650,000 | No unlock Months 0–5; ~69.44% cliff unlock at Month 6; then linear Months 6–18 (12 months). Fully vested by 25 Dec 2026. |
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.
(a) Date & component affected
No exploits affecting tokenholders or protocol funds as of 2026-09-08.
(b) Exploit vector summary
No exploits affecting tokenholders or protocol funds as of 2026-09-08.
(c) Quantified impact
N/A no prior token-related incidents as of 2026-09-08.
(d) Remediation/response taken
N/A — no prior token-related incidents as of 2026-09-08.
(e) Current status
N/A — no prior token-related incidents as of 2026-09-08.
(f) References
No post-mortem, advisory, or PR references for prior token-related incidents are disclosed in this filing.
Material Risk Factors (Regulation, Technology, Token Economics)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
-
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
-
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
-
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
-
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
-
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
-
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
-
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
-
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
-
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
-
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
-
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
(a) Regulatory, Legal & Tax Risks
In addition to general crypto-asset and early-stage project risks, investors and tokenholders should consider securities and offering exposure disclosed in Q10.
The Public Runway Sale was conducted via Republic using Reg S and Reg D SAFT instruments (June 2025). Private / angel and other rounds used SAFT / OTC-style instruments as disclosed in Q10. Such offerings are speculative: investors may lose some or all capital; tokens or SAFTs may be illiquid with limited or no secondary market; resale may be restricted (including Reg S offshore / distribution-compliance limits and Reg D transfer restrictions for U.S. persons); token utility, delivery timing, and securities characterisation can be uncertain; and ongoing issuer disclosure under Reg D / Reg S is more limited than for registered public companies. Investors should review the applicable PPM / subscription documents and Republic risk disclosures carefully. Republic does not independently verify all issuer information.
Other legal and operational risks include evolving regulation of crypto-assets and DeFi, MiDAO / Marshall Islands entity and Operating Agreement evolution (MM OA today; Token OA planned), smart-contract and custody risks described in Q12b, and the early-stage nature of Diamond Hands fee generation (fee waterfall not yet operative — see Q4f). This summary is not legal advice and is not a complete risk factor list.
(b) Protocol, Technology & Security Risks
Material technical risks include:
(1) UUPS upgradeable core contracts — Diamond Hands / $GVNR-related core contracts use UUPS upgradeability (including, among others, paths gated to DEFAULT_ADMIN_ROLE / UpgradeValidator as disclosed in Q4e). A compromised or malicious upgrade path could alter protocol behaviour. Contract addresses and further technical detail are available on request.
(2) Oracle dependency via PriceFeedConsumer — pricing depends on PriceFeedConsumer. GVNR uses an aggregate of multiple price feeds to reduce the risk of single-feed failure or manipulation. Further oracle / feed detail is available on request.
(3) UCD overcollateralisation — UCD is designed to be overcollateralised by BTC vault collateral. Overcollateralisation (and user positions) could be at risk if contracts were attacked and drained. Delegation of emergency-pause powers is being explored to reduce the chance that such an event becomes a terminal risk (see also Q4e pause authority).
Audits and early-2026 context: Q1 2026 DeFi incidents showed that “audited” protocols were still exploited when (i) code changed after the audit commit, (ii) oracle/integration or economic attacks were scoped out, (iii) privileged mint/admin paths lacked on-chain invariants, or (iv) keys / off-chain infrastructure were compromised — surfaces a point-in-time code review often does not cover. GVNR has used multiple AI audit tools and intends to move to rigorous, PR-gated review over time (so new modules are not shipped on an unaudited delta). Mitigations aligned to those failure modes include UUPS role separation and Safe execution controls (Q4e), aggregated price feeds via PriceFeedConsumer, exploration of delegated emergency-pause to limit drain/terminal risk to UCD overcollateralisation, and avoiding sole reliance on a one-time launch audit. There is no SOC 2 (or equivalent) attestation at this time due to operational limitations. Even strong audits would not necessarily catch novel economic attacks, post-audit refactors, key-compromise, out-of-scope integrations, or off-chain operational failures.
(c) Token Economics, Unlocks & Incentive Risks
$GVNR has a fixed maximum and total supply of 20,000,000 tokens. Unlocks and vesting continue through 25 December 2026, as described in the Token Paper, and may affect market supply. Token allocations may be concentrated among certain holders, which may affect liquidity, price, and governance influence. Under the current OA, the Managing Member has the applicable company-management authority. The planned Token Operating Agreement may change how tokenholder governance and control operate, including any future rights over fee and Furnace parameters. Until a Token OA is in force, fee and Furnace parameters remain under Managing Member authority under the MM OA. These arrangements may evolve as the OA structure evolves and could affect token economics or governance outcomes.
This Token Transparency Filing is provided for general informational purposes only. Blockworks reviews completeness only and does not verify or warrant the accuracy of individual answers. GVNR is solely responsible for the content, accuracy, and legality of its disclosures.