98450001BQK77812E747 2026-01-01 2026-12-31

Table of Contents

General Information
SUMMARY
Part A - Information about the Offeror or the Person Seeking Admission to Trading
Part B - Information about the Issuer, If Different from the Offeror or Person Seeking Admission to Trading
Part C - Information about the Operator of the Trading Platform
Part D - Information about the Crypto-Asset Project
Part E - Information about the Offer to the Public of Crypto-Assets or their Admission to Trading
Part F - Information about the Crypto-Assets
Part G - Information on the Rights and Obligations attached to the Crypto-Assets
Part H - Information on the underlying technology
Part I - Information on Risks
Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
General Information
00: Table of content
true
01: Date of notification

2026-07-10

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

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

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

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

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

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

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

false

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

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

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

Warning

This summary should be read as an introduction to the crypto-asset white paper.

The prospective holder should base any decision to purchase this crypto-asset on the content of the crypto-asset white paper as a whole and not on the summary alone.

The offer to the public of this crypto-asset does not constitute an offer or solicitation to purchase financial instruments and any such offer or solicitation can be made only by means of a prospectus or other offer documents pursuant to the applicable national law.

This crypto-asset white paper does not constitute a prospectus as referred to in Regulation (EU) 2017/1129 of the European Parliament and of the Council or any other offer document pursuant to Union or national law.

08: Characteristics of the crypto-asset

GNOT is the native token of the Gno Land ecosystem, serving as the gas and storage deposit unit for on-chain activity on its smart-contract Layer 1 blockchain.

Gas Payments: GNOT is required to submit and execute transactions on the Gno.land network, functioning as the fee token for all on-chain activity.

Storage Deposits: Applications interacting with the Gno.land L1 bond GNOT to reserve on-chain state and receive refunds when that storage is freed. Certain GNOT held within storage deposit accounts is transferable only between designated deposit structures and may not be withdrawn.

Supply Constraints: GNOT has a constitutionally defined hard cap of 1.333 billion units, which represents its total allocation at genesis, with zero future inflation. The token carries no secondary-market or yield features and does not confer financial returns, ownership rights, or claims on any entity or pool of assets.

09: Further information about utility tokens

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

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

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

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

NewTendermint, LLC

A.2: Legal form

Limited Liability Company

A.3: Registered address

PHS Corporate Services, Inc., located at 1313 N. Market Street, Suite 5100, Wilmington, Delaware 19801

A.4: Head office

PHS Corporate Services, Inc., located at 1313 N. Market Street, Suite 5100, Wilmington, Delaware 19801

A.5: Registration date

2021-11-19

A.6: Legal entity identifier

98450001BQK77812E747

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

6409024

A.8: Contact telephone number

6613886953

A.9: E-mail address

carolyn.pehrson@tendermint.com

A.10: Response time (days)

002

A.11: Parent company
A.12: Members of management body

1

JAE KWON
Founder and CEO

2
MANFRED TOURON
VP of Engineering

3
DONGWON SHIN
Chief Operating Officer

4
NANDIKA HETTIARACHCHI
Director of Finance

A.13: Business activity

NewTendermint, LLC is the token issuer entity, developer of “Gno.land”, a next-generation smart contract platform built using “Gno”. It provides software and user interfaces for interacting with the Gno.land blockchain network, a next-generation smart contract platform built using “Gno”.

A.14: Parent company business activity
A.15: Newly established

false

A.16: Financial condition for the past three years

Gno Land is a pre-launch project financed primarily through a token sale of its native GNOT token, with a stated fundraising target of up to $19.3 million to fund continued development and marketing ahead of mainnet launch. Its capital resources consist of the proceeds (and expected proceeds) from this sale and a hard‑capped GNOT supply of approximately 1.333 billion tokens, structured via a treasury system intended to fund validation, core development, ecosystem contributors, governance, security, and reserves over time. Current operating performance is described qualitatively rather than via traditional financial statements: the project reports that around 70% of expenditure is on salaries and personnel (indicating a development‑heavy cost base), 10% on marketing, 10% on servers and tools, and 10% on legal and company operating costs, suggesting that near‑term financial KPIs are focused on maintaining engineering capacity, infrastructure, and legal readiness for launch rather than revenue generation.

Non‑financial KPIs and performance indicators are embedded in the token and protocol design: GNOT functions as the native gas and storage‑deposit token, with a storage‑bonded model that ties token use directly to on‑chain state utilization, so future on‑chain storage locked in GNOT and activity levels are intended to become key indicators of ecosystem traction and real usage once mainnet is live. At this stage the project’s financial condition is best characterized by its available and target capital from the ongoing token sale, its planned expenditure mix, and the governance‑driven allocation of future token reserves, with no publicly available quantitative data on revenues, profits, or secondary‑market performance.

A.17: Financial condition since registration

Not applicable as the offeror or person seeking admission to trading has been established for at least three years.

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

false

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

Gno Land

D.2: Crypto-asset name

GNOT

D.3: Abbreviation

GNOT

D.4: Crypto-asset project description

Purpose and Goals:
Gno.land is a next‑generation, open‑source smart contract platform built on Gnolang, a deterministic, interpreted extension of Go, designed to make decentralized applications and verifiable knowledge bases transparent, auditable, and easy to build. It aims to become the execution layer and “GitHub of Web3,” lowering barriers to censorship‑resistant applications while aligning incentives among developers, validators, and contributors through a contribution‑driven reward and governance model.

Key Features and Operation:

  • Gnolang and the GnoVM execute smart contracts deterministically via interpreted code, enabling fully transparent, on‑chain source that is easy to inspect, audit, and verify.
  • Applications are structured as “realms” and packages in a decentralized app‑store model, where each package has a unique path and can be browsed, reused, and composed into larger systems.
  • The Gno.land blockchain forms the smart‑contract application layer, managing realms, objects, and logic, and uses an improved Tendermint2 consensus for simplicity, performance, and fast finality.
  • Interoperability is provided through IBC and a proposed “IBC2,” positioning Gno.land as a hub of interconnected realms and cross‑chain applications.
  • A Proof‑of‑Contribution framework with non‑transferable WORX units measures contributors’ work and drives periodic GNOT reward distributions, governed by a Contributor DAO and related sub‑DAOs.
D.5: Details of all natural or legal persons involved in implementation of crypto-asset project

1
Development team
Jae Kwon

2
Development team
Manfred Touron

3
Development team
Dongwon Shin

4
Development team
Morgan Bazalgette

5
Development team
Antoine Eddi

6
Development team
Guilhem Fanton

7
Development team
Thomas Bruyelle

8
Development team
Alexis Colin

9
Development team
NewTendermint Management Holdco

D.6: Utility token classification

false

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

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

D.8: Plans for the token

Gno.land has built an open-source smart contract platform using Gno, a deterministic variation of Go, with live on-chain applications such as Boards (a fully on-chain social forum), a browser-based Gno Playground for building and testing contracts, public documentation, and a faucet for testnet GNOT, demonstrating an active developer environment ahead of mainnet launch. GNOT is designed as the native gas fee and storage-deposit token used to pay for transactions, reserve on-chain storage and execution resources, and act as a reputation and reward medium aligning developers, validators, and creators.

