Pons
Blockchain Services+1 · Other AI+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
Token launches often require creators to supply liquidity, configure pools, manage migration, and convince users that liquidity cannot later be withdrawn. They also typically force every launch to trade against the same asset. Pons solves this with a fixed-supply bonding curve that provides trading from launch, automatically funds and creates a Uniswap v4 pool at graduation, and permanently locks the resulting liquidity. Creators can also select from approved pairing assets, which then serve as the currency for trading, graduation, liquidity, and creator payouts.
(b) Operational priorities
Pons is currently developed and operated by the core Pons team. The team maintains the public interface and supporting infrastructure, reviews approved pairing assets and community-takeover requests, and operates bounded fee sweeps when internal swaps are required. Operations are funded primarily through Pons’s share of protocol trading fees and launch fees. User funds and launch liquidity are not used to fund operations, and Pons does not custody user assets.
(c) High-level project overview
Pons Protocol is a non-custodial token launch protocol on Robinhood Chain. Creators deploy fixed-supply tokens with predefined onchain terms, while users buy and sell directly through a bonding curve. Once the graduation threshold is reached, the token automatically transitions into a Uniswap v4 pool with permanently locked liquidity. Launches may be paired with ETH or other approved assets, which are then used throughout the token’s lifecycle for trading, graduation, liquidity, and creator payouts. Pons also supports configurable creator fees, optional token buybacks with long-term vesting, and community takeovers for abandoned projects. All transactions are signed by users through their own wallets, and Pons never takes custody of their tokens or funds.
(d) Primary token functions
Token exists for entertainment purposes and does not give any right or claim to anything.
(e) Control surface reliance
Pons v2 is non-custodial, but it is not entirely free of operational control. Users sign transactions directly, launch terms are fixed at creation, and neither the creator nor Pons can mint additional supply, alter a live launch’s pairing asset or pricing, or withdraw graduated liquidity. The Pons team currently controls which assets may be used for new custom-pair launches, operates bounded fee sweeps that require internal swaps, can disable but not enable a creator-funded buyback, may propose delayed community takeovers, and can activate the seven-day recovery path for a failed graduation. These controls cannot seize user wallets or permanently locked liquidity. No transition to token governance or complete removal of these operational controls has been announced; any future decentralization should therefore be described as a potential evolution rather than a current commitment.
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 |
|---|---|---|
Ozan Aydin | Founder | RootsFi Founder, Software Engineer at Adesso Insurance Solutions GmbH |
Foundation
Full Name | Official Title | Prior Experience |
|---|---|---|
Does not exist |
DAO / Onchain Governance
Full Name | Official Title | Prior Experience |
|---|---|---|
Does not exist |
DAO Structure
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so for each sub question. Even if there is no DAO, there must be an answer to (d). Address the lettered items below.
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List on-chain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Current tokenholder governance rights and economic arrangements — If any, describe the current governance rights of tokenholders and any presently operative rights or arrangements relating to treasury actions, fee-routing, rewards, buybacks, or other protocol-controlled resources. If none, state that explicitly.
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
- (f) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., on-chain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
No DAO
(b) Contract/admin powers
No DAO
(c) Locked-token rights (conditional)
No DAO
(d) Current tokenholder governance rights and economic arrangements
No governance or economic rights.
(e) Control surface reliance
No DAO
(f) Dissolution authority
No DAO
Primary Foundation
For the Primary Foundation do the following independently. If a Foundation does not exist, state so for each sub question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary Foundation can be explained as the entity which is directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities, and the method/threshold for each (e.g., veto/majority/super-majority).
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly.
(a) Entity
No Primary Foundation exists as of 2026-07-29
(b) IP ownership & control
No Primary Foundation exists as of 2026-07-29
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No Primary Foundation exists as of 2026-07-29
(d) Powers over DevCo
No Primary Foundation exists as of 2026-07-29
(e) Contract/admin powers
No Primary Foundation exists as of 2026-07-29
(f) Current economic arrangements and distribution policies
No Primary Foundation exists as of 2026-07-29
Primary DevCo
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly across each sub-question. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definition: The primary DevCo can be explained as the entity which is directly involved in the issuance of the native token at launch.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional)
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
Pons Labs, LLC. Delaware.
(b) IP ownership & control
All IP controlled and owned by Pons Labs, LLC. No registered trademarks, smart contracts use MIT license.
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No DAO. Pons Labs, LLC controls treasury actions, protocol-controlled resources, token administration, or reward parameters via a 2 of 3 multisig.
(d) Powers over Foundation
No foundation.
(e) Contract/admin powers
All contracts are owned and controlled by the Pons Labs, LLC 2 of 3 multisig. Signers are team members and the same signers for pause/upgrade contract capabilities.
(f) Current economic arrangements and distribution policies
There are no formally adopted, approved, contractual, or programmatic mechanisms currently in place.
Token Supply & Allocations
Initial Allocation
Download the Worksheet, enable macros, complete the Initial Allocation sheet, then use Convert To CSV to export the file for import here. To make edits after importing, update the worksheet, use Convert To CSV again, then re-import the new CSV.
Ticker | Date | Allocation Category Name | Recipient Type | Allocation % | Allocation Tokens | TGE Unlock % | TGE Unlock Tokens | Cliff Months | Cliff Unlock % | Linear Vesting Months | Cadence Months | Circulating Treatment | Notes on what each category is used for | If applicable: Contract / Wallet address |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
PONS | 7/13/26 | Public Launch Supply | Public / Sale | 1 | 1000000000 | 1 | 1000000000 | 0 | 0 | 0 | 0 | No | Fixed 1,000,000,000 PONS supply. all supply entered circulation at launch and PONS did not launch through a bonding curve. PONS launched through the legacy v1 factory. Source: https://docs.ponsfamily.com/ | |
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 | |||||||||||||
PONS | 7/13/26 |
Airdrop Process
State the project's airdrop status plainly, and back it up:
- Never conducted and none planned for TGE: state so plainly.
- Planned but not yet executed: state the target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to balance or net position), and commit to publishing a recipient wallet list in a public channel and providing it to Blockworks quarterly until the initial TGE airdrop is fully completed.
- Already executed: state the covered user segments and the allocation method, and point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count.
Pons has never conducted an airdrop and does not plan one for TGE.
Transactions & Market Structures
Market Maker Agreements & Deals
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly. For each market maker, include in a table:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model).
If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for (b).
Market Maker Name | Token Allocation Committed | Term Duration | Structure Name |
|---|---|---|---|
Pons has no market-maker agreements or deals, and no native tokens have been loaned or allocated to market makers as of 2026-07-29. |
Exchange Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Exchange Name | Token Allocation Committed | Term Duration | Native Token Listing Fees |
|---|---|---|---|
No exchange agreements or deals exist. |
Financial Disclosures & Risks
Prior Token Sales & Fundraising
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
- (a) Series Name;
- (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.);
- (c) Date of sale (at least month & year);
- (d) Number of tokens sold (or % of total supply);
- (e) Vesting schedule.
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Series Name | Investment Instrument | Date Of Sale | Number of tokens sold | Vesting Schedule |
|---|---|---|---|---|
No prior fundraising token sales, material OTC token sales, or discounted market-maker token sales have occurred as of 2026-07-29. |
Previous Exploits Affecting The Native Token
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References — Link(s) to post-mortem/advisory/PR.
(a) Date & component affected
No exploits affecting tokenholders or protocol funds as of 2026-07-29
(b) Exploit vector summary
As of 2026-07-29, no incidents have directly affected the native token, supply, holder balances, token controls, or custody.
(c) Quantified impact
As of 2026-07-29, no incidents have directly affected the native token, supply, holder balances, token controls, or custody.
(d) Remediation/response taken
As of 2026-07-29, no incidents have directly affected the native token, supply, holder balances, token controls, or custody.
(e) Current status
As of 2026-07-29, no incidents have directly affected the native token, supply, holder balances, token controls, or custody.
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
Legal and regulatory risk
Pons v2 has no native token or TGE. Laws could still classify certain launches, fees, or Stock Token pairs as regulated activities, requiring licensing, disclosures, KYC, geo-blocking, or suspension. Users are responsible for legal access and their own tax obligations.
Technology and security risk
Pons is non-custodial but remains exposed to smart contract, bonding curve, Uniswap v4 hook, pairing asset, and operator failures. Audits and safeguards reduce risk but cannot prevent all losses. Locked liquidity and tokens sent incorrectly cannot be recovered.
Token economics and liquidity risk
Fixed supply and permanently locked liquidity do not guarantee demand, stable prices, or an exit. Launches may never graduate or may lose all value. Custom pairs add pairing asset risk, while taxes, slippage, skipped buybacks, and vested tokens can affect returns.
(b) Protocol, Technology & Security Risks
Pons depends on Robinhood Chain, Uniswap v4, approved pairing assets, and its own curve, hook, locker, escrow, and vesting contracts. Bugs could misprice trades, block graduation, misroute fees, bypass limits, or cause permanent fund loss. Network outages, reorganizations, sequencer failures, or pairing token defects could also disrupt trading.
Three independent audits are in progress with SB Security, Dingbats, and Pashov Audit Group. Safeguards include slippage limits, fixed launch terms, approved pairs, capped internal price impact, locked liquidity, and delayed recovery. No completed audits, formal verification, or public bug bounty are currently disclosed. These measures may miss economic, integration, access control, or unexpected contract interaction failures.
(c) Token Economics, Unlocks & Incentive Risks
Fixed supply and permanently locked liquidity do not guarantee demand, stable prices, or an exit. Launches may never graduate or may lose all value. Custom pairs add pairing asset risk, while taxes, slippage, skipped buybacks, and vested tokens can affect returns.
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. Pons is solely responsible for the content, accuracy, and legality of its disclosures.
