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
Throughout history, every form of currency has carried a fundamental tradeoff: the convenience of standardization against the risk of centralized manipulation. Bitcoin promised an alternative, but at just 7 transactions per second, it pushed users back to centralized exchanges and IOUs, recreating the very problem it set out to solve. ORE exists to advance the original vision for crypto: creating a peer-to-peer electronic cash that cannot be debased or controlled by centralized authorities. Built on Solana, ORE inherits the network's scalability, composability, feature-set and upgrades without requiring the tradeoffs traditionally associated with securing blockchain consensus. For these reasons, we describe ORE as future-proof electronic cash.
(b) Operational priorities
Regolith Labs' operational priorities are to maintain and improve the ORE protocol and its user-facing applications; strengthen decentralization, durability, and scalability; expand integrations across Solana; and make mining, staking, and self-custody more accessible.
Ongoing development, operations, and marketing are funded through a 1% administrative fee collected each time SOL is deployed through the mining protocol. This creates a recurring source of funding tied directly to protocol usage and supports continued engineering, infrastructure, ecosystem development, and user growth.
(c) High-level project overview
ORE is a Solana-native asset and on-chain protocol, designed to serve as peer-to-peer electronic cash and a non-sovereign store of value. ORE has a maximum supply of 3,000,000 tokens and was fairly launched without any team or investor allocation.
The protocol distributes ORE through Grid Mining. Each minute, miners deploy SOL across a shared tile grid; rewards scale with tile selection and size. Mining activity generates protocol revenue, which is used to purchase ORE on the open market. Of the ORE purchased, 90% is buried and 10% is distributed to ORE stakers.
Miners claim earned ORE through a process called refining. A 10% refining fee is redistributed proportionally to miners who continue to hold unclaimed balances. Together, these mechanisms create a permissionless system for distributing ORE while supporting protocol-funded buybacks, staking rewards, and fee-sharing.
(d) Primary token functions
$ORE is the native asset of the ORE protocol and is designed to function as peer-to-peer electronic cash and a store-of-value asset. Its primary protocol functions are:
Mining reward: ORE is distributed to miners through Grid Mining. Staking: ORE holders can stake their tokens to receive a share of protocol revenues. Refining rewards: Unclaimed mining balances receive a proportional share of the fees paid when other miners claim their mining rewards. Transferability and composability: ORE can be held in self-custody, transferred, and used across compatible Solana applications.
ORE is not currently used for protocol governance and does not provide equity, ownership, or governance rights in Regolith Labs or another operating entity.
(e) Control surface reliance
Not applicable for ORE.
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 |
|---|---|---|
Hardhat Chad | Founder & CEO | Experienced developer and engineer. Built payments systems at a major technology company, then created multiple Solana infrastructure projects. |
Trey Buckingham | Head of Operations | Trey brings eight years of strategy consulting and management experience at a leading global professional services firm. |
Thep B. | Head of Growth, Marketing & Partnerships | Long-time core team member at Step Finance (2021–2026), one of Solana’s earliest and most widely used portfolio dashboards and ecosystem platforms. Served in multiple operational, marketing, and community-builder roles across Step Finance, Solana Allstars, and related brands. |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
No foundation exists |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
No DAO/onchain governance body exists |
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
a DAO does not exist.
(b) Contract/admin powers
a DAO does not exist.
(c) Locked-token rights (conditional)
a DAO does not exist.
(d) Value accrual & holder rights
All revenue flows and treasury activity are publicly disclosed and verifiable through open-source code and onchain data. The ORE token is not currently used for protocol governance and does not provide equity, ownership, or governance rights in Regolith Labs or another operating entity. Mining activity generates protocol revenue, which is used to purchase ORE on the open market. Of the ORE purchased, 90% is buried and 10% is distributed to ORE stakers. In addition to protocol revenue, a 1% administrative fee collected each time SOL is deployed through the mining protocol. This creates a recurring source of funding tied directly to protocol usage and supports continued engineering, infrastructure, ecosystem development, and user growth. Tokenholders have no rights to revenue collected from this administrative fee.
(e) Dissolution authority
a DAO does not exist.
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
No foundation exists.
(b) IP ownership & control
No foundation exists.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No foundation exists.
(d) Powers over DevCo
No foundation exists.
(e) Contract/admin powers
No foundation exists.
(f) Current economic arrangements and distribution policies
No foundation exists.
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
Type: C-Corporation State of Incorporation: Delaware Country of Jurisdiction: USA
(b) IP ownership & control
All intellectual property related to ORE is open source.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
ORE has no DAO or token-holder voting. The parts that matter most for the token are permanently frozen: the minting program has been made immutable, so the 3,000,000 hard cap and the ~2-ORE-per-minute issuance limit can never be raised by anyone, and there is no freeze authority — no one, including the team, can freeze, seize, or blacklist a holder's tokens.
(d) Powers over Foundation
ORE has no foundation.
(e) Contract/admin powers
ORE does not have a DAO-style governance executor (no tokenholder votes, veto, majority, or “3/5 multisig” process for protocol decisions). Admin / operator authorities (single keys, not DAO thresholds) include:
- Admin key — can update who the admin is (SetAdmin).
- Admin fee collector — automatically receives the 1% admin fee on SOL miners deploy.
- Bury/wrap authority — can run treasury ops used for buybacks/burns (wrap SOL, bury ORE / send yield).
(f) Current economic arrangements and distribution policies
Ongoing development, operations, and marketing are funded through a 1% administrative fee collected each time SOL is deployed through the mining protocol. This creates a recurring source of funding tied directly to protocol usage and supports continued engineering, infrastructure, ecosystem development, and user growth.
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 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
$ORE (Fully fair-launched with zero team/investor allocation) | 8/2/2024 | Mining | Community | 0 | 0% | 0.00% | 0 | no cliff | no cliff | no vesting | no vesting | No | All tokens in circulation were issued exclusively through mining and legacy boost programs. All data is fully onchain and publicly trackable. |
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
Not applicable. ORE has never conducted an airdrop and has no plans to conduct one in the future. Accordingly, there are no prospective recipient segments, allocation criteria, or wallet lists to disclose.
(b) Executed airdrop
Not applicable. ORE has never conducted an airdrop and has no plans to conduct one in the future. Accordingly, there are no prospective recipient segments, allocation criteria, or wallet lists to disclose.
(c) No airdrop planned or conducted
We have never conducted an airdrop to date and do not plan to execute one.
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 |
|---|---|---|---|
Not applicable. Neither ORE nor Regolith Labs has any agreements, arrangements, or commercial relationships with market makers. |
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 |
|---|---|---|---|
Not applicable. Neither ORE nor Regolith Labs has any agreements, arrangements, or commercial relationships with any centralized or decentralized exchange. |
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 |
|---|---|---|---|---|
No prior fundraising, OTC, or discounted MM sales have occurred. |
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-07-15.
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
Impact of Regulatory Change on TGE and Listings: Not applicable in the traditional sense. ORE conducted no TGE, presale, or capital-raising distribution. All circulating ORE was issued programmatically by the protocol to miners through its grid mining mechanism. Entity-Level Regulatory Impact: ORE's structure is deliberately simple: no foundation, no DAO, no offshore issuance vehicle. Regolith Labs, a Delaware-incorporated development company, builds open-source software for the protocol, which runs autonomously on Solana. Tokenholder Tax Treatment: Tax treatment of ORE is uncertain and varies by jurisdiction, including whether mined ORE is ordinary income at receipt, how it is valued when mined, and whether disposal gains are capital or ordinary. Jurisdictional & User Access Restrictions: The protocol is permissionless open-source software and does not restrict access by jurisdiction.
(b) Protocol, Technology & Security Risks
Bugs and Design Flaws: ORE's core protocol consists of on-chain Solana programs governing token issuance, grid mining rewards, and supply mechanics. As with any smart contract system, implementation errors could exist despite testing and review. Potential failure modes include: bugs in reward calculation or distribution logic that over- or under-issue ORE relative to intended emissions; errors in claim or checkpoint logic that temporarily lock or misallocate miner rewards; and economic design flaws in the grid mining mechanism that could be exploited to extract disproportionate rewards (e.g., through bot strategies or timing manipulation) without technically violating the code. ORE does not depend on bridges or rollups core protocol operation, which eliminates the largest historical sources of catastrophic loss in DeFi. The protocol does inherit Solana network-level risk: a chain halt or consensus failure would pause mining and claims for its duration, though on-chain state and balances would not be lost.
Security Measures & Their Limitations: The protocol's code is fully open source, allowing continuous public review, and its issuance logic has operated live on mainnet under adversarial conditions, including sustained bot activity, since launch. These measures have inherent limits. Audits are point-in-time reviews and do not cover subsequently deployed code or guarantee the absence of defects; open-source review depends on volunteer attention; and live operation demonstrates resilience only against attacks actually attempted to date. Economic and incentive-design flaws are particularly difficult to detect through code audits, since exploits of this type involve using the protocol as designed but in unanticipated ways.
(c) Token Economics, Unlocks & Incentive Risks
ORE has a fixed maximum supply of 3,000,000 tokens, which cannot be increased. The protocol’s economic model assumes continued participation in mining and demand for ORE-related activities. Mining and staking returns may depend on factors including SOL deployed through the protocol, protocol-generated fees, market activity, and the number of participants competing for or sharing rewards. If participation, fee generation, or demand declines, rewards and yields may decrease, liquidity may weaken, and the market value or utility of ORE may be adversely affected. ORE is not used to secure an underlying network, so these assumptions are economic rather than necessary for blockchain consensus or security.
No governance body can increase ORE’s maximum supply. However, certain protocol parameters, fee allocations, reward mechanics, or incentive programs may be modified through future protocol upgrades where technically permitted. Any such changes could alter expected mining or staking returns, redistribute economic benefits among participants, or otherwise adversely affect tokenholders. There is no guarantee that historical or currently displayed yields, fee revenue, or reward levels will continue.
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. Ore Protocol is solely responsible for the content, accuracy, and legality of its disclosures.