Future milestones (dated / forward-looking)

  • 14 August 2026 - Token Generation Event (TGE) for GNOT, initiating the live native gas and storage-deposit token used for fees, storage bonding, and incentive alignment.
D.9: Resource allocation

Financial resources / funding

  • Ongoing GNOT token sale targeting up to $19.3M in proceeds.
  • Current spend split: ~70% salaries/personnel, 10% marketing, 10% servers/tools, 10% legal and operating costs.
  • Stated use of funds: build on Gno.land, onboard Go developers, specialize engineering in mobile/Interchain Security/IBC, grow treasury to seed first-wave apps, and support ecosystem marketing and user adoption.

Human resources / team

  • Core engineering and infra team of at least eight senior profiles, including multiple senior Go engineers (distributed systems, peer‑to‑peer, decentralized systems, large-scale data), a senior frontend engineer (gnoweb), a senior DevOps/infra engineer (validators, CI/CD, internal services), and a senior technical project manager for developer platforms and open‑source ecosystems.

Technological resources developed

  • Core protocol stack including GnoVM (interpreting Gnolang) and the Gno.land blockchain managing realms, objects, and logic.
  • Gno Realm & Packages: on-chain “app store” of composable modules, plus official realm packages (r/gnoland), system realms (r/sys), demos (r/demo), and pure demo packages (p/demo).
  • Interoperability stack with IBC/“IBC2” and Tendermint2 consensus focused on simple, performant fast-finality.
  • Frontend and tooling: Gnoweb universal contract browser/UI, Gno Playground for writing/running/testing Gno in the browser, local dev tooling (gnodev), testnet faucet, and the on-chain Boards social/forum dApp.

Other significant investments

  • Investment in ecosystem infrastructure: on-chain forum (Boards), developer documentation, events, blog, and community channels to support developer and user onboarding.
  • Planned treasury and grant-like funding to incentivize early application development and broader ecosystem growth.
D.10: Planned use of collected funds or other tokens

Gno Land plans to use funds and future crypto-asset inflows primarily to continue core protocol and software development, cover personnel and operating costs, and support marketing and brand awareness around mainnet launch. Funds raised through GNOT token purchases are earmarked for onboarding Go developers, specialized engineering work (including mobile, Interchain Security, and IBC), and bolstering a treasury to incentivize early application development and broader ecosystem growth. Newly minted GNOT is further allocated across dedicated treasuries focused on validation, core software development, ecosystem contributors, governance, security and audits, and future reserve needs, with mechanisms that redirect surplus from validation and governance pay toward ecosystem rewards when their funding needs are lower.

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

ATTR

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

Enable EU market access for GNOT holders.

E.3: Fundraising target

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

E.4: Minimum subscription goals

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

E.5: Maximum subscription goals

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

E.6: Oversubscription acceptance

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

E.7: Oversubscription allocation

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

E.8: Issue price

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

E.9: Official currency determining issue price

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

E.10: Subscription fee

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

E.11: Offer price determination method

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

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

1333000000

E.13: Targeted holders

All.

E.14: Holder restrictions

There are no restrictions.

E.15: Reimbursement notice

There are no reimbursement rights.

E.16: Refund mechanism

There is no refund mechanism.

E.17: Refund timeline

There is no refund mechanism.

E.18: Offer phases

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

E.19: Early purchase discount

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

E.20: Time-limited offer

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

E.21: Subscription period beginning

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

E.22: Subscription period end

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

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

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

E.24: Payment methods for other token purchase

Fiat or other crypto-assets.

E.25: Value transfer methods for reimbursement

There are no reimbursement rights.

E.26: Right of withdrawal

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

E.27: Transfer of purchased other tokens

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

E.28: Transfer time schedule

There is no relevant time schedule.

E.29: Purchaser's technical requirements

There are no technical requirements.

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

Not applicable.

E.31: CASP identifier

Not applicable.

E.32: Placement form

NTAV

E.33: Trading platforms name

NewTendermint, LLC is seeking admission to trading for the GNOT token across multiple trading platforms, including Payward Global Solutions Limited.

E.34: Trading platforms market identifier code (MIC)

PGSL

E.35: Trading platforms access

Online via the platform.

E.36: Involved costs
E.37: Offer expenses

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

E.38: Conflicts of interest

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

E.39: Applicable law

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

E.40: Competent court

Delaware

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

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

F.2: Other token functionality
  • Native ecosystem token of the Gno.land blockchain, required to use the platform.
  • Gas token for transactions and smart contract execution.
  • Storage-bond token: transactions that increase persistent on-chain state must post a GNOT bond; freeing state space refunds GNOT, with 1 billion GNOT corresponding to 10 TB of state.
  • Resource reservation: applications may lock GNOT to reserve network resources (code, state, data) and signal real usage on-chain.
  • Reputation and reward medium used to measure and reward participants (developers, validators, creators) and to distribute ecosystem incentives via treasuries.

Rights (as described):

  • Governance/voting right: token holders “play an active role in the decentralized governance of the GNOT ecosystem,” voting on key proposals and shaping platform development, including parameter changes, validator acceptance/denial, ecosystem funding, and contribution acceptance via the core DAO and subDAOs.
  • Practical network rights: ability to submit transactions, execute contracts, and reserve/release on-chain storage by posting and reclaiming GNOT bonds under protocol rules.
  • No explicit rights to dividends, profit-sharing, or guaranteed returns are described; materials emphasize usage, participation, and rewards for active contribution rather than passive holding for profit.
F.3: Planned application of functionalities

Q1 2026 - Beta Mainnet Launch

  • Token Generation Event and initial GNOT distribution
  • Launch of the functional network and core operating system
  • GNOT live as the gas and storage-deposit token; protocol-level transfers not yet enabled

Q2 2026 - Network expansion

  • Bridging with Atom.One for shared security and interoperability (IBC/IBC2)
  • Advancing Gno functionality and features
  • Launch of Game of Realms, an incentivized contribution network

Q3 2026 - Mainnet Launch

  • Protocol-level transfers enabled
  • Fully interoperable, security-hardened network, following completion of full network audits and penetration testing

Q4 2026 & BEYOND - Ecosystem growth

  • Focus on flagship applications on Gno.land
  • Continued tooling development
F.4: Type of crypto-asset white paper

OTHR

F.5: Type of submission

NEWT

F.6: Other token characteristics

Gno.land’s native token GNOT is designed and documented as a capped, chain-native token for gas and storage deposits on the Gno.land smart-contract L1, rather than as a separate investment token with external cash-flow rights. It sits on a storage‑bonded economic base where applications bond tokens to reserve on‑chain state and receive refunds when storage is freed, with a constitutionally defined hard cap that will never exceed 1.333 billion units, fully minted and allocated at genesis across predefined tranches.GNOT is the native gas and storage token for the ecosystem, indicating a utility-token compliance posture focused on network usage rather than financial returns, with no secondary-market or yield features described and no public market data available at this pre‑launch stage.

F.7: Commercial name or trading name

Gno Land

F.8: Website of the issuer

https://gno.land/

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

14-08-2026

F.10: Publication date

07-08-2026

F.11: Any other services provided by the issuer

Nothing other than already stated in the white paper.

F.12: Language or languages of white paper

English

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

LFJTPFK8D

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

6537KDT7Q

F.15: Voluntary data flag

false

F.16: Personal data flag

true

F.17: LEI eligibility

true

F.18: Home member state

Ireland

F.19: Host member states

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

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

Ownership/economic rights:
The native token of the Gno.land blockchain (GNOT) is designed strictly as a utility, storage-deposit, and governance asset, not as equity. Holders do not receive claims on NewTendermint, LLC, GovDAO, or core treasury assets beyond what is authorized via constitutional governance. The total supply is strictly capped at 1.333 billion units allocated at genesis, with zero future token minting or inflation. Revenue generated from transaction fees is programmatically distributed to core purpose-specific treasuries (Validator Services, Core, Ecosystem, and Reserve) to sustain network infrastructure and open-source development under strict oversight.

Access/utility:
The token functions as a mandatory storage-bonded resource for writing to the blockchain’s persistent state. Every transaction that increases persistent state space requires a GNOT bond deposit (proportionate to the rule of 1 billion GNOT per 10TB of state space), and any transaction that frees up state space triggers a direct refund. This ties token utility and network demand directly to the active deployment and use of smart-contract “realms.”

Voting/governance:
General token holders do not vote directly within GovDAO, which is a structured, tiered council of vetted and publicly identified individuals. Instead, broader community token holders participate in decentralized governance through GnotDAO, a GNOT-bonded on-chain voting DAO. GnotDAO exercises specific constitutional checks, such as voting on the appointment of certain members of the Oversight Body and electing GovDAO members if council expansion targets stall.

Holder obligations:
By interacting with the network, users must adhere to the immutable rules set forth in the Gno.land Constitution. All spending from the ecosystem treasuries for software or intellectual property must strictly be for Open Source IP released under the Gno Network GPL License. Furthermore, validators and governing members face strict operational obligations, including running dedicated, physical non-cloud hardware and maintaining a complete absence of government intelligence, defense contractor, or criminal associations.

G.2: Exercise of rights and obligations

Network Access and Usage (The Principal Exercisable Right)
Holders exercise the token's core utility by bonding storage and paying transaction fees to interact with Gno.land's realms and packages. The technical procedure requires:

Setting up a compatible interface or cryptographic key management software, such as the official command-line tools or a standard reference wallet application.

Maintaining a $GNOT balance to deploy as a storage bond whenever a transaction increases the network's persistent state space, calculated under the baseline of 1 billion $GNOT per 10TB of state.

Initiating on-chain transactions to invoke smart-contract "realms," with the understanding that freeing persistent state space programmatically triggers an automated refund of the bonded $GNOT to the initiating account.

Governance Participation
The procedure for exercising governance rights depends on the user's role within the dual-DAO structure defined by the Constitution:

Vetted Contributors (GovDAO): Vetted individuals who meet strict technical criteria, pass live interview tests, and satisfy geographic diversification limits participate in the core governing body (GovDAO). They exercise voting power weighted by their membership tier (T1, T2, or T3) to decide on treasury allocations and constitutional amendments.

General Token Holders (GnotDAO): Broader community members exercise their governance rights by bonding $GNOT directly to GnotDAO. This token-bonded voting body acts as an on-chain check on GovDAO, exercising the right to vote on the replacement of specific Oversight Body members and electing GovDAO candidates if council expansion targets stall.

Eligibility Conditions and Restrictions
While network interaction and storage bonding are public and code-driven, specific constitutional restrictions apply to active participants:

Ecosystem Rewards: Any developer or creator seeking funding or rewards from the Ecosystem Treasury must have their real human identity verified and recorded in accordance with the Constitution and applicable laws.

Governance Exclusions: No candidate or member is eligible to participate in GovDAO governance if they have any association with government intelligence agencies, defense contractors, law enforcement, organizations with confidential membership (e.g., Freemasonry), or any prior conviction for violent, property, white-collar, or cyber crimes.

Hardware Obligations: Validators authorized to secure the pre-migration network must run dedicated physical hardware with 24-hour physical access, completely avoiding the use of cloud hosting providers.

G.3: Conditions for modifications of rights and obligations

Constitutional Amendment Framework: Rights, obligations, and core network parameters defined in the Constitution can only be modified through a formal Constitutional Amendment. This process requires a Constitutional Majority Decision, which is an exceptionally high threshold demanding more than 9/10 (90%) of the total voting power across the GovDAO council tiers (T1, T2, and T3).

Mandatory Pre-Approval and Oversight Guardrails: A Constitutional Amendment cannot execute automatically upon passing a vote. To be valid, the proposal body must cryptographically attach a signed signature of pre-approval from the independent Oversight Body (initially NewTendermint, LLC, migrating to a dedicated three-member Oversight DAO). The Oversight Body is constitutionally obligated to reject any amendments that violate the Seven Mandates of Gno.land or distort the original spirit of the genesis text.

Permissible Modifications: 1. Storage Burn Adjustments: Governance can implement or alter the automatic burn rate of stagnant GNOT held within realm-specific Storage Deposit Discount Credit Accounts (SDDCAs), provided the rate does not exceed 10% per year.
2. Treasury Management: Unspent or assigned funds within the core treasuries can be clawed back, altered in purpose, or burned only if a full Constitutional Amendment is ratified to permit the specific exception.
3. Clarification of Language: Amendments are permitted to clarify ambiguous wording, provided the changes strictly preserve the intent of the terms established prior to the amendment.

Immutable Core Constraints: Certain foundational rules are explicitly designed to be immutable and cannot be altered by governance intervention:

Absolute Supply Ceiling: The rule that the total created GNOT will never exceed 1.333 billion tokens is absolute; the protocol lacks any mechanism or inflation schedule to mint new tokens.

Storage Price Ceiling: The GNOT Storage Deposit Price per byte can never be increased by any governance decision (it can only be lowered by a maximum of 10% per year).

G.4: Future public offers

There are no future offers planned.

G.5: Issuer retained other token

332,000,000

G.6: Utility token classification

false

G.7: Key features of goods or services utility tokens
G.8: Utility tokens redemption
G.9: Non-trading request

true

G.10: Other tokens purchase or sale modalities

Not applicable. This white paper is published in relation to the admission to trading of the GNOT token and does not relate to any public offering.

G.11: Other tokens transfer restrictions

On-chain / protocol-level transfer mechanics

Stagnant Storage Restrictions: GNOT tokens deposited or routed into realm-specific Storage Deposit Discount Credit Accounts (SDDCAs) face permanent transferability restrictions. These tokens can never be withdrawn back into standard circulating user wallets, even when on-chain storage space is freed. They may only be moved to other SDDCAs under rules defined in the Governing Documents, and any such transfer must be strictly initiated by the active authority or managing organization of that specific smart-contract realm.

Lock-ups, Vesting Schedules, and Whitelists

Initial Transferability Ban: GNOT tokens are subject to a strict protocol-level transfer restriction immediately following genesis. The token will not be freely transferrable between ordinary user wallets at launch.

Whitelisted Operational Addresses: Transferability is initially restricted exclusively to predefined, whitelisted addresses. These whitelisted exceptions include the "Ecosystem" and "Investors" funds, alongside specific infrastructure addresses necessary for the baseline operations of the blockchain, investor payouts, or core funding needs.

