OpenGradient
AI+2 · Layer-1+1Token Transparency Filing
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
The Problem: Traditional cloud-based AI requires blind trust. Users have no way to verify what model ran, on what data, or whether the output was tampered with. OpenGradient solves this "AI Black Box" problem by executing jobs securely in TEEs and generating cryptographic proofs that are verified directly on-chain, enabling client-side verification of every inference.
(b) Operational priorities
The project’s operational priorities are centered on supporting long-term protocol development, ecosystem growth, infrastructure reliability, security, and community engagement. Resources are expected to be allocated toward core engineering and research, maintenance and upgrades of protocol infrastructure, developer tooling, ecosystem incentives, strategic partnerships, compliance and operational support, and ongoing community and governance initiatives.
(c) High-level project overview
OpenGradient is the Network for Open Intelligence, a decentralized infrastructure network serving as a specialized AI coprocessor that enables applications, blockchains, and autonomous agents to outsource compute-heavy AI tasks to a dedicated network of GPU and Trusted Execution Environment (TEE) nodes.
(d) Primary token functions
The OpenGradient token has several key functionalities within the OpenGradient Network ecosystem. The platform offers a suite of goods and services designed to transform AI from a centralized gatekeeper model into an open, verifiable infrastructure for hosting, executing, and verifying AI models. Key utilities of the OpenGradient token include:
- Protocol Governance: OpenGradient holders can vote on network upgrades and the on-chain registry of approved enclave code.
- Internal Settlement: The token is used as the medium for internal chain settlement and rewards, distinct from external gateway payments.
- Model Hosting: Users can use tokens to upload models to the decentralized Model Hub.
- Validation and Staking: The token grants access to staking rights within the consensus mechanism and allows users to earn rewards for maintaining CometBFT consensus.
(e) Control surface reliance
Currently the governance is done by the OpenGradient Foundation. There are no immediate plans to convert to a token-based DAO structure, however as the protocol and network matures, we will re-evaluate this continuously. Currently, the OpenGradient Foundation holds multisigs for token allocations.
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 |
|---|---|---|
Matthew Wang | Co-founder & CEO | Quantitative Research & Engineering at Two Sigma (2020–2024), where he built research and modeling infrastructure for equity options market-making. Previously ML Intern at Google (ads traffic estimation), SWE Intern at Meta (Messenger/Instagram infrastructure), and SWE Intern at NASA (hazard data analytics). B.S. Electrical and Computer Engineering, Northwestern University. |
Adam Balogh | Co-founder & CTO | Tech Lead AIP at Palantir Technologies (Oct 2017–Feb 2024, 6.5 years), where he conceived, designed, and led development of major Palantir AIP projects. Previously SWE Intern at Amazon (2016) and Google (2015). M.S. Advanced Computing, Imperial College London. |
Advait Jayant | CSO | Founded SuperSight (2022–2024), a venture-backed AI analytics platform that scaled to 200K+ users and raised $1.27M at $20M valuation. Subsequently founded Peri Labs (2024–2025), an edge AI research lab anchored at Imperial College London (IP acquired). Previously Head of Research at Fabric Ventures ($140M UK-based VC fund, 2021–2022), Lecturer at UCL (Portfolio Management, 2022–2023), MakerDAO Delegate (2021–2022), and O'Reilly Author with 50+ publications on AI (2019–2022). |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
Tiaan Van Wyk | Sole Director | Manager at Deloitte (2024); Head of Operations at Lemma; Senior Manager at MainNet Partners |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
N/A | N/a | N/A |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
- (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) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) 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. The project is currently operated by the core development team and governed by the OpenGradient Foundation.
(b) Contract/admin powers
N/A
(c) Locked-token rights (conditional)
N/A
(d) Value accrual & holder rights
The OPG token is a decentralized digital asset designed for functional use within the OpenGradient Network ecosystem. Any "rights" are limited to the token's protocol-level utility. Currently, there are no rights for revenue or treasury, but this will be re-evaluated in the future as the protocol matures. The treasury is managed by the OpenGradient Foundation.
(e) Dissolution authority
N/A
Primary Foundation
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are 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) and an explanation of any subsidiary entities.
- (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; "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
Entity: OpenGradient Foundation - Cayman Foundation
(b) IP ownership & control
The entity owns Deliverables that modify/improve/derive from the Company's existing property. Specifically, the smart contracts that make up the core Network protocol. Subsidiary: the Foundation owns a BVI subsidiary that acts as the token issuer.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
The Foundation oversees the network and ecosystem. It retains veto power and execution authority over all changes to the system or network. Protocol upgrades are executed via a multi-signature wallet controlled by the members of the OpenGradient Foundation. Funds are held in a 3-4 multisig where two of the four seats are held by personnels from the Foundation.
(d) Powers over DevCo
The Foundation does not exert direct operational control over DevCo’s day-to-day decision-making. DevCo operates independently and is responsible for product development, engineering execution, and operational activities. The Foundation’s role is primarily limited to ecosystem stewardship, grant allocation (where applicable), and supporting long-term protocol growth. Any interaction between the Foundation and DevCo is generally limited to coordination, funding flows, or high-level ecosystem alignment rather than binding operational directives.
(e) Contract/admin powers
2/3 multisig
(f) Current economic arrangements and distribution policies
The Foundation entity pays DevCo the cost of all services listed in the Service Agreement plus 10% of that amount. DevCo is responsible for sending invoices to the Foundation, and the Foundation shall settle any invoices within 30 days of receipt.
Primary Dev Co
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are 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) and an explanation of any subsidiary entities.
- (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
US entity, Delaware C corp
(b) IP ownership & control
The US DevCo owns： Anything built before the Service Agreement started Anything built independently of the Services (on their own time/resources) APIs, SDKs, or software that integrates with or provides a UI to the Network Anything that isn't a smart contract constituting the core protocol Anything that isn't a Deliverable
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
N/A
(d) Powers over Foundation
DevCo does not exert direct control over the Foundation’s decision-making. The Foundation operates as an independent entity responsible for ecosystem stewardship, grant allocation, and governance-related activities. While DevCo may collaborate with the Foundation on ecosystem initiatives and provide technical input, it does not have authority over Foundation governance decisions, treasury management, or grant-making processes. Any coordination between the two is advisory in nature rather than directive.
(e) Contract/admin powers
2/3 multisig
(f) Current economic arrangements and distribution policies
The Foundation entity pays DevCo the cost of all services listed in the Service Agreement plus 10% of that amount. DevCo is responsible for sending invoices to the Foundation, and the Foundation shall settle any invoices within 30 days of receipt.
Token Supply & Allocations
Initial Allocation
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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
OPG | 2026-04-21 | Airdrop | Community | 4.00% | 40,000,000 | 100.00% | 40,000,000 | 0 | 0.00% | 0 | 0 | Yes | Retroactive airdrop to testnet developers and early | |
OPG | 2026-04-21 | Liquidity & Exchange Incentives | Liquidity | 6.00% | 60,000,000 | 100.00% | 60,000,000 | 0 | 0.00% | 0 | 0 | Yes | Market makers, exchange liquidity pools, and | |
OPG | 2026-04-21 | Ecosystem | Ecosystem | 40% | 400,000,000 | 10.00% | 40,000,000 | 0 | 0.00% | 60 | 1 | Conditional | Developer grants, strategic partnerships, | |
OPG | 2026-04-21 | Foundation | Treasury | 15% | 150,000,000 | 33.33% | 49,995,000 | 0 | 0.00% | 48 | 1 | Conditional | Protocol development, operations, and exchange | |
OPG | 2026-04-21 | Core Contributors | Insiders | 15.45% | 154,521,725 | 0.00% | 0 | 12 | 0.00% | 36 | 1 | Yes | Founding team and employee allocation (Vanna | |
OPG | 2026-04-21 | Investors + Advisors | Private / VC | 9.55% | 95,478,275 | 0.00% | 0 | 12 | 0.00% | 36 | 1 | Yes | Strategic seed investors and advisors providing | |
OPG | 2026-04-21 | Staking Rewards | Other | 10.00% | 100,000,000 | 0.00% | 0 | 0 | 0.00% | 96 | 1 | Conditional | Validator/delegator emissions to secure Proof-of-Stake network. |
Airdrop Process
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, 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. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
(a) Planned but not yet executed airdrop
N/A
(b) Executed airdrop
The project has already executed an initial airdrop
Here is the source: https://github.com/OpenGradient/airdrop/blob/main/registrations/sablier_recipients.csv
Categories: BitQuant users (amount of token swaps executed on BitQuant and chat messages sent) Discord OG role holders (early contributors on Discord) TwinFun users (people who traded twins on-chain) Discord Alpha OG role holders (contributors who provided value to the project) Testnet x402 Developers (developers who used our verifiable inference via x402) Model Hub users (developers who uploaded models to the model hub) Testnet V2 users (users who executed transactions on our testnet) TwinFun Testers (users who contributed valuable feedback to our twinfun early MVP)
(c) No airdrop planned or conducted
N/A
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; doing so earns full credit. 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) without describing trading strategy or expected outcomes. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
EFRA | 59,571 (0.0059%) | 12 months | Loan |
FalconX | 6,000,000 (0.6%) | 18 months | Loan |
CEX / DEX 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 |
|---|---|---|---|
Binance (Spot Listing) | 1.61% total supply | Marketing fee: 6-month vesting Marketing activities: N/A (at Binance's discretion) | N/A |
Binance Alpha + Perps | 3.3% total supply | Airdrop allocation utilized 6 months after TGE in different batches | $250K refundable deposit (refunded 6 months post-TGE if liquidity requirements met); $1M TVL for DEX LP (500K each side) |
Bybit | 1.0121% total supply | N/A no term durations specified in contract | Marketing Budget: 10M OPG Security Deposit: 300K USDT Market Assurance: 30K USDT + 120K OPG |
Bithumb | 0.075% total supply | N/A no term durations specified in contract | N/A |
Coinbase | N/A | N/A no term durations specified in contract | Free |
Gate | 0.032% total supply | N/A no term durations specified in contract | $80,000 |
MEXC | 0.0015% total supply | N/A no term durations specified in contract | $15,000 |
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 Vehicle | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
Seed | SAFE+Token Warrant | March 11, 2024, to September 27, 2025 | 9.55% | 1-year cliff, then monthly linear vesting over 3 years |
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 (optional) — Link(s) to post-mortem/advisory/PR.
(a) Date & component affected
No exploits affecting tokenholders or protocol funds as of 2026-05-21.
(b) Exploit vector summary
N/A
(c) Quantified impact
N/A
(d) Remediation/response taken
N/A
(e) Current status
N/A
(f) References (optional)
N/A
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
Since OPG has completed TGE, changes in laws, regulations, or enforcement priorities could impact the project’s ability to maintain token listings on centralized or decentralized trading venues. Regulatory developments may also require modifications to token functionality, geographic restrictions, or onboarding procedures. Regulatory or legal developments may impact the Foundation, DevCo, contributors, or service providers supporting the ecosystem. In response, entities may need to adjust operational structures, compliance procedures, or geographic operations. The tax treatment of digital assets and token-related transactions remains uncertain and may vary across jurisdictions. Tokenholders may be subject to taxes related to acquiring, holding, transferring, staking, or disposing of tokens. Tokenholders are solely responsible for understanding and complying with their own tax obligations and should consult independent tax advisors regarding their specific circumstances. The project may implement jurisdictional or user-based restrictions in response to evolving legal and regulatory requirements.
(b) Protocol, Technology & Security Risks
The protocol’s smart contracts, infrastructure, and related software may contain bugs, vulnerabilities, design flaws, or implementation errors. Such issues could result in unintended behavior, security incidents, downtime, or disruption of protocol functionality. Dependencies on third-party infrastructure, external integrations, or blockchain networks may introduce additional risks outside the project’s direct control. The project may utilize various security measures. However, no security measure can guarantee the absence of vulnerabilities or prevent all potential exploits, attacks, or failures. Security incidents may still occur despite these measures.
(c) Token Economics, Unlocks & Incentive Risks
The long-term sustainability and growth of the ecosystem may depend on factors including developer adoption, demand for protocol services, network participation, liquidity availability, and broader digital asset market conditions. If these assumptions do not materialize, the protocol may experience reduced usage, lower ecosystem participation, or adverse impacts on token utility and ecosystem growth. Future governance mechanisms may enable modification of certain protocol or economic parameters over time.
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. OpenGradient is solely responsible for the content, accuracy, and legality of its disclosures.
