plaza.fun — Native Asset Activation Layer for Polkadot Hub: Retroactive Development Funding
This referendum requests $110,000 USDT (Asset Hub USDt) as one-time retroactive development funding for plaza.fun: a live app on Polkadot Hub proving that native assets + EVM execution can produce real user activity. This is a live mainnet product, not a concept, pitch deck, or testnet-only demo. plaza.fun lets users create pallet_assets tokens, trade them through bonding curves, and graduate successful tokens into PlazaSwap liquidity with 90% LP permanently burned and creator fee rights represented by FeeKeyNFTs.
1. Summary
This referendum is not asking the Treasury to fund a concept, pitch deck, or testnet-only demo; it requests retroactive development funding for shipped infrastructure that users can already access and verify.
Specifically, this proposal covers delivered native asset activation infrastructure: native asset creation, bonding curve launches, the PlazaSwap graduation path, indexer, frontend, documentation, and upstream contributions to the Polkadot Hub EVM ecosystem.
plaza.fun is a native asset activation layer on Polkadot Hub: a production application that turns Hub's native asset infrastructure into a usable consumer workflow.
Users can:
- create a
pallet_assetstoken through a web UI - trade it immediately through bonding curve liquidity
- graduate it into PlazaSwap liquidity when the curve fills
- benefit from a graduation design where 90% of LP tokens are permanently burned
- give creators transferable fee rights through FeeKeyNFTs
Polkadot Hub already has the core ingredients for an application-centric future: native assets, EVM execution, stablecoins, shared security, and low fees. plaza.fun activates those primitives in a real application. Every token created through plaza.fun is a Hub native asset. Every trade settles on Hub. Every graduation creates Hub-side liquidity.
This proposal requests one-time retroactive funding for completed development work from January to April 2026. It does not include future milestones, forward funding, marketing spend, liquidity incentives, or operating runway.
2. Request
| Field | Value |
|---|---|
| Track | Medium Spender |
| Request | $110,000 USDT (Asset Hub USDt) |
| Payment type | One-time retroactive payment |
| Period covered | January - April 2026 |
| Beneficiary | The beneficiary account specified in the on-chain call |
| Named accountable party | Elvis (@elvis_build, Subsquare identity) |
| Future milestones | None |
| Forward funding | None |
3. Why Native Asset Activation Matters
Hub is not just another EVM chain. Its strongest differentiator is that assets can be runtime-level pallet_assets, exposed to EVM contracts through precompiles and prepared for native Hub/XCM workflows.
That advantage only matters if real applications make those assets easy to create, trade, and use.
plaza.fun activates this layer in three ways:
- Creation: anyone can create a Hub native asset through a consumer UI, without deploying a separate ERC-20 contract.
- Trading: each token has immediate bonding curve liquidity, creating Hub transactions from day one.
- Graduation: successful tokens can move into DEX liquidity, with permanent LP burn and creator fee rights.
This turns dormant infrastructure into live application activity.
4. Delivered Work
The delivered system covers the full token lifecycle:
Create native asset
-> Bonding curve trading
-> Curve fills
-> Automatic graduation
-> PlazaSwap pair created
-> 90% LP burned forever
-> 10% LP locked in creator vault
-> Creator earns through transferable FeeKeyNFT
Delivered components:
| Component | Delivered scope | Status |
|---|---|---|
| Bonding curve launchpad | Native asset creation, buy/sell flow, fee routing, graduation threshold logic | Mainnet deployed |
| PlazaSwap V2 | Uniswap V2-style DEX for graduated assets and general ERC-20 pair routing on Hub | Mainnet deployed |
| Graduation system | Moves a token from bonding curve to DEX liquidity, burns LP, locks creator LP position | Mainnet deployed |
| FeeKeyNFT + CreatorFeeVault | Transferable creator revenue rights after graduation | Mainnet deployed |
| Frontend application | Create, explore, trade, token pages, swap/pool surfaces, blog/documentation | Live at plaza.fun |
| Indexer / backend | Real-time event indexing, relayer paths, LP harvester, data APIs | Running on mainnet |
| Security and governance controls | Internal security review, critical/high fixes, TimelockController, Guardian emergency pause | Complete |
| Verified contracts | Contract source code verified on Blockscout, available for public review | Verified |
The table above lists shipped mainnet components rather than future roadmap items.
5. Differentiation
Most token launchpads deploy ERC-20 contracts from a factory. plaza.fun's core design is different: tokens are Hub native assets.
| Generic ERC-20 launchpad | plaza.fun on Polkadot Hub |
|---|---|
| Deploys a new ERC-20 contract per token | Creates a pallet_assets runtime asset |
| Liquidity is usually external or manually bootstrapped | Bonding curve liquidity exists from creation |
| Post-launch liquidity can be pulled or migrated | Graduation burns 90% of LP tokens permanently |
| Creator economics often stop at launch | FeeKeyNFT creates transferable creator fee rights |
| Mostly app-local activity | Every token and trade exercises Hub-native asset infrastructure |
plaza.fun is not only an EVM app deployed on Hub. It is an application that turns Hub's native asset model into something users can create and trade without understanding the underlying runtime.
6. Mainnet Data Snapshot
Organic mainnet activity has continued with no marketing spend, no incentive program, and no airdrop — confirming that native asset creation on Hub attracts real users when made accessible through a usable consumer interface.
Snapshot from plaza.fun/explore, cross-checked against the production Supabase index, fetched on 2026-05-25:
| Metric | Value |
|---|---|
| Visible active tokens | 19 |
| Bonding curve trades | 346 indexed trades |
| Indexed bonding-curve trading volume | ~5,038.55 DOT across 346 indexed trades |
| Highest visible market cap | ~695.64 DOT |
| Holder activity | All 19 visible tokens show holder activity; top token has 13 holders |
| Trade activity | All 19 visible tokens show trade activity |
| Graduation progress | Top visible token is 27% toward graduation |
| Community feedback | Active feature requests, including a deployers page and clearer creator visibility |
The trading-volume figure comes from the production Supabase index (omni_trades.quote_amount, polkadot-hub-mainnet). This early traction is a signal, not a scale claim. It also shows that activity did not stall after the first week: visible active tokens increased from the 2026-05-16 snapshot, indexed trades reached 346, indexed bonding-curve volume reached ~5,038.55 DOT, and the current highest visible market cap remains materially above the first-week ~270 DOT level. The point is simple: when native asset creation and trading are accessible through a usable application, organic behavior appears on Hub without incentives.
No token has graduated yet. The graduation threshold (2000π DOT, about 6,280 DOT; roughly $8K at recent DOT rates) is a deliberate design choice: graduation should signal real market conviction, not a speed-run. As of this snapshot, the leading visible token is 27% toward graduation. The graduation mechanism is deployed and designed to execute automatically when the threshold is reached.
7. Ecosystem Contributions From The Build
Building plaza.fun also surfaced practical Hub EVM integration lessons and upstream contributions:
Upstream issues filed:
paritytech/polkadot-sdk#11525— Discovered a platform-level issue with complex call chain behavior throughpallet_revive.call. Filed with full reproduction steps, component isolation, and an async graduation workaround. This is the kind of builder feedback that helps harden Hub's EVM layer for all future dApps.paritytech/hardhat-polkadot#430— PVM / tooling bytecode-size findings, transferred frompolkadot-sdk#11526.
Integration patterns developed:
- Built DirectAdapter and async graduation patterns to work around precompile/router and heavy-call limitations. These patterns are now documented and available for other Hub builders.
- Documented
pallet_assetsERC-20 precompile edge cases, including metadata and approval integration issues.
Technical documentation:
- Published a 7-part Builder's Journal (Hub architecture, bonding curves, fee design, token lifecycle, security, governance, and lessons learned from building on pallet_revive).
These are supporting contributions. The primary delivered value is the working native asset activation layer.
8. Budget
| Workstream | Delivered scope | Effort | Subtotal |
|---|---|---|---|
| Core protocol contracts | Bonding curve, native asset lifecycle, fee config, registries, creator fee logic, upgrade/governance controls. 47 Solidity files (approx. 11,200 lines source), 177 test files (approx. 80,500 lines). | approx. 5 FTE-months | $39,000 |
| PlazaSwap + graduation system | Uniswap V2-style DEX deployment, graduation flow, LP burn/lock mechanics, adapter patterns. 6 contracts including factory, pair, router, adapters. | approx. 3 FTE-months | $22,000 |
| Frontend application | Create, explore, trade, token details, swap/pool surfaces, blog and product UI. Next.js, 40+ pages/routes. | approx. 4 FTE-months | $21,000 |
| Indexer / backend / relayer | Event indexing, APIs, relayer paths, LP harvester, production data plumbing. Cloudflare Workers + Supabase. | approx. 3 FTE-months | $18,000 |
| Security review + QA | Internal review, critical/high fixes, permission checks, production verification. | approx. 1.5 FTE-months | $7,000 |
| Technical documentation + upstream issue work | Builder's Journal (7 parts), GitHub issues (#11525, #11526), reproduction repos, Hub EVM integration writeups. | approx. 1.5 FTE-months | $3,000 |
| Total | approx. 18 FTE-months | $110,000 |
Team composition: 4 full-time + 2 part-time (approx. 25-30%) over 4 months (January–April 2026), yielding approximately 18 FTE-months. Effective blended rate: approx. $6,100 per FTE-month, still materially below typical senior Web3 engineering rates.
This request includes:
- no contingency line
- no marketing budget
- no liquidity subsidy
- no future milestone budget
- no operating runway
9. Why Retroactive
This proposal is retroactive so voters can evaluate shipped work instead of promises.
The system has already been built and deployed. The requested work does not depend on future Treasury payments. If this referendum passes, it funds completed development work. If it does not pass, the deployed product, contracts, documentation, and issue history remain public and operational. The team continues to maintain the platform. The deliverables — deployed contracts, open-source code, and public documentation — are already in the community's possession and cannot be withdrawn.
The platform is intended to be self-sustaining through:
- 1% bonding curve trading fee
- 6.28 DOT token creation fee
- future PlazaSwap fee revenue and platform-owned liquidity funded from platform revenue
Any future Treasury request, if ever submitted, should be scoped separately around new ecosystem contributions and judged on its own merits.
10. Beneficiary And Accountability
The beneficiary of this referendum is the account specified in the on-chain call. Elvis is the named accountable party for delivery and post-funding reporting.
The team will publish or link the following alongside this referendum:
- beneficiary address
- Elvis on-chain identity / Subsquare profile: Elvis | plaza.fun
- final spend asset and amount
- confirmation that the beneficiary is not an exchange or custodian address
If funded, Elvis commits to publishing monthly updates for 6 months covering:
- tokens created
- bonding curve trades and volume
- graduations, if any
- PlazaSwap liquidity and pairs
- fee revenue
- upstream
pallet_revive/ Hub EVM follow-up work - user feedback and product changes
We ask voters to evaluate the delivered code, deployed contracts, and public documentation — all verifiable today.
11. Prior Polkadot Funding History
- No prior Web3 Foundation grant received.
- No prior successful Polkadot Treasury funding received.
- Two earlier signal proposals (#1853 Small Tipper, #1854 Wish For Change) were submitted on incorrect tracks. The product was then shipped before returning with this retroactive proposal.
- DeFi Builders Program / DeFi Bounty outreach is a separate workstream and does not duplicate this retroactive ask.
- No overlapping active Treasury proposal is in flight for plaza.fun.
12. Current Gaps
To keep the proposal honest:
- No external audit yet. Internal security review was conducted using AI-assisted analysis (Codex and Claude), with critical/high findings resolved. Contract source code is verified on Blockscout and available for independent review. External audit is not included in this retroactive budget.
- Early traction, not scale. Mainnet activity exists, but it is early organic usage, not a mature growth metric.
- No graduation yet. The mechanism is deployed, but no bonding curve has reached the 2000π DOT graduation threshold.
- Small team. The team is not a large, VC-backed organization. The accountability model is public code, on-chain verification, named Elvis accountability, and a public beneficiary account.
These gaps are why the proposal is scoped as retroactive funding for completed infrastructure, not a claim that plaza.fun has already become a large-scale consumer application.
13. Links
- Website: plaza.fun
- Explore: plaza.fun/explore
- Forum introduction: Introducing plaza.fun
- Builder reflection: Why I'm Still Building on Polkadot Hub | plaza.fun
- Twitter: @plaza_fun / @elvis_build
- Elvis Subsquare identity: Elvis | plaza.fun
- Elvis posted referenda: Subsquare profile / posted referenda
- Discord: discord.gg/B8ScBnBUwK
- Verified production contracts:
- Core lifecycle: OmniBondingCurve, GraduationManager, CreatorFeeVault, FeeKeyNFT
- PlazaSwap: Factory, Router, DirectAdapter
- Config and governance: FeeConfig, QuoteTokenRegistry, ProtocolParams, MetadataRegistry, LauncherRegistry, ReferralStorage, TimelockController
- Builder's Journal: plaza.fun/blog
- Builder's Journal articles:
- Part 0: The Plaza Brief
- Part 1: Why Polkadot Hub
- Part 2: The Bonding Curve
- Part 3: The Fee Engine
- Part 4: The Token Lifecycle
- Part 5: Security & Governance
- Part 6: Lessons & What's Next
- Issue #11525: pallet_revive call chain behavior
- Issue #11526: contract size limit / PVM tooling findings
- Reproduction repos: #11525 repro, #11526 repro
- Issue #430: PVM bytecode-size findings transferred to hardhat-polkadot
Comments (6)
Requested
Proposal Failed
Just when I thought you were one of the few legit teams and a ray of hope in the Polkadot ecosystem, this proposal showed typical grifterism, characteristic of OpenGov.
As with any startup, business, if you have a good product, you will succeed. There is no reason for OpenGov and DOT to fund a private business. I think you have a good product, a good idea, the product and business will be self-sustaining and I wish you all the luck to succeed.
Vote NO!
@14uk...GCEw
Thanks — and I appreciate you recognizing the product and the idea.
I agree with the principle: Treasury shouldn't fund a team's runway, marketing, or liquidity. Where I see it differently is treating a path to sustainability as a mark against already-shipped work. If anything, OpenGov should want more projects that can eventually stand on their own — that means rewarding adoption, not ongoing reliance.
Plaza was built, launched on Hub, and made verifiable before asking for anything. So to me the question is narrow: did the work already delivered create enough value for Hub to justify a one-time retroactive payment? Whether Treasury should carry the business going forward is a separate question — and there I agree, it shouldn't.
A sustainable product model is a strength for Polkadot, not a reason to dismiss the work.
I appreciate that plaza.fun shipped a live product and created activity on Polkadot Hub. The idea itself may be useful, and I do not want to dismiss the effort the team has put into building it.
However, I am not convinced that retroactively reimbursing private product development is the right use of Treasury funds, especially when the platform already charges creation/trading fees and retains future revenue upside.
Polkadot Treasury is not a VC investor. It receives:
If the product succeeds commercially, the upside appears to remain with the platform, while the development cost is being requested from the Treasury.
This also creates a broader precedent issue. Many ideas in the ecosystem are good, and many teams work hard to build useful products. But if the Treasury starts reimbursing platforms simply because they built something useful, then the same logic could apply to almost every product in the ecosystem.
That is not a sustainable funding model. Treasury should not become a general reimbursement mechanism for private product development.
If a product exceeds its budget or needs more capital to grow, the team should explore normal sustainability paths:
In this case, plaza.fun already has a fee model, so the sustainability of the product should be measured through organic usage and its own revenue generation.
If this is being positioned as public-good infrastructure, then I would expect stronger public-good commitments, including:
Without a stronger public-good return or reciprocal commitment, I do not think Treasury reimbursement is justified here.
@DW niraivettu
Fair criticism.
I agree that OpenGov is not a VC, and the Treasury should not generally reimburse every private product just because it was built.
This proposal will most likely fail, and that’s okay. But I still think the discussion is useful, because it shows the exact tension around funding application-layer work on Hub.
Plaza is not a pure public good. It has a fee model, and if it succeeds, the product should become self-sustaining. That part is true.
Where I see the public value is different: Plaza turned Hub native assets into a usable mainnet workflow, created real on-chain activity, documented the integration path, surfaced Hub EVM issues, verified contracts publicly, and gave future builders a working reference point.
Maybe voters decide that is not enough for Treasury funding. That is fair.
But if Polkadot wants more consumer apps on Hub, there needs to be some path to reward shipped application work, even when the product also has a business model. Otherwise the message is basically: build on Hub, create usage, take all the risk yourself, and if it works, Treasury still should not care because you might eventually earn fees.
On the transparency points, I agree those are fair asks. Fee revenue, fee recipient addresses, admin powers, and open-source scope should all be easy to inspect and clearer for voters.
Polkassembly is now a read-only archive. Commenting is disabled.