13-Month Common Vesting Schedule: All GNOT allocations granted at genesis are bound to a strict, uniform lock-up and release schedule tied to the launch of the transferrable mainnet:

Day 1 (Mainnet Launch): 7% of the allocated tokens are released and become transferrable.

Months 2 through 12: 7% of the allocation is unlocked incrementally each subsequent month.

Month 13 (Final Month): The remaining 9% of the allocation is released, resulting in a fully vested allocation 13 months after the mainnet launch.

G.12: Supply adjustment protocols

true

G.13: Supply adjustment mechanisms

Fixed Supply and Absolute Hard Cap: There is no protocol mechanism to mint new tokens post-launch. The total supply is strictly fixed from day one, as the constitution dictates that the total created $GNOT will never exceed 1.333 billion tokens. The entire 1.333B supply is fully allocated at genesis across predefined allocations (Airdrops, Core Treasury, Ecosystem Treasury, Validator Treasury, Investors, and NT,LLC), making the economic model strictly non-inflationary.

Storage-Bond and Price Adjustment Dynamics: The storage-bond protocol regulates circulating tokens based on data footprints. Transactions that increase the blockchain's persistent state require a $GNOT bond deposit (where 1 billion $GNOT corresponds to 10TB of state space), while freeing state triggers a direct refund. GovDAO can lower the per-byte storage price by a maximum of 10% per year, but can never increase it. When a price reduction occurs, the resulting "excess" bonded $GNOT is split: 25% is directed to the Security Treasury, and 75% enters segregated virtual accounts per realm (Storage Deposit Discount Credit Accounts, or SDDCAs) exclusively to subsidize future transaction discounts for that specific realm.

Automated Storage Deflation Burn: Supply contraction is driven automatically by a protocol mechanism targeting stagnant storage credits. $GNOT balances held within SDDCAs are subject to an automatic burn at a constitutionally set rate not to exceed 10% per year. This prevents inactive credits from permanently locking up the network's allocated storage capacity. When $GNOT is destroyed via this mechanism, it permanently reduces the total existing supply and automatically triggers a further reduction in the storage deposit rate without re-activating the excess deposit redistribution rules.

Treasury Burn Restrictions: Funds allocated or transferred to the top-level core treasuries (Core, Ecosystem, Validator Services, and Reserve) are explicitly protected from arbitrary governance destruction. Any unspent or assigned treasury assets cannot be clawed back, transferred to other DAOs, or burned through standard spending proposals. Executing a token burn from these treasuries strictly requires a full Constitutional Amendment, necessitating a Constitutional Majority Decision (9/10 voting power) and explicit pre-approval from the Oversight Body.

G.14: Token value protection schemes

true

G.15: Token value protection schemes description

Description of the protection schemes protecting the value of the crypto-assets, if applicable

Absolute Supply Hard Cap (Anti-Dilution): The primary mechanism protecting $GNOT's long-term economic value is a strict, constitutionally enforced anti-dilution framework. The token features zero post-launch inflation and no minting schedules. The total created supply is permanently capped at 1.333 billion tokens, all of which are brought into existence at genesis and strictly distributed across fixed buckets. This prevents any downward price pressure from continuous block rewards or unexpected supply issuance.

Intrinsic Utility Value (Storage-Bond Anchoring): $GNOT's market demand is programmatically tied directly to the physical storage growth of the Gno.land ecosystem. The network enforces a mandatory byte-storage deposit model, where 1 billion $GNOT directly corresponds to 10TB of persistent state space. Because any transaction that writes permanent data to a "realm" must bond $GNOT, a growing network footprint removes tokens from active market circulation. Conversely, freeing up state space triggers an immediate token refund, stabilizing the link between token utility and actual network usage.

Predictable Storage Pricing Ceiling: To protect the economic viability of developers building on the platform, the GNOT Storage Deposit Price (per byte) is constitutionally barred from ever increasing. It may only decrease by a maximum of 10% per year via governance vote. This ensures that the cost of network storage remains predictable and cannot be artificially inflated to extract value from users.

Automated Supply Contraction (Deflation): When GovDAO votes to lower the per-byte storage deposit rate, the protocol triggers automated deflationary pressure. A portion of the excess storage credits sitting in realm-specific Storage Deposit Discount Credit Accounts (SDDCAs) can be burned automatically at a rate up to 10% per year to clear out stagnant allocations. This destruction permanently reduces the total existing supply below the 1.333B ceiling, intensifying token scarcity as the network matures.

Rigid Treasury Ring-Fencing and Oversight: To eliminate misallocation risks that could devalue the asset, the Constitution enforces strict structural boundaries on the network's capital reserves:

Priority Revenue Routing: Network transaction fees ("Revenue") are strictly routed to keep the blockchain secure, prioritizing the Validator Services Treasury on a runway-based scale (up to 50% of revenue when runway is under 1 year). The remainder is locked into specific allocations: 40% Core Treasury, 40% Ecosystem Treasury, and 20% Reserve Treasury.

Anti-Clawback & Anti-Burn Safeguards: Unspent treasury allocations are protected by a high governance barrier. They cannot be arbitrarily spent, moved, or burned by standard voting protocols; doing so requires a full Constitutional Amendment (9/10 majority vote) and explicit cryptographic pre-approval from the independent Oversight Body (NewTendermint, LLC / Oversight DAO).

G.16: Compensation schemes

false

G.17: Compensation schemes description
G.18: Applicable law

Delaware

G.19: Competent court

Delaware

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

Gno Land uses a distributed blockchain computer where many independent nodes run the same Gnolang programs, so no single party controls data or execution. Security comes from a Tendermint2-style consensus that requires a large set of validators to agree on each block and from Merkle‑tree based storage, which makes it practically impossible to alter code or state without detection. Once transactions and smart contracts are finalized, their history is immutable, and all logic runs in the GnoVM, which is designed for deterministic execution and easy auditing. Transparency is built in: contracts live in on‑chain “realms” that are open to inspection, with a native “view source” interface so anyone can see and verify how applications work and how data and token balances change over time.

H.2: Protocols and technical standards

Core chain, consensus, and interoperability stack

  • Consensus: Tendermint2 BFT consensus is the core consensus engine for the Gno.land blockchain, designed for fast finality and performance.
  • VM and language: GnoVM (deterministic VM) executing Gnolang (Gno), a Go-derived language extended for multi‑user, inter‑realm programming on a shared chain.
  • Interoperability (cross‑chain): The design explicitly includes IBC and “IBC2” to position Gno.land as a “Hub of Realms”, building on Cosmos‑style IBC/ICS for cross‑chain communication.
  • Interoperability (intra‑chain): An Interrealm specification defines how realms (smart-contract packages) call each other (explicit and implicit realm crossing) to enable scalable multi‑module dApps on a single shared state machine.

Wallet, client, and SDK standards

  • GnoConnect standard: GnoConnect is a URL/HTML‑metadata based standard for connecting wallets, clients, and SDKs (e.g., Adena Wallet, Gnoweb, Gnobro) to Gno blockchains, defining RPC, chain‑ID, tx‑domains and transaction link semantics.
  • gno-js-client alternative: GnoConnect is described as a minimalistic, URL‑based alternative to the gno‑js‑client, allowing apps to integrate without embedding JS/TS components while still generating transactions via compatible wallets/clients.
  • Official wallets: The core software set includes an “official standard reference browser extension wallet” and “official standard hardware wallet software” for Gno.land; Adena is referenced as the flagship non‑custodial wallet in ecosystem materials.
  • CLI wallet and clients: The gnokey CLI wallet and both Go and JavaScript clients are documented for interacting with Gno networks and dApps, enabling programmatic and SDK‑style access.

Developer and UX interfaces (relevant to scalability/interoperability)

  • Gnoweb: A standard web interface (“Gnoweb”) for browsing and interacting with realms and packages, acting as a universal frontend over the GnoVM and chain.
  • Gno Playground & local dev: Web‑based Gno Playground and gnodev local‑dev tooling provide standardized environments for building, testing, and deploying realms, supporting scalable developer workflows.

Summary (focused on interoperability/scalability)
Concretely, the interoperability/scalability stack for Gno.land centers on Tendermint2 consensus, IBC/ICS (including a planned IBC2) for cross‑chain connectivity, the Gno interrealm model for intra‑chain modularity, and the GnoConnect standard plus official wallets/clients (Adena, Gnoweb, gno‑js‑client alternative, gnokey, Go/JS clients) for interoperable wallet/SDK integration.

H.3: Technology used
  • Cryptographic Key Management & CLI Tooling: Users hold, store, and transfer $GNOT tokens using public-key cryptography. At the base protocol layer, keys are managed using the official command-line interface tools (gno cli). The software supports generating secure cryptographic key pairs from standard localized mnemonic backup phrases, ensuring that private keys remain under the direct control of the user. Transactions transferring assets are cryptographically signed locally before being broadcast to the Tendermint2 network engine.
  • Constitutionally Mandated Core Software Wallet Stack: To ensure long-term decentralized access, security, and open-source continuity, the Constitution establishes a strict mandate for the platform's user-facing wallet infrastructure. The following components are explicitly categorized as Core Software and are prioritized for perpetual development and security funding from the Core Treasury:
  1. Official Standard Reference Browser Extension Wallet: A foundational, open-source browser utility designed to allow general users to easily interact with smart-contract "realms" and approve token-bonded transfers safely from web interfaces.
  2. Official Standard Hardware Wallet Software: Dedicated, secure reference software developed to enable native hardware wallet integrations, isolating private keys from internet-connected execution environments.
  • Open Source IP and Licensing Guardrails: In alignment with the network's security architecture, all official wallet applications, codebases, and cryptographic libraries must be released entirely as Open Source IP under the strong copyleft Gno Network GPL License (with strict attribution clauses). This ensures that any wallet software used to hold or move assets remains transparent, verifiable by qualified third-party auditors, and permanently protected from proprietary lock-in.
  • Multisig and Governance Account Execution: For institutional or team-based custody, the protocol utilizes multi-signature structures managed at the account level or driven through smart-contract DAOs. Top-level core operations—such as the initial management of the Oversight Body—rely on a dedicated multisig account layout where signers must act strictly in accordance with pre-approved cryptographic bounds before transactions can modify ledger states or deploy capital assets.
H.4: Consensus mechanism

Gno.land is designed as a standalone L1 chain that uses Tendermint2 (TM2), a Byzantine Fault Tolerant consensus engine derived from the original Tendermint, providing fast finality.

Security comes from TM2’s BFT model with a validator set that must reach a supermajority agreement on each block; as long as less than one‑third of voting power is faulty, finalized blocks cannot be reverted, giving strong safety guarantees. Efficiency comes from short block times and instant finality (no long confirmation chains), plus deterministic execution with Gno, which together reduce latency for transactions and smart contracts while keeping resource usage predictable.

H.5: Incentive mechanisms and applicable fees

Incentive mechanism
$GNOT is a hard-capped (1.333 billion), non-inflationary token acting initially as a transaction fee token and permanently as a byte-storage deposit token; there is no staking issuance or block rewards on Gno.land. Network operations and development are funded entirely via transaction-fee Revenue and genesis treasury allocations managed by GovDAO. Validators are compensated from the Validator Services Treasury, core development is funded by the Core Treasury, and external open-source contributors are rewarded via the Ecosystem Treasury.

Applicable fees
Users pay $GNOT for transaction execution (gas) and must provide a bond deposit for any transaction that increases the blockchain's persistent state (scaled at 1 billion $GNOT per 10TB of persistent state space). This storage bond is fully refunded when the state space is freed. The per-byte storage deposit price can never increase and may only decrease by a maximum of 10% per year via governance decision.

Fee distribution
Collected transaction fees are defined as "Revenue" and are distributed strictly in the following priority order:

Validator Services Treasury (ValTreasury): Receives a prioritized, runway-based share of Revenue (50% if under 1 year of runway; 25% if under 2 years; 10% if under 3 years; 5% if under 5 years; 0% if over 5 years).

Remaining Revenue Split: Whatever remains after funding the ValTreasury is strictly divided as follows:

Core Treasury: 40%

Ecosystem Treasury: 40%

Reserve Treasury: 20%

When GovDAO lowers the storage deposit rate, the resulting excess bonded $GNOT is treated separately from standard Revenue: 25% goes to the Security Treasury and the remaining 75% goes to realm-specific Storage Deposit Discount Credit Accounts (SDDCAs) to subsidize future transaction discounts for those specific realms.

H.6: Use of distributed ledger technology

true

H.7: DLT functionality description

Architecture and ledger model
Gno.land operates as a Tendermint2-based account and contract blockchain executing a custom interpreted state machine called the GnoVM.

  • The GnoVM and AST Interpreter: Unlike conventional virtual machines that execute opaque bytecode (e.g., EVM), the GnoVM directly interprets a Go-derived Abstract Syntax Tree (AST). It handles values natively as type-value tuples (TypedValue), enabling strong type enforcement throughout the execution lifecycles.
  • The Realms Storage Architecture: Smart contracts are stateful packages known as "realms" deployed under the gno.land/r/... namespace. Global variables declared in a realm are automatically persisted and Merkle-ized by the protocol across transaction states without manual serialization code. Immutable libraries use the pure package namespace (gno.land/p/...), while temporary user scripts execute state calculations on-chain within the ephemeral namespace (gno.land/e/...) without writing to permanent storage. Both user accounts (EOAs) and deployed smart contracts share the uniform underlying abstraction of a realm, with addresses derived directly from package paths.

Node roles and interaction
The network relies on specific infrastructure roles to maintain ledger integrity:

  • Validators and Full Nodes: Validators run dedicated physical hardware to maintain the full application state, gossip blocks, and execute Tendermint2 round-based consensus.
  • Call-Stack Execution Model: End users sign transactions via wallets or command-line clients (gnokey) to invoke exposed realm functions. Every execution triggers an atomic call stack across packages. Contracts track interaction origins using standard runtime APIs including OriginCaller() (the initial cryptographic signer), PreviousRealm() (the immediate caller in the execution path), and CurrentRealm().

Consensus processes
The consensus layer is decoupled from the application layer via an ABCI-style engine boundary. Gno.land utilizes Tendermint2, which delivers Byzantine Fault-Tolerant (BFT), round-based consensus. The validator set validates and orders transactions with weight distributed by token stake. The protocol achieves deterministic, short-latency finality as soon as a block receives cryptographic signatures representing $\ge 2/3$ of the total active voting power, completely eliminating probabilistic forks.

Security measures
Security is enforced structurally through the execution environment and language constraints:

  • Sandboxed Execution: Non-deterministic or high-risk Go standard libraries—including direct operating system (os) features, system calls, and raw network I/O access—are stripped from the Gno compiler to create a fully sandboxed runtime.
  • Deterministic Replayability: Auto-persistence and auto-Merkle-ization guarantee that execution transitions remain entirely deterministic and easily auditable across distinct validator nodes.
  • Strongly Typed Composability: The GnoVM's type system limits variable access to exported identifiers, maintaining tight control over inter-contract calling sequences and mitigating confused-deputy vulnerabilities.

Unique differentiators vs other DLTs

  • AST Interpretation: Executing human-readable syntax trees directly enables advanced client-side tooling to inspect typed values directly on-chain.
  • The Operating System Paradigm: Merging user accounts and packages into a single unified realm abstraction treats the blockchain like a multi-tenant operating system rather than an account state glued to an external key-value store.
  • Browsable On-Chain Tree: Code architecture resembles a public directory file system, mirroring an on-chain version-controlled code repository where packages can be natively browsed, inspected, and cleanly imported by other developers.

Operation and management of the DLT
Operational responsibilities shift from early core-team testing loops to structured constitutional governance over time:

  • The Core Stack: The minimal reference platform software (comprising the node, GnoVM, Tendermint2, and standard tooling) must be permanently licensed as Open Source IP under the Gno Network GPL. Vetted Proxy Entities (such as NewTendermint, LLC) manage this repository contractually on behalf of the chain.
  • The Core Revenue Framework: Long-term funding and software upkeep are sustained strictly through transaction fee "Revenue." This fee pool is programmatically distributed by priority: first to the Validator Services Treasury based on a localized runway calculation (50% when runway is under 1 year, scaling down to 0% if runway exceeds 5 years), with all remaining surpluses split exactly 40% to the Core Treasury, 40% to the Ecosystem Treasury, and 20% to the Reserve Treasury.
  • The Security Treasury Split: Separate from standard transaction revenue streams, the Security Treasury receives a strict 25% allocation of excess tokens only when GovDAO explicitly executes a vote to reduce the per-byte storage deposit price. Spending from this pool requires a 2/3 GovDAO Supermajority decision and is limited to protocol security, maintaining a complete absence of programmatic or discretionary user compensation schemes.
H.8: Audit

true

H.9: Audit outcome

Gno Land’s core technology is built around the GnoVM, which interprets the Gnolang language for transparent, deterministic smart contracts on a dedicated Gno.land L1, combined with a Tendermint2 consensus design that targets simplicity, performance, and fast finality; the broader architecture includes composable “realms” and packages plus advanced IBC/IBC2 interoperability to act as a hub for applications.

From a security and robustness standpoint, key components have undergone independent audits: the GnoVM has been reviewed by Oak Security, and the flagship GnoSwap AMM protocol was audited by OpenZeppelin, which reported 55 issues in total, with all 7 critical issues resolved, all medium issues resolved, and the majority of high and low issues either resolved or partially resolved, indicating active remediation and follow‑up by the team. In addition, the project uses internal stress‑testing and benchmarking tools (Supernova and dedicated benchmark suites) and embeds strong process safeguards: core software must be open‑source, fully audited before receiving treasury funding, and treasury rules prioritize funding for essential infrastructure and validation, all of which support a disciplined, security‑first, and long‑term‑oriented technical governance model.

Part I - Information on Risks
I.1: Offer-related risks

Market & Liquidity Risk

  • Protocol-Level Transfer Restrictions: $GNOT is subject to an immediate post-genesis transferability ban. Initial liquidity is strictly constrained as tokens are locked inside a uniform 13-month vesting schedule (with only 7% unlocked at mainnet launch and 7% released incrementally each subsequent month).
  • Storage Lock-Up Friction: A significant portion of the circulating supply will be programmatically locked up as non-withdrawable storage bonds (scaled at 1 billion $GNOT per 10TB of state space) or trapped inside realm-specific Storage Deposit Discount Credit Accounts (SDDCAs). This unique utility dynamic can cause unpredictable circulating supply contractions, leading to high price volatility and severe secondary market illiquidity.

Admission to Trading / Venue Risk

  • Inter-Chain Security (ICS) Migration Dependencies: Long-term token liquidity and venue integration are structurally dependent on a planned protocol migration. The Constitution obligates Gno.land to migrate its security framework to be hosted by Atom.One ICS.
  • Automated Market Maker (AMM) Execution Risk: Following the migration, an internal AMM exchange module must be implemented on the Gno.land consumer shard to facilitate the programmatic exchange of collected $GNOT into $PHOTON tokens to pay for security. Delays, technical vulnerabilities, or architectural failures in deploying this internal AMM or establishing the cross-chain IBC connections could heavily impair localized asset convertibility and price discovery.

Legal & Regulatory Risk

  • Defensive Regulatory and Tax Positioning: The platform operates under a highly defensive posture regarding external legal classifications. The core text explicitly rejects standard regulatory or tax interpretations that characterize inflationary protocol dynamics as income, labeling such policies as confiscatory. Divergent global regulatory enforcement or aggressive classification of $GNOT as a security, e-money, or regulated financial instrument could severely disrupt whitelisted investor allocations, compromise proxy entities (such as NewTendermint, LLC), or trigger jurisdictional blocks on network access.

AML / KYC Risk

  • Governance Vetting vs. Ecosystem Access Duality: While Gno.land functions as a public, permissionless network at the base transaction layer, strict identity barriers exist for contributors. The Constitution dictates that no funding from the Ecosystem Treasury can be granted unless the contributor's real human identity is verified and recorded under applicable law. Incomplete, inconsistent, or changing compliance standards across international boundaries could disrupt developer onboarding, freeze ecosystem treasury distributions, or isolate contributors residing in heavily scrutinized jurisdictions.
I.2: Issuer-related risks
I.3: Other tokens-related risks

Asset Identity / Ticker Collision

  • Secondary Market Ticker Confusion: Gno.land’s native utility token is constitutionally designated as $GNOT. Because an entirely separate blockchain network (Gnosis) natively uses the ticker GNO, there is an inherent risk of secondary market fragmentation, listing errors, or user operational slip-ups. Intermediaries or purchasers may accidentally buy the incorrect asset, leading to settlement errors, capital loss, or artificial pricing abnormalities.

Utility-Demand and Value Linkage

  • Capped Cost Friction: The $GNOT economic model relies entirely on baseline utility demand, pinning 1 billion $GNOT directly to 10TB of physical persistent state space. Because the per-byte storage price is constitutionally barred from ever increasing (and can only drop by up to 10% a year), the protocol cannot dynamically raise storage costs to artificially protect token value during market downturns. If actual commercial deployment of smart-contract "realms" and data-storage usage lags below historical models, the system's token-bonding velocity will stall, significantly undermining the token's programmatic scarcity and long-term value accrual.

Supply Concentration and Governance Structural Risks

  • Vesting Sell-Pressure: The 1.333 billion $GNOT hard cap is entirely generated at genesis, allocating large, highly concentrated blocks to specific tranches (including 332M to NT, LLC, 300M to Investors, and 231M/350M to distinct snapshot Airdrops). Even though these are bound to a strict 13-month vesting schedule, the unlocking of these major blocks could generate substantial market sell-pressure, particularly if secondary trading venues lack sufficient localized liquidity depth.
  • The Dual-DAO Governance Decoupling Risk: It is critical to recognize that token concentration does not buy direct control over the core governing council (GovDAO). GovDAO is a merit-based, non-token-weighted assembly where voting authority is tied directly to vetted individual tiers (T1, T2, and T3) and isolated by strict geographic concentration limits (no single country can represent more than 1/3 of a tier).
  • GnotDAO Vulnerability: Instead, heavy token concentration primarily introduces risks to the GnotDAO layer—the specialized, $GNOT-bonded on-chain backup DAO. If a few entities amass outsized token holdings, they could gain disproportionate influence over GnotDAO’s specific constitutional powers, such as the ability to vote out the Third Oversight Member or unilaterally push through GovDAO candidate elections if the main council stalls.
I.4: Project implementation-related risks

Adoption and Resourcing Risk

  • Ecosystem Adoption Curve: Because Gno.land relies entirely on Gno—a specialized, runtime-interpreted dialect of Go—the platform's expansion is highly dependent on attracting, training, and retaining a dedicated developer base. If documentation, tooling ecosystems, or localized grant structures fail to convert mainstream Go engineers into ecosystem contributors, core feature deployment and critical realm tooling could face severe bottlenecks.

Governance Complexity and Coordination Overhead

  • Multi-Layer Jurisdictional Friction: The network’s highly structured administrative layer—comprising GovDAO's tiered merit-based council (T1, T2, T3), the dual-check system of GnotDAO, and an independent Oversight Body—significantly increases operational coordination overhead. The necessity of achieving an exceptional 9/10 Constitutional Majority Decision for structural upgrades, combined with mandatory cryptographic pre-approval from the Oversight Body, creates a heightened risk of legislative gridlock. This could severely delay urgent resource reallocations or parameter updates during critical operational crises.
  • Vulnerability of the Secondary Check Layer (GnotDAO Capture): While the main governing council (GovDAO) is fully protected from capital-weighted hostile takeovers due to its identity-vetted, non-token-weighted design, its secondary backup layer (GnotDAO) remains susceptible to token-concentration dynamics. Large aggregations of $GNOT held by specific early entities or whale addresses could result in the coordinated capture of GnotDAO's specific powers, enabling bad actors to target and dismiss the Third Oversight Member or force through un-vetted GovDAO candidate expansions if the core council stalls.

Parameter Rigidity

  • Absolute Capital Inelasticity: The underlying monetary architecture is entirely immutable. The protocol hard cap of 1.333 billion $GNOT and its strictly non-inflationary model cannot be adjusted, expanded, or relaxed by any governance action, including full Constitutional Amendments. While this provides maximum anti-dilution protection to token holders, it completely strips the network of the ability to deploy programmatic token minting or localized inflation to react to catastrophic black swan events, severe capital shortages, or structural shifts in global digital asset markets.

Third-Party Dependencies and Hardening Constraints

  • Auditing and Infrastructure Bottlenecks: Protocol scaling, client wallet releases, and mainnet migration dependencies rely heavily on deep external security coordination, including third-party auditing firms (such as Oak Security and OpenZeppelin) to inspect low-level interpreter layers and state Merkle-ization logic. Delays in completing these critical security-hardening milestones, lower-than-expected software performance from external validator hardware operators, or structural disruptions among proxy software maintainers (such as NewTendermint, LLC) present persistent risks of timeline slippage or network delivery disruptions.
I.5: Technology-related risks

Smart Contracts and Execution Engine

  • Interpreter Vulnerabilities: Gno.land utilizes the custom-built GnoVM to directly interpret a Go-derived syntax tree rather than compiling code to traditional bytecode. This introducing native, runtime-specific interpreter bugs and execution exploits unique to the Gno VM.
  • Toolchain Isolation: Because "Gnolang" functions as an ecosystem-specific dialect, developers cannot rely on the mature auditing tools, static analyzers, or developer environments native to standard Go, significantly shrinking the protective software toolchain.

Cross-Chain Interoperability and Sharding Dependencies

  • Atom.One ICS Vulnerabilities: The long-term architecture positions Gno.land as a consumer chain structurally secured by Atom.One Inter-Chain Security (ICS). This design removes sovereign settlement autonomy, binding Gno.land's structural survivability directly to the consensus, economic health, and validator performance of the Atom.One hub layer.
  • IBC Bridging Failures: Cross-chain state transfers and asset conversions rely heavily on localized automated market makers (AMMs) and the core IBC stack. Vulnerabilities in IBC relayers, cross-chain communication packet corruption, or downstream protocol failures on counterparty networks present persistent integration and asset isolation risks.

Scalability and Performance Limits

  • Unproven Mainnet Throughput: While Tendermint2 consensus delivers deterministic, short-latency fast finality using round-based Byzantine Fault Tolerance (BFT), performance validation has occurred strictly within synthetic testing environments.
  • State Space Growth Friction: Because 1 billion $GNOT maps directly to 10TB of physical persistent state space, unanticipated exponential transaction spikes will dramatically scale storage-bond requirements. This unique mechanics could trigger localized state-growth shocks, testing the structural limits of validator disk space and network performance under live production constraints.

Wallets and Privacy Tracking

  • Total Ledger Traceability: Transactions, variable modifications, and account states within smart-contract "realms" are entirely transparent and public on-chain. Gno.land lacks a native privacy or anonymization layer, exposing users to systemic data-harvesting, transaction tracking, and ultimate real-world deanonymization.
  • Early Wallet Ecosystem: The client key-management framework (gnokey) and reference extensions are pre-launch utilities, increasing end-user vulnerability to phishing vectors, private key-derivation slop, or client-side UX execution errors.

Infrastructural and Bare-Metal Hardware Mandates

  • Bans on Cloud Infrastructure: The Constitution imposes a strict, non-negotiable operational constraint: validators are completely prohibited from utilizing cloud hosting environments (such as AWS, Google Cloud, or Azure).
  • Physical Access Dependencies: Network validators must operate completely on dedicated, physical bare-metal hardware with mandatory 24-hour physical access. This structural mandate introduces acute geographic risk, single-point facility vulnerabilities, physical hardware component degradation, and sudden co-location facility operational disruptions that cannot be mitigated using standard elastic cloud-scaling failovers.

Audits and Security Posture

  • Incomplete Protocol Audits: While independent reviews cover isolated layers—including the GnoVM runtime through Oak Security and specific application sets via OpenZeppelin—a comprehensive end-to-end audit of the compiled monorepo, mainnet genesis architecture, and dual-DAO voting interfaces remains outstanding.
  • Restricted Security Reserves: Financial safety structures are severely restricted. The on-chain Security Treasury is not an insurance fund; it is only funded during governance-driven storage rate drops. It maintains a complete absence of user-facing compensation schemes, leaving users to absorb 100% of the financial impact of code-level exploits or economic execution flaws.
I.6: Mitigation measures

VM and Language Risks (GnoVM / Gnolang)

  • Human-Readable Auditing Vector: Because the GnoVM executes human-readable syntax trees directly on-chain rather than compiled bytecode, contract logic remains completely transparent, drastically reducing the complexity of public security auditing.
  • Deterministic Sandboxing: The language mitigates arbitrary exploit vectors by stripping out non-blockchain appropriate Go standard libraries (such as raw operating system access or un-sandboxed I/O calls). Global variables are automatically persisted and Merkle-ized by the protocol, eliminating human serialization errors.

Cross-Chain Risks (IBC and Shared Security)

  • The Atom.One ICS Safety Net: Rather than relying indefinitely on isolated consensus or unverified bridging mechanisms, the primary cross-chain mitigation strategy is a constitutionally mandated migration path. The Constitution obligates Gno.land to eventually migrate its entire security foundation to be hosted by Atom.One Inter-Chain Security (ICS) upon a Supermajority Decision by GovDAO. This bridges Gno.land directly into a highly secure consumer shard model, shifting the baseline burden of network consensus security to the main Atom.One validator hub.

Scalability and Performance

  • Progressive Guardrails: Performance risk is mitigated through continuous benchmarking loops and progressive multi-node testnets (such as Test4 and Test5) to coordinate validator state handling. Furthermore, the $GNOT tokenomics model enforces a hard ceiling on storage prices (which can never increase and can only decrease by up to 10% annually), preventing sudden economic pricing shocks for active network applications.

Wallets and Privacy

  • Constitutionally Enforced Wallet Standards: Risks associated with malicious third-party client interfaces, key-management slop, and phishing are mitigated by a dedicated funding mandate. The Constitution designates an Official Standard Reference Browser Extension Wallet and Official Standard Hardware Wallet Software as protected "Core Software." These tools receive continuous, prioritized development funding from the Core Treasury to ensure open-source, heavily vetted user interfaces.

Infrastructure Dependencies and Centralization

  • Mandatory Bare-Metal Decoupling: Gno.land mitigates systemic cloud-outage dependencies and corporate infrastructure leverage by completely outlawing cloud hosting providers (such as AWS or Google Cloud). All validators are constitutionally required to operate exclusively on dedicated physical hardware where they maintain physical server access at all times, ensuring true cryptographic and infrastructural sovereign resilience.

Audits and Security Posture

  • Economic Audit Forcing Functions: While core components have undergone independent assessments (such as the GnoVM by Oak Security and application layers by OpenZeppelin), the network implements a strict legislative gate to maintain long-term safety. The Constitution explicitly dictates that funding from the Core Treasury for Essential Services software may only go toward Open Source IP that is fully audited.
  • The 25% Security Treasury Allocation: To continuously fund systemic safety upgrades, the network establishes a dedicated Security Treasury. Whenever governance acts to lower the storage price per byte, 25% of the excess token deposits are programmatically routed directly into the Security Treasury to fund qualified auditors and evaluate bonded vulnerability reports, creating a perpetual security budget tied directly to ecosystem expansion.
Part J – Information on the sustainability indicators in relation to adverse impact on the climate and other environment-related adverse impacts
S.1: Name

NewTendermint, LLC

S.2: Relevant legal entity identifier

98450001BQK77812E747

S.3: Name of the crypto-asset

GNOT

S.4: Consensus mechanism

Gno.land is designed as a standalone L1 chain that uses Tendermint2 (TM2), a Byzantine Fault Tolerant consensus engine derived from the original Tendermint, providing fast finality.

Security comes from TM2’s BFT model with a validator set that must reach a supermajority agreement on each block; as long as less than one‑third of voting power is faulty, finalized blocks cannot be reverted, giving strong safety guarantees. Efficiency comes from short block times and instant finality (no long confirmation chains), plus deterministic execution with Gno, which together reduce latency for transactions and smart contracts while keeping resource usage predictable.

S.5: Incentive mechanisms and applicable fees

Incentive mechanism
GNOT is a hard-capped (1.333 billion), non-inflationary token acting initially as a transaction fee token and permanently as a byte-storage deposit token; there is no staking issuance or block rewards on Gno.land. Network operations and development are funded entirely via transaction-fee Revenue and genesis treasury allocations managed by GovDAO. Validators are compensated from the Validator Services Treasury, core development is funded by the Core Treasury, and external open-source contributors are rewarded via the Ecosystem Treasury.

Applicable fees
Users pay $GNOT for transaction execution (gas) and must provide a bond deposit for any transaction that increases the blockchain's persistent state (scaled at 1 billion GNOT per 10TB of persistent state space). This storage bond is fully refunded when the state space is freed. The per-byte storage deposit price can never increase and may only decrease by a maximum of 10% per year via governance decision.

Fee distribution
Collected transaction fees are defined as ""Revenue"" and are distributed strictly in the following priority order:

Validator Services Treasury (ValTreasury): Receives a prioritized, runway-based share of Revenue (50% if under 1 year of runway; 25% if under 2 years; 10% if under 3 years; 5% if under 5 years; 0% if over 5 years).

Remaining Revenue Split: Whatever remains after funding the ValTreasury is strictly divided as follows:

Core Treasury: 40%

Ecosystem Treasury: 40%

Reserve Treasury: 20%

When GovDAO lowers the storage deposit rate, the resulting excess bonded GNOT is treated separately from standard Revenue: 25% goes to the Security Treasury and the remaining 75% goes to realm-specific Storage Deposit Discount Credit Accounts (SDDCAs) to subsidize future transaction discounts for those specific realms.

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

2026-04-29

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

2026-05-12

S.8: Energy consumption

777886.74449

S.9: Energy consumption sources and methodologies

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

S.10: Renewable energy consumption

29.07

S.11: Energy intensity

0.00002

S.12: Scope 1 DLT GHG emissions - controlled

0

S.13: Scope 2 DLT GHG emissions - purchased

357.05002

S.14: GHG intensity

0.00001

S.15: Key energy sources and methodologies

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

S.16: Key GHG sources and methodologies

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

S.17: Energy mix
S.18: Energy use reduction
S.19: Carbon intensity
S.20: Scope 3 DLT GHG emissions - value chain
S.21: GHG emissions reduction targets or commitments
S.22: Generation of waste electrical and electronic equipment (WEEE)
S.23: Non-recycled WEEE ratio
S.24: Generation of hazardous waste
S.25: Generation of waste (all types)
S.26: Non-recycled waste ratio (all types)
S.27: Waste intensity (all types)
S.28: Waste reduction targets or commitments (all types)
S.29: Impact of the use of equipment on natural resources
S.30: Natural resources use reduction targets or commitments
S.31: Water use
S.32: Non recycled water ratio
S.33: Other energy sources and methodologies
S.34: Other GHG sources and methodologies
S.35: Waste sources and methodologies
S.36: Natural resources sources and methodologies