Proposals/canton-foundation/canton-dev-fund/#267GitHub ↗

Declined#267 Pull request

Funding Proposal by Jubilee: Privacy-Native NFT Marketplace & CIP-56 Reference Implementation for Canton

Opened 29-04-2026 by Jubilee-Market, last activity 6d ago

Incoming5.9 days29-04-2026
Needs Champion30 days05-05-2026
In Review18 days04-06-2026
Ready for Vote17 days22-06-2026
Voting Live13 days09-07-2026
Ready for Vote12 days22-07-2026
Voting Live37 days03-08-2026
Needs Revision1 day09-09-2026
Voting Live34 days10-09-2026
Declinedsince 14-10-2026

Waiting on: Decided on the board but the PR is still open; idle 6.5 days
Champion named in file: Jack Charlesworth — @jackcharlesworth
Discussion: 66 messages; 10 people

Development Fund Proposal Submission

Proposal file

/rfps/financial-markets-standards-verification/jubilee.md

Dev Fund 2.0 update

This proposal is now explicitly classified as an RFP-aligned proposal under RFP 12 — RWA Standards / Daml and Institutional RWA Workflow Standards, with secondary alignment to RFP 13 and RFP 14.

The proposal has been moved to the corresponding /rfps/financial-markets-standards-verification/ category and now explicitly documents the ecosystem need, beneficiaries, and adoption path required by the Dev Fund 2.0 transition.

The underlying scope, 600,000 CC funding request, four-milestone structure, workstream allocations, and binding adoption gates remain unchanged.

Review update

The proposal has been updated in response to Tech Ops feedback requesting a clearer separation between the marketplace and the reusable public-good infrastructure, together with a workstream-level budget and measurable adoption gates.

The revision makes five material changes:

Separate workstreams: the open-source infrastructure and the Jubilee reference marketplace now have distinct scopes, milestone deliverables, acceptance criteria, adoption logic, and funding allocations.
Current deployment status: the proposal reflects Jubilee's progress since the original submission from testnet validation to a controlled private MainNet review deployment.
Measurable adoption gates: each applicable milestone now includes minimum binding adoption gates. The previously stated higher transaction and ecosystem figures remain operational targets and reporting metrics rather than minimum acceptance thresholds.
Explicit workstream budget: the 600,000 CC request is now divided into 400,000 CC for Workstream A and 200,000 CC for Workstream B. Within Workstream A, 150,000 CC is ring-fenced for two independent third-party security audits and 250,000 CC is allocated to reusable public-good engineering and delivery.
Audit, release, and standards sequencing: MS1 completes audit readiness and provides the funding used to commission both audits at the start of MS2. The repository progresses from public architecture to core primitives, settlement modules, and then the full stable public-good release, with the full DAML contract suite and atomic payment distribution logic covered by the two independent audits. The proposal also documents the compatibility path from CIP-0056 V1 toward approved CIP-0112 V2.

The overall four-milestone structure and total 600,000 CC request remain unchanged. Individual deliverables, acceptance conditions, adoption gates, and workstream allocations have been refined in response to Committee feedback.

Summary

The proposal is organized into two connected but separately evaluated workstreams.

Workstream A — Open-source non-fungible asset infrastructure

Reusable Canton public goods released under Apache License 2.0:

an NFT-focused DAML implementation layer compatible with CIP-0056 V1, with a defined path for gradual adoption of CIP-0112 V2 features through its cross-version transition;
collection creation and minting primitives, including supply caps, mint stages, allowlists, and per-wallet limits;
party-based ownership and transfer flows;
listing, offer, counter-offer, and cancellation primitives;
fully backed on-ledger offer escrow;
atomic Canton Coin payment distribution for seller proceeds, platform fees, and creator royalties;
a browser-encrypted self-custody wallet reference implementation;
a staged public repository: architecture and interface materials in MS1, core asset implementation preview in MS2, settlement-module preview in MS3, and the complete stable public-good release in MS4;
developer documentation and runnable integration examples; and
two independent security audits covering the full DAML contract suite and atomic payment distribution logic.

The self-custody wallet reference implementation is published separately and is not represented as part of the audited DAML scope. Third-party bridge code is also outside the audit scope.

Workstream B — Jubilee reference marketplace

Jubilee Markets is the production reference implementation used to validate Workstream A under real Canton MainNet conditions.

The existing creator, user, wallet, marketplace, bridge, and operator surfaces provide the production environment required to validate collection creation and minting, ownership, discovery, offers, backed escrow, transfer, atomic settlement, external onboarding, and interoperability.

Since the original submission, Jubilee has progressed from testnet validation to a controlled private MainNet review deployment. Collection creation, minting, listing, purchasing, offers, counter-offers, cancellations, direct transfers, and atomic settlement are operational on MainNet under internal testing.

The grant therefore does not treat already implemented product surfaces as greenfield development. Workstream B funding supports their production hardening, external validation, integration testing, operational monitoring, ecosystem onboarding, MainNet settlement evidence, and real-user adoption of the reusable infrastructure delivered under Workstream A.

The first reference use case is intentionally art, PFPs, and digital collectibles because they are familiar to crypto-native users and provide a low-friction environment for repeated production validation. They are the starting point, not the limit of the infrastructure.

The longer-term objective is to reduce the engineering and audit burden for Canton teams developing other unique assets and rights, including certificates, licenses, memberships, tokenized documents, property-related rights, private-market positions, and other financial or real-world instruments. No specific regulated financial product or native fractionalization layer is included in the current grant scope.

The proposal spans four milestones over approximately 13–15 weeks. MS1 is estimated at 2 weeks; MS2 at 3–5 weeks, subject to the auditor schedules finalized in MS1; and MS3 and MS4 at 4 weeks each.

MS1 completes audit readiness and, upon acceptance and disbursement, provides the capital used to commission both independent audits immediately at the start of MS2.

The reference collection launch is not dependent on the grant-disbursement schedule and may occur before audit completion. If so, exposure remains controlled through the collection's fixed 1,000-NFT supply and allowlist-gated access at launch. Audit completion and remediation of critical and high-severity findings gate removal of the allowlist for broad public onboarding, the audit-complete designation, and the final stable public-good release.

The funding request remains 600,000 CC.

Scope separation

The two workstreams are technically connected but separately evaluated:

Workstream	Purpose	Primary outputs
A. Open-source infrastructure	Durable, reusable Canton public goods	CIP-0056 V1-compatible implementation layer, gradual CIP-0112 V2 feature-adoption path, collection creation and minting modules, ownership and transfer modules, marketplace primitives, backed escrow, atomic settlement, separate wallet reference implementation, two DAML/settlement audits, tests, documentation, and runnable examples
B. Production reference implementation & ecosystem validation	End-to-end production validation and adoption	Jubilee MainNet application, production hardening of existing surfaces, reference collection, creator and user validation, external onboarding, independent-user settlement activity, bridge integration, embedded OneSwap integration, USDCx settlement, monitoring, reporting, and ecosystem feedback

The workstreams also have an explicit funding split:

Workstream	Allocation
Workstream A — Reusable public-good engineering & delivery	250,000 CC
Workstream A — Ring-fenced third-party audits	150,000 CC
Workstream A total	400,000 CC
Workstream B — Production Reference Implementation & Ecosystem Validation	200,000 CC
Total	600,000 CC

The same underlying engineering deliverable will not be funded twice. Reusable protocol and public-good engineering belongs to Workstream A; MainNet integration, production validation, external onboarding, operational evidence, and adoption belong to Workstream B.

Adoption and acceptance design

The revised proposal introduces minimum binding adoption gates while retaining the previously stated higher growth figures as operational targets.

This structure is intended to demonstrate genuine external adoption without making grant acceptance dependent on artificial transaction generation or raw volume.

For measurement purposes:

Independent / external means a user, developer, collection, or project not owned, controlled, or operated by the Jubilee core team and not participating solely to satisfy a grant threshold.
Unique user means a distinct independently controlled Canton Party ID, to the extent reasonably identifiable from Jubilee's application and onboarding records.
Eligible user-initiated marketplace action means a MainNet mint, listing, offer submission or acceptance, purchase, or direct asset transfer executed by the user. Account creation, login, browsing, and other passive activity do not count.
Eligible marketplace activity excludes Jubilee-controlled accounts, operator or reviewer test accounts, self-trading, activity between accounts reasonably known to share the same beneficial controller, repetitive circular activity, and activity generated primarily to satisfy a grant metric.
Onboarding pipeline means an external project with a documented Jubilee onboarding record containing at minimum project identity, submission date, intended collection or use case, and current onboarding status. Informal expressions of interest alone do not qualify.
Each completed marketplace settlement is counted once regardless of the number of parties involved.

Raw transaction volume is not used by itself as a binding gate.

Workstream A adoption progression

Workstream A is developer-facing public-good infrastructure, so its gates measure independent technical validation rather than requiring another project to make a commercial production-integration decision.

MS2: at least one independent Canton developer or external technical team meaningfully evaluates the published architecture and core implementation preview.
MS3: at least one independent developer or technical team successfully executes a published settlement or escrow preview/test flow without Jubilee's private application code.
MS4: at least one independent developer or technical team sets up the final stable release using only the public repository and documentation and successfully executes a reusable module flow or runnable example.

Workstream B minimum adoption gates

MS2

at least 50 independent non-team MainNet users complete at least one eligible user-initiated marketplace action;
at least 25 eligible completed purchase or sale settlements occur.

MS3

at least 100 cumulative independent non-team MainNet users complete at least one eligible user-initiated marketplace action;
at least 75 cumulative eligible completed purchase or sale settlements occur;
at least two external collections or ecosystem projects enter the documented onboarding pipeline;
at least one of those projects completes a Canton MainNet launch through the production reference implementation.

MS4

at least 150 cumulative independent non-team MainNet users complete at least one eligible user-initiated marketplace action;
at least 50 completed USDCx-denominated purchase or sale settlements occur;
those USDCx settlements involve at least 20 distinct independent non-team user Party IDs.

The previously stated higher marketplace and ecosystem figures remain operational targets and will continue to be reported, but they are not the minimum binding thresholds for milestone acceptance.

If a minimum adoption gate has not been met at a scheduled milestone review, the adoption component remains pending until sufficient evidence is provided. Technical deliverables may still be evaluated separately by the Committee, and updated adoption evidence may be submitted during a remediation or extension period agreed with the Committee.

Clarifications for reviewers

Is this grant primarily funding an art or PFP collection?

No. The collection is the first production reference use case and adoption vehicle.

The durable grant output is reusable open-source infrastructure that Canton developers can independently evaluate and run, together with two independent security audits covering the full DAML contract suite and atomic payment distribution logic.

Why start with collectibles?

A new infrastructure layer needs a real production environment in which collection creation, minting, ownership, backed escrow, trading, and settlement can be exercised repeatedly.

Collectibles are familiar to crypto-native users, have an existing adoption base, and provide a practical first validation environment without requiring the proposal to depend on hypothetical institutional demand.

What broader use cases can the infrastructure support?

The same primitives may support applications involving unique certificates, licenses, memberships, documents, property-related rights, private-market positions, and other financial or real-world instruments.

Each future application would still require its own economic model, legal structure, compliance logic, and product-specific functionality.

Does the current grant include fractionalization?

No.

Native fractionalization is outside the current grant scope. The current proposal establishes the underlying collection creation, minting, ownership, transfer, escrow, permissioning, and settlement primitives first.

Why keep both workstreams in one proposal?

The marketplace is the production reference environment that validates the public-good modules.

Separating scope, acceptance criteria, adoption gates, and budget makes the distinction explicit while preserving the implementation relationship required for end-to-end MainNet validation.

Is Workstream B funding functionality that is already built?

Not as greenfield functionality.

Jubilee has already implemented substantial marketplace, creator, wallet, bridge, and operational surfaces. The funded Workstream B work focuses on production hardening, external validation, interoperability, ecosystem onboarding, independent-user settlement validation, monitoring, reporting, and gathering production evidence and feedback for the reusable Workstream A components.

Checklist

Proposal file moved under /rfps/financial-markets-standards-verification/ for Dev Fund 2.0 RFP alignment
Marketplace and infrastructure workstreams separately scoped
Explicit 400,000 CC / 200,000 CC workstream allocation defined
150,000 CC ring-fenced third-party audit budget defined within Workstream A
Existing milestone totals preserved
Separate deliverables and acceptance conditions included for both workstreams
Minimum measurable adoption gates included from MS2 onward
Previously stated higher adoption figures retained as operational targets
Eligible user/activity and external-project definitions documented
Anti-wash and duplicate-settlement counting methodology clarified
Alignment with Canton priorities described
Out-of-scope financial products and fractionalization clarified
Public repository staged from MS1 architecture through MS2 core primitives and MS3 settlement modules to an MS4 stable public-good release
Full DAML contract suite and atomic payment distribution logic covered by two independent audits
CIP-0056 V1 compatibility and gradual CIP-0112 V2 cross-version transition distinguished
Dev Fund 2.0 RFP mapping, ecosystem need, beneficiaries, and adoption framing explicitly documented

Notes for reviewers

Status: In Review; champion confirmed.

We are submitting under CIP-0100 as an external contributor team with a confirmed Tech & Ops Committee champion.

Items the Committee may want to focus on:

Public-good value beyond the marketplace. The core grant output includes reusable asset, escrow, transfer, settlement, testing, and documentation components, alongside a separately released wallet reference implementation, rather than a closed Jubilee-only implementation.
Token-standard alignment. Jubilee currently vendors and implements the CIP-0056 V1 DARs: NFToken and NFTokenV2 (amount = 1.0) implement Holding, and JubileeTransferFactory implements TransferFactory. For the allocation surfaces, Jubilee deliberately does not reimplement the standard; its atomic settlement flows exercise Splice's official CIP-0056 V1 AllocationFactory and Allocation implementations directly for the Canton Coin legs, and every backed offer locks the buyer's committed CC in a standard Allocation. CIP-0112 V2 is designed for a high level of backward compatibility with CIP-0056 V1 and supports a gradual cross-version transition. The proposal therefore defines a gradual V2 feature-adoption path rather than treating the current V1 implementation as a mandatory replacement.
Atomic settlement and backed offers. Platform fee, creator royalty, seller proceeds, and asset ownership settle in one atomic operation. Offers are backed by CC committed on-ledger before they become actionable by a seller.
Audit sequencing, scope, and budget. MS1 completes audit readiness and provides the funding used to commission both audits at the start of MS2. The audits cover the full DAML contract suite and atomic payment distribution logic. 150,000 CC is ring-fenced within Workstream A for the two audits. Third-party bridge code and the separately published browser wallet reference implementation are outside the DAML audit scope.
Audit timeline. MS2 is estimated at 3–5 weeks, subject to the auditor schedules finalized in MS1. Critical and high-severity findings must be remediated before the affected code is designated audit-complete, before broad public onboarding is opened, and before the final stable public-good release.
Production progress. Since the original submission, Jubilee has moved from testnet validation to controlled MainNet review and has provided MainNet transaction evidence for the principal marketplace flows. Workstream B therefore focuses on production hardening and external validation rather than presenting existing surfaces as unbuilt functionality.
Current fee model. The review build uses 0.1 CC placeholder fees per completed sale and per minted NFT. The planned public-launch schedule is a flat 3 CC per completed sale and 3 CC per minted NFT, with no percentage-based platform commission.
Acceptance design. Technical deliverables and applicable minimum adoption gates are binding. Higher marketplace and ecosystem targets remain operational reporting targets. The revised design also excludes team/test activity, self-trading, circular activity, and other metric-gaming behavior from the binding adopti

[truncated by CCPEDIA at 20000 characters; the issue body is 22430 — open the URL for the rest]

Milestones 4

MainNet Hardening, Audit Readiness & Public Architecture2 weeks
Independent Audits, Core Primitive Preview & Product Readiness3–5 weeks, subject to the auditor schedules finalized in MS1
Settlement Module Preview, Ecosystem Onboarding & Embedded OneSwap Integration4 weeks
USDCx Settlement, Multi-Chain Onboarding & Full Stable Public-Good Release4 weeks

Discussion65 comments, 1 review, 0 inline comments

1 automated message from bots hidden. Show bot messages

Showing 1 to 66 of 66, oldest first.

Jubilee-Marketcommented03-06-2026 · 4mo agoGitHub ↗

Updated the proposal based on feedbacks:

Removed explicit partner/vendor naming from the multi-chain bridge language and replaced it with more general multi-chain bridge integration wording.
Expanded the Team section with more context on the Jubilee core contributors and their responsibilities.
Strengthened milestone acceptance criteria with measurable targets around collection launch, external collection onboarding, marketplace transactions, volume/activity reporting, and open-source delivery.

jackcharlesworthreviewedapproved04-06-2026 · 4mo agoGitHub ↗

No text. The verdict is the content.

Jubilee-Marketcommented04-06-2026 · 4mo agoGitHub ↗

Updated the proposal to reflect the confirmed champion and added the 600,000 CC working funding request for review calibration.

Erlannn7commented18-07-2026 · 3mo agoGitHub ↗

This is a very interesting proposal, and I appreciate the effort to build reusable infrastructure for the Canton ecosystem rather than just another marketplace. Wishing the team success throughout the review process and beyond. If you ever need an active community moderator, beta tester, or someone to help engage users and collect feedback, I'd be glad to contribute. Telegram: @Erlannn7 Email: e***@gmail.com

hythlodacontributorcommented22-07-2026 · 3mo agoGitHub ↗

Feedback from tech ops is to have users post on this PR for evidence of demand. Also would want to separate out marketplace from the NFT standard

Jubilee-Marketcommented22-07-2026 · 3mo agoGitHub ↗

Feedback from tech ops is to have users post on this PR for evidence of demand. Also would want to separate out marketplace from the NFT standard

Thanks for the feedback.

We will invite users, creators, and Canton community members to share direct and independent feedback on this PR as evidence of demand.

For the second point, we propose keeping this as a single proposal while separating the marketplace and the NFT standard into two clearly defined workstreams, each with its own scope, deliverables, acceptance criteria, and funding allocation.

This would make the distinction between Jubilee's application-level marketplace work and the open-source NFT-focused CIP-56 reference implementation explicit, while preserving the technical relationship between the two.

Would this structure address the Tech Ops feedback?

Erlannn7commented22-07-2026 · 3mo agoGitHub ↗

From a community perspective, this could be really useful. A marketplace with proper escrow and clear settlement would make NFT interactions feel much more trustworthy. Curious to see how this develops on Canton 🙏

s0urleddcommented23-07-2026 · 2mo agoGitHub ↗

I've been active on Canton as a builder for a while. An NFT marketplace built natively for Canton would be a great addition to the ecosystem, definitely something the network needs. Supporting this. Good luck to the team

orwavescommented23-07-2026 · 2mo agoGitHub ↗

From a community perspective An nft marketplace with proper escrow and clear settlement would really spike community interest in NFT marketplace, increase onchain activity and would make NFT interactions a lot safer

And an atomic payment distribution pattern (platform fee + creator royalty + seller) would definitely help with users and creators retention

captainsnowboycommented23-07-2026 · 2mo agoGitHub ↗

As an active Canton community member, I can confirm we’ve been eagerly anticipating Jubilee Market going live. An NFT marketplace where people can trade their favourite collections will be a big positive for the ecosystem.

The community needs this and we’re hyped.

Erlannn7commented23-07-2026 · 2mo agoGitHub ↗

As an active Canton community member, I can confirm we’ve been eagerly anticipating Jubilee Market going live. An NFT marketplace where people can trade their favourite collections will be a big positive for the ecosystem.

The community needs this and we’re hyped.

I as a Canton community, I totally agree with you even other communities are waiting for the launch of Jubilee

G3rald9commented23-07-2026 · 2mo agoGitHub ↗

I'm an artist building a Canton native NFT collection called CANTON GENESIS, and I'm actively exploring launching it through Jubilee.

Having a dedicated NFT marketplace and launchpad on Canton would make a big difference for creators. It gives artists a place to launch collections that are built specifically for the ecosystem, helps us reach the Canton community more easily, and provides confidence that there is infrastructure designed for NFTs on the network.

As someone creating artwork for the Canton ecosystem, I'd be excited to see Jubilee continue to grow and support artists like myself.

X: https://x.com/G3rald_ezema

Avocadobot26commented23-07-2026 · 2mo agoGitHub ↗

I’ve been around the Canton ecosystem for a while, and am personally hyped for Jubilee. we need a dedicated NFT marketplace, as it would bring more attraction into the canton ecosystem .

Avocadobot26commented23-07-2026 · 2mo agoGitHub ↗

I’ve been around the Canton ecosystem for a while, and am personally hyped for Jubilee. we need a dedicated NFT marketplace, as it would bring more attraction into the canton ecosystem .

Realobafemicommented23-07-2026 · 2mo agoGitHub ↗

I've been an active member of Canton ecosystem for a while, a dedicate NFT marketplace will be amazing. Launching Jubilee will add to the Canton ecosystem and bring more attraction to the network

xurrydepcommented23-07-2026 · 2mo agoGitHub ↗

I believe some of the earliest work created within the Canton ecosystem could gain historical and cultural value over time. Jubilee could become one of the key platforms where collections from this early period are created and preserved.

kursatkorkmazx-speccommented23-07-2026 · 2mo agoGitHub ↗

Allowing different teams on Canton to launch collections through the same platform could create new connections between projects. What excites me about Jubilee is the possibility of it becoming more than just a marketplace, but also a shared space that brings different parts of the ecosystem together.

enespolat01commented23-07-2026 · 2mo agoGitHub ↗

I think digital collections can also be used as tools that provide access to certain benefits or privileges. This feature from Jubilee could give many projects new ways to engage with their communities and explore different ideas.

agungap2204-cloudcommented23-07-2026 · 2mo agoGitHub ↗

lfg jubilee. great move

gucluprizcommented23-07-2026 · 2mo agoGitHub ↗

It would be valuable for early contributors to a project to have digital badges that prove their involvement. Jubilee could help make contributions and participation history across Canton more visible.

WongRaencommented23-07-2026 · 2mo agoGitHub ↗

I would love to see joint collections created by different communities. Jubilee could make it possible for groups that normally operate independently to collaborate on shared campaigns and special releases.

hakan0xnftcommented23-07-2026 · 2mo agoGitHub ↗

Just like any chain needs, NFT culture needs to take root in Canton. For this, a marketplace is, of course, a priority. Networks where NFT culture is established can host both long-lasting and strong communities. That's why Jubilee's presence in Canton is essential.

utku3755commented23-07-2026 · 2mo agoGitHub ↗

Having a dedicated NFT marketplace on Canton is huge. Jubilee seems to offer exactly what the ecosystem needs for smooth trading and launching new collections. Really looking forward to seeing this live!

Bayramalikaplancommented23-07-2026 · 2mo agoGitHub ↗

For users to adopt an application, it needs to offer more than strong technology. The experience also has to be simple and enjoyable. If Jubilee can achieve that, it may even attract people who have never been interested in NFTs before.

uzaylisakcommented23-07-2026 · 2mo agoGitHub ↗

in my opinion, nfts on canton would be mostly rwa focused, rather than typical collections. and keeping their transfers and trades private is a huge deal. jubilee is being built as an open source platform where you can mint buy and sell these assets. as an experienced user i really cant wait to try it out

ctnsefacommented23-07-2026 · 2mo agoGitHub ↗

There is a need for such a marketplace on Canton. Being able to buy and sell NFTs and host great collections is crucial. I have no doubt that Jubilee will do an excellent job with this. After all, you know that what truly defines a community is its own NFT.

efsanedizzycommented23-07-2026 · 2mo agoGitHub ↗

People joining Canton for the first time should have interesting applications they can try right away. Jubilee could become a great starting point for users who are just discovering the ecosystem.

ravqrestcommented23-07-2026 · 2mo agoGitHub ↗

Canton already has a strong institutional foundation, but I think it also needs more applications that support art, culture, and community. Jubilee could become a great bridge between those two sides.

franklinn31commented23-07-2026 · 2mo agoGitHub ↗

first of all, i see a bright future for canton. i've been interested in nfts from the very beginning. when you bring these two together, there's no reason why canton shouldn't have an nft marketplace. why shouldn't the next bayc come from canton, right?

bhasangullcommented23-07-2026 · 2mo agoGitHub ↗

Jubilee’s focus on real utility, community participation, and creator support offers a healthier and more sustainable model for Canton. It feels built for the long term rather than being just another short-lived project.

0xTonyukukcommented23-07-2026 · 2mo agoGitHub ↗

Digital tickets or certificates of attendance could be very useful for physical events within the Canton ecosystem. If Jubilee makes these assets easy to create and verify, it could become a powerful tool for event organizers as well.

reddline617commented23-07-2026 · 2mo agoGitHub ↗

Every major network has its own unique NFT marketplace. Jubilee can fill this gap in the Canton ecosystem very well.

erdaleccommented23-07-2026 · 2mo agoGitHub ↗

It’s important for smaller communities to be able to create collections without having to deal with all the technical details. I believe Jubilee will make this process simple enough to open the door to many different and creative projects.

owgee-ethcommented23-07-2026 · 2mo agoGitHub ↗

Canton needs more spaces where teams building new projects can bring their ideas directly to users. I believe Jubilee can speed up this process and lead not only to new collections, but also to new collaborations across the ecosystem.

bitjointorgcommented23-07-2026 · 2mo agoGitHub ↗

Every ecosystem needs to build its own culture beyond the underlying technology. Collections can help shape that culture over time and make it more visible. I believe Jubilee could have a lasting impact in that regard.

TuffyDuckcommented23-07-2026 · 2mo agoGitHub ↗

Giving projects a way to offer exclusive digital assets to their supporters could help them build stronger relationships with their communities. If Jubilee makes this process accessible, it could create a valuable new communication channel for projects on Canton.

syftneth-engcommented23-07-2026 · 2mo agoGitHub ↗

Turning events, campaigns, and important moments on Canton into lasting digital collections could be a great use case. I believe Jubilee can become a platform where these memories are created and shared within the community, which is why I see it as valuable for Canton.

Be33ethcommented23-07-2026 · 2mo agoGitHub ↗

We’re seeing a lot of progress on Canton’s technical infrastructure, but we also need more applications that users can interact with directly. I believe Jubilee is one of the projects that could make the network feel more active, accessible, and easier to explore.

guildagcommented24-07-2026 · 2mo agoGitHub ↗

What I find most interesting about Jubilee is its potential to unlock use cases that haven’t been explored on Canton before. I’m genuinely curious to see how the first collections and communities will use the platform.

artscollabcommented24-07-2026 · 2mo agoGitHub ↗

For me, it’s not only about being able to buy and sell. I also want to discover new collections easily and connect with the people behind them. Since I believe Jubilee will handle this social side well too, it’s likely to become a platform I use regularly.

midasbalcommented24-07-2026 · 2mo agoGitHub ↗

honestly a native marketplace is long overdue for canton. you can't really build a strong community culture without nfts and verifiable badges. jubilee's setup with the testnet stuff looks super clean.

0xStegocommented24-07-2026 · 2mo agoGitHub ↗

i'd love to see an nft marketplace built into anton. i'd definitely use jubilee to collect community nfts, pick up badges, and discover new collections without leaving the ecosystem. i also like the idea of being able to launch a collection there one day, it just makes everything feel more connected.

Rodeoethcommented24-07-2026 · 2mo agoGitHub ↗

would love to see a native nft marketplace on canton. I'd definitely use it for trading nfts and probably launching collections too. Community badges and project nfts would be a nice addition.

Magnetccdcommented24-07-2026 · 2mo agoGitHub ↗

As an active user within the Canton ecosystem, Jubile is one of the projects I am most looking forward to. I am confident that Jubile will play a vital role in the Canton ecosystem.

An NFT marketplace is an exciting prospect I am truly anticipating Jubile and look forward to building together within the Canton ecosystem

Ayberkoscommented24-07-2026 · 2mo agoGitHub ↗

I think Jubilee’s real value lies in providing a foundation for creative ideas that haven’t even been imagined yet. Once the platform goes live, it will be really interesting to see all the different ways people choose to use it.

salimalitikocommented24-07-2026 · 2mo agoGitHub ↗

Allowing artists to earn a share from secondary sales after releasing their work is important for sustainable creation. I am especially interested in Jubilee because it can provide creators with a way to generate long-term income.

cryptomeiicommented24-07-2026 · 2mo agoGitHub ↗

I’ve been active in the Canton community for quite a while and currently help moderate the official Canton Discord and Telegram, along with the Temple Telegram.

From what I’ve seen, an NFT marketplace and launchpad is still missing from the ecosystem. I can see it being useful for community collections, badges, contributor rewards, event collectibles, memberships, and similar ideas.

I’d be interested in testing Jubilee on MainNet, and I think it could make it much easier for Canton communities and projects to launch these kinds of assets.

YessahBlessahCCcommented24-07-2026 · 2mo agoGitHub ↗

Dear Canton Network, Canton Foundation, and ALL $CC Investors,

I have never been into NFT's much in the past HOWEVER, we need to consider how valuable the "Canton Network" brand will be in the future! These will be original collector's pieces 1st of their kind with Canton as the brand!

We need an NFT marketplace here on cc. I personally have sent an Artist to the Jubilee team. The Canton Foundation just liked his artwork a few days ago...Mr Gerald on X! He racked up over 3,000 views on that post.

The people loved his work and so did the Foundation

We also have a big group of OG SUI investors who have also come to the Canton Network and are now buying cc and contributing to our community here. These guys are true MINTERS and have a lot of experience with NFT's! This group of power house X leaders / crypto OG's are just itching to get into Jubilee NFT marketplace.

Next, I have a friend from MONAD chain who actually just created an NFT Marketplace "Vault" of some sort but check this out folks! You can supply your NFT (same as supply cc into defi borrow / lend like alpend) and borrow against your NFT!!

This adds a whole new layer of liquidity into our Canton Ecosystem! We support Jubilee, new artists, new minters, and investors can purchase Original Collector's pieces of Canton Network Digital Art which will 100% guaranteed be HUGE winners and worth a lot of money as $cc climbs the market cap ranks and actually gets some brand awareness

Higher Ups would be Foolish not to launch this new Featured App as the community and investor base is already 100% here and ready Mint and Deploy money into NFT's!

**Me personally...ever since I met the team and thought about "Original Canton Artwork" I have been waiting to get my hands on an original collector's piece and am ready to do a bidding war with ANY of you investors out there

Launch Jubilee NFT!

Aloha & Mahalo, Yessah Blessah

**The team is one of the most down to earth teams I have been able to speak with during the past few months. Even the brief conversations tell me that these guys have the best interest of the cc community! The Jubilee Team is honestly the kind of Solid Actors we want here on the cc rails! Do NOT disregard Jubilee!

RPCdotcomcommented24-07-2026 · 2mo agoGitHub ↗

As the team behind RPCdot, we enjoy seeing projects that build on Canton's unique capabilities instead of following the same patterns seen on other networks. After reading the proposal and exploring Jubilee, we think the team has put significant thought into both the technical architecture and the long-term value it can bring to the ecosystem.

The focus on privacy by protocol, atomic settlement, self-custodial wallets, and an open-source CIP-56 reference implementation makes this feel like more than just another NFT marketplace. These are the kinds of building blocks that can benefit not only end users but also other developers building on Canton.

We also appreciate that the proposal emphasizes reusable infrastructure and open standards alongside the marketplace itself. Growing an ecosystem requires applications that users want to interact with, but also tools and reference implementations that make it easier for future teams to build.

Wishing the Jubilee team the best throughout the review process.

emrhnyzcommented24-07-2026 · 2mo agoGitHub ↗

i’ve been around canton for a while and i’d really like to see an nft marketplace here.

i already buy and sell nfts on other chains, so if canton projects start launching collections through jubilee i’d definitely use it. feels like one of the missing pieces in the ecosystem right now.

Akdemir2commented24-07-2026 · 2mo agoGitHub ↗

I believe that Jubile will be good for the Canton network. I want to see the Nft Marketplace

bravemissokacommented24-07-2026 · 2mo agoGitHub ↗

I've been following the Canton ecosystem for a while, and I believe there is room for better NFT infra A dedicated marketplace and launchpad would make it easier for creators and communities to build and engage on Canton. Jubilee looks like a project that can help fill this gap and attract more activity to the eco

Jubilee-Marketcommented24-07-2026 · 2mo agoGitHub ↗

Updated the proposal in response to feedback from Canton ecosystem stakeholders and reviewers:

The open-source non-fungible asset infrastructure and the Jubilee marketplace are now separated into distinct workstreams with their own deliverables and acceptance criteria.
The proposal now reflects Jubilee's progress since the original submission from testnet validation to a controlled private MainNet review deployment.
The fee model has been updated to match the current flat 3 CC sale / 3 CC mint launch plan, and third-party-dependent adoption figures are now reported operational targets rather than grant-disbursement conditions.
The open-source sequence has been clarified: the repository progresses from public architecture in MS1, to core asset modules in MS2, marketplace and settlement modules in MS3, and the complete stable public-good release in MS4.
The audit scope covers the full DAML contract suite and atomic payment distribution logic. Third-party bridge code is outside the audit scope. One audit firm is Canton Network's official audit solution partner and the other is an independent firm with DAML expertise. Both complete reports will be delivered to the Committee; public reports or summaries remain subject to auditor disclosure terms.
The collection launch and audit schedule are now explicitly separated. The reference collection may launch before audit completion because launch timing is not dependent on grant disbursement. If that occurs, exposure remains constrained by the collection's fixed 1,000-NFT supply and allowlist-gated access. Audit completion and remediation of critical and high-severity findings gate removal of the allowlist for broad public onboarding and publication of the final stable public-good release, with the full DAML contract suite and atomic payment distribution logic covered by the two independent audits.
The standards section now reflects the implemented CIP-0056 V1 relationships accurately: NFToken and NFTokenV2 implement Holding, JubileeTransferFactory implements TransferFactory, and Jubilee's settlement contracts consume Splice's official AllocationFactory and Allocation implementations rather than reimplementing the allocation surfaces. The gradual CIP-0112 V2 transition remains documented.
The self-custody wallet reference implementation remains a public-good deliverable but is explicitly separated from the audited DAML scope.
A documented, runnable non-collectible worked example has been added as an MS4 deliverable and acceptance condition, demonstrating the reusable modules outside an art or PFP use case.
A disclosure model paragraph now describes what is visible to whom across ownership contracts, marketplace listings, and published collection statistics.
The embedded swap deliverable now commits to OneSwap and uses Jubilee's built-in self-custody wallet; the separate swap-wallet connection deliverable has been removed.

The total working request and overall four-milestone structure remain unchanged, while individual deliverables and technical descriptions have been refined. Collectibles remain the first production reference use case, while the grant's durable output is reusable infrastructure intended to support broader non-fungible and financial applications on Canton.

cantonarmy77-uxcommented25-07-2026 · 2mo agoGitHub ↗

We’ve been considering launching an NFT collection on Canton, so this could be very useful for us.

riigormortiscommented27-07-2026 · 2mo agoGitHub ↗

NFTs can also play a leading role in bringing brand collaborations and real-world assets to Canton. Jubilee’s open-source code could be valuable for these use cases as well.

Erlannn7commented28-07-2026 · 2mo agoGitHub ↗

Updated the proposal in response to feedback from Canton ecosystem stakeholders and reviewers:

The open-source non-fungible asset infrastructure and the Jubilee marketplace are now separated into distinct workstreams with their own deliverables and acceptance criteria.

The proposal now reflects Jubilee's progress since the original submission from testnet validation to a controlled private MainNet review deployment.

The fee model has been updated to match the current flat 3 CC sale / 3 CC mint launch plan, and third-party-dependent adoption figures are now reported operational targets rather than grant-disbursement conditions.

The open-source sequence has been clarified: the repository progresses from public architecture in MS1, to core asset modules in MS2, marketplace and settlement modules in MS3, and the complete stable public-good release in MS4.

The audit scope covers the full DAML contract suite and atomic payment distribution logic. Third-party bridge code is outside the audit scope. One audit firm is Canton Network's official audit solution partner and the other is an independent firm with DAML expertise. Both complete reports will be delivered to the Committee; public reports or summaries remain subject to auditor disclosure terms.

The collection launch and audit schedule are now explicitly separated. The reference collection may launch before audit completion because launch timing is not dependent on grant disbursement. If that occurs, exposure remains constrained by the collection's fixed 1,000-NFT supply and allowlist-gated access. Audit completion and remediation of critical and high-severity findings gate removal of the allowlist for broad public onboarding and publication of the final stable public-good release, with the full DAML contract suite and atomic payment distribution logic covered by the two independent audits.

The standards section now reflects the implemented CIP-0056 V1 relationships accurately: NFToken and NFTokenV2 implement Holding, JubileeTransferFactory implements TransferFactory, and Jubilee's settlement contracts consume Splice's official AllocationFactory and Allocation implementations rather than reimplementing the allocation surfaces. The gradual CIP-0112 V2 transition remains documented.

The self-custody wallet reference implementation remains a public-good deliverable but is explicitly separated from the audited DAML scope.

A documented, runnable non-collectible worked example has been added as an MS4 deliverable and acceptance condition, demonstrating the reusable modules outside an art or PFP use case.

A disclosure model paragraph now describes what is visible to whom across ownership contracts, marketplace listings, and published collection statistics.

The embedded swap deliverable now commits to OneSwap and uses Jubilee's built-in self-custody wallet; the separate swap-wallet connection deliverable has been removed.

The total working request and overall four-milestone structure remain unchanged, while individual deliverables and technical descriptions have been refined. Collectibles remain the first production reference use case, while the grant's durable output is reusable infrastructure intended to support broader non-fungible and financial applications on Canton.

I appreciate how the team incorporated the community and reviewer feedback into the proposal. Separating the marketplace from the open-source NFT infrastructure makes the scope much clearer, and the updated roadmap gives more confidence in the project's direction. As a member of the Canton community, I'm genuinely looking forward to seeing Jubilee go live and bringing privacy-focused NFTs to the ecosystem. Wishing the team the best during the review process! 🙌

hythlodacontributorcommented09-09-2026 · 1mo agoGitHub ↗

Committee requested a workstream-level budget and measurable adoption gates. When that is done this can move back to voting.

Jubilee-Marketcommented09-09-2026 · 1mo agoGitHub ↗

Committee requested a workstream-level budget and measurable adoption gates. When that is done this can move back to voting.

Updated. The proposal now includes an explicit workstream-level budget and measurable binding adoption gates for both workstreams. We also clarified the distinction between minimum acceptance thresholds and higher operational targets.

Thanks, happy for this to move back to voting.

Jubilee-Marketcommented28-09-2026 · 22d agoGitHub ↗

Updated for the Dev Fund 2.0 transition.

Jubilee is now explicitly mapped to RFP 12 - RWA Standards / Daml and Institutional RWA Workflow Standards, with the proposal moved under the corresponding RFP category.

We also added explicit Dev Fund 2.0 framing covering the ecosystem need, beneficiaries, and adoption path.

The underlying 600,000 CC funding request, four-milestone structure, workstream allocations, and binding adoption gates remain unchanged.

hythlodacontributorcommented30-09-2026 · 20d agoGitHub ↗

A good next step might be to make a CIP for the reference implementation for the infra for these NFTs. Under RfP guidelines the CIPs that are approved can then get dev funds

shaul-dacommented30-09-2026 · 20d agoGitHub ↗

It sounds like there's already a CIP proposal from Fairmint so it makes more sense to me to create a reference implementation after a CIP gets approved

Jubilee-Marketcommented30-09-2026 · 20d agoGitHub ↗

It sounds like there's already a CIP proposal from Fairmint so it makes more sense to me to create a reference implementation after a CIP gets approved

Thanks, Shaul. Just to clarify, our understanding from today’s meeting, including Amanda’s suggestion, was that a good next step for Jubilee would be to pursue a CIP around an NFT token standard, and we were happy to follow that path.

Your comment seems to suggest a different direction: waiting for Fairmint’s proposed CIP to be approved and then potentially contributing a reference implementation.

Fairmint does not currently have a submitted or approved NFT CIP. Jubilee began designing and implementing its NFT architecture roughly five months ago, independently of the current Fairmint proposal, and has since taken that work to a functioning MainNet implementation.

Could you clarify which path the Committee would actually recommend for Jubilee? If the expectation is already to converge specifically on Fairmint’s future CIP, it would be helpful for us to know that before investing time into a parallel CIP process. Otherwise, we would like our production experience to have a fair opportunity to inform the NFT standardization process through the normal CIP governance process.

We would also appreciate clarity on whether our current Dev Fund proposal should continue to be evaluated on its existing scope while that standards process develops.

bbznyccommented07-10-2026 · 13d agoGitHub ↗

Consideration given for V2 Profile (CIP-0112)

https://github.com/Fairmint/dev-docs/blob/main/proposals/canton-cips/2026-10-canton-nft-profile.md

s0urleddcommented08-10-2026 · 13d agoGitHub ↗

Consideration given for V2 Profile (CIP-0112)

https://github.com/Fairmint/dev-docs/blob/main/proposals/canton-cips/2026-10-canton-nft-profile.md

not public btw

waynecollier-dacontributorcommented08-10-2026 · 12d agoGitHub ↗

Consideration given for V2 Profile (CIP-0112) https://github.com/Fairmint/dev-docs/blob/main/proposals/canton-cips/2026-10-canton-nft-profile.md

not public btw

The public text is here:

https://github.com/canton-foundation/cips/pull/276

This ^^ was posted in the cip-discuss thread at

https://lists.sync.global/g/cip-discuss/topic/cip_tbd_canton_nft_profile/121620194

hythlodacontributorcommented14-10-2026 · 6d agoGitHub ↗

For now we are moving this to decline. It seems like a better FA and we need this proposal to come after the CIP is complete.

Proposal file rfps/financial-markets-standards-verification/jubilee.md, 74 KB

Jubilee — Open-Source Non-Fungible Asset Infrastructure & Reference Marketplace for Canton


Author	Jubilee Team
Status	In Review
Created	2026-04-29
Updated	2026-09-28
Website	https://jubilee.markets
X (Twitter)	https://x.com/JubileeMarkets
Champion	Jack Charlesworth — @jackcharlesworth
Proposal Type	RFP-aligned
Primary RFP	RFP 12 — RWA Standards
RFP Area	Daml and Institutional RWA Workflow Standards
Secondary Alignment	RFP 13 — Payments and DeFi; RFP 14 — Wallet and dApp Integration Tooling

Abstract

Jubilee is building open-source non-fungible asset and atomic settlement infrastructure for Canton, with the full DAML contract suite and atomic payment distribution logic independently audited, together with a production marketplace that serves as its first end-to-end reference implementation. With its on-ledger contract logic built entirely in DAML, the system combines party-based ownership, contract-enforced authorization, fully backed on-ledger offers, and atomic multi-party settlement.

The proposal distinguishes two connected workstreams:

Workstream A — Open-source non-fungible asset infrastructure: an Apache 2.0-licensed, NFT-focused implementation layer built on the Canton Network Token Standard; reusable collection creation, minting, ownership, transfer, listing, offer, counter-offer, escrow, and atomic payment distribution primitives; developer documentation; two independent security audits covering the full DAML contract suite and atomic payment distribution logic; and a documented path for gradual adoption of CIP-0112 V2 features from the current CIP-0056 V1-compatible implementation. The self-custody wallet reference implementation is released as a separate public-good component and is not included in the DAML audit scope.
Workstream B — Jubilee reference marketplace: the production application used to validate those primitives end to end through creator, user, marketplace, wallet, bridge, and operator flows.

Art, PFPs, and digital collectibles are the first reference use case because they are familiar to crypto-native users and provide the lowest-friction path to real adoption and repeated production validation. They are the starting point, not the limit of the infrastructure. The same reusable building blocks are intended to reduce the engineering and audit burden for Canton teams developing other unique assets and rights, including certificates, licenses, memberships, tokenized documents, property-related rights, private-market positions, and other financial or real-world instruments. No specific regulated asset product or native fractionalization layer is included in the current grant scope.

Since the original submission, Jubilee has progressed from testnet validation to a private MainNet review deployment. Collection creation, minting, listing, purchasing, offers, counter-offers, cancellations, direct transfers, and atomic settlement are now operational on MainNet under controlled internal testing.

This proposal seeks funding to harden the existing MainNet deployment, complete two independent security audits covering the full DAML contract suite and atomic payment distribution logic, remediate critical and high-severity findings, deliver USDCx-denominated settlement and additional onboarding integrations, and release the reusable infrastructure as Canton ecosystem public goods. The browser-encrypted self-custody wallet reference implementation will be released separately and is not represented as part of the audited DAML scope. Third-party bridge code is outside the audit scope.

Dev Fund 2.0 Alignment

RFP Mapping

This proposal primarily responds to RFP 12 — RWA Standards, specifically the Daml and Institutional RWA Workflow Standards area.

Workstream A delivers reusable Daml models, tooling, tests, documentation, and reference implementations for uniquely identifiable assets and their application workflows on Canton. The funded public-good scope includes asset creation and issuance, ownership and transfer, cancellation and lifecycle flows, backed offer escrow, atomic settlement, interoperability with the Canton Network Token Standard, and production-tested reference implementations intended to be reusable across multiple Canton applications rather than limited to Jubilee's proprietary application.

The proposal also has secondary alignment with RFP 13 — Payments and DeFi through its reusable atomic settlement, backed-offer escrow, Canton Coin payment distribution, and USDCx-denominated settlement work, and with RFP 14 — Wallet and dApp Integration Tooling through the separately released browser-encrypted self-custody wallet reference implementation and prepare/sign/submit integration patterns.

Ecosystem Need and Beneficiaries

Canton provides generic token and settlement interfaces, but application teams still need reusable implementation-level components for uniquely identifiable assets and the workflows around them.

Without shared components, teams building non-fungible or individually identifiable assets would need to independently design, implement, test, and secure collection or asset creation, issuance, ownership, transfer, listings, backed offers, escrow, atomic payment distribution, and related application flows.

The primary beneficiaries are:

Canton application developers, who gain reusable and documented Daml components instead of rebuilding the same asset and marketplace primitives from scratch;
asset issuers, creators, and ecosystem projects, who gain a production reference implementation for issuing, distributing, and transacting in uniquely identifiable digital assets;
wallets, venues, and integrators, who gain documented reference flows and interoperability examples built on the Canton Network Token Standard; and
the broader Canton ecosystem, which gains reusable infrastructure for an additional asset category that can extend beyond collectibles to certificates, licenses, memberships, tokenized documents, property-related rights, private-market positions, and other individually identifiable assets.

Adoption

Adoption is measured separately for the reusable public-good infrastructure and the production reference implementation.

Workstream A uses independent technical adoption gates. From MS2 onward, external Canton developers or technical teams must evaluate the published implementation, execute the published settlement or escrow flows without Jubilee's private application code, and ultimately reproduce a reusable module flow or runnable example using only the public repository and documentation.

Workstream B uses independent MainNet user and ecosystem adoption gates. The existing binding thresholds progress from at least 50 independent MainNet users and 25 completed purchase or sale settlements in MS2, to 100 cumulative independent users, 75 cumulative settlements, two external projects in the onboarding pipeline, and one external MainNet launch in MS3, and finally 150 cumulative independent users plus 50 USDCx-denominated purchase or sale settlements involving at least 20 distinct independent user Party IDs in MS4.

Collectibles are used as the first production reference use case because they provide a familiar, low-friction environment for repeatedly validating issuance, ownership, transfer, escrow, trading, and settlement under real MainNet conditions. They are the adoption vehicle for the first reference implementation, not the limit of the reusable infrastructure.

Delivered Work — Current Platform State (MainNet Private Review)

Jubilee is currently deployed on Canton MainNet in a controlled private-review environment. The core platform flows are operational end to end. This proposal funds production hardening, public-launch readiness, supplementary features, two independent security audits, and the release of reusable open-source infrastructure for the Canton ecosystem.

Core marketplace & DAML architecture (MainNet private review)

Full DAML contract suite (6+ templates): collection management, token ownership, marketplace listings, offer/counter-offer, transfer requests
End-to-end marketplace flows: mint, list, buy, sell, offer, counter-offer, transfer
Party-based ownership model, enforced via DAML controller rules
Current review-build fees of 0.1 CC per completed sale and 0.1 CC per minted NFT, with creator royalty and seller distribution settled atomically

Marketplace discovery & browsing

Top Collections / Ledger of Rank — sortable list with floor, best offer, sales, volume, listed, owners, and trend graph; 1D/7D/30D/ALL time filters
Featured Collections and Trending Collections carousels
Explore Collections page — sortable columns (Floor, 1D/7D Change, Volume, Owners, Supply), favoriting
Latest Activity feed (mint, list, sale, transfer, offer events)
Activity page — fully filterable event history (All/Sale/List/Offer/Mint/Transfer), LIVE indicator
Collection detail and NFT detail pages

Mint experience

Jubilee Mint page — Opening Soon (with countdown), Minting Now (progress bar, stage display), Allowlist/Public stage flows
Minting Right Now live cards — minted/supply, price, stage info
Editor's Note curation, Submit a Collection flow

Collection creation & management

4-step creator wizard: Details → Media & Metadata → Mint Stages → Review
Multi-file media upload (GIF/JPG/MP3/MP4/PNG/SVG)
CSV metadata upload: tokenID, name, file_name (required); description, external_url (optional); attributes[trait_name] (traits)
Mint settings: total supply, mint price, start/end time, royalty %, per-wallet mint limit
Staged mint + whitelist management
Editorial Office (platform admin panel) — launch permissions, users, collection management, platform revenue tracking

Creator tools & analytics

Creator Dashboard — total volume, royalties earned, NFTs minted, collection count
Royalty earnings graph (7D/30D/90D/1Y/ALL)
Avg per sale, all-time royalty, royalty rate metrics
CSV export
Per-collection management — mint progress, volume, sales, holders, floor, royalties

User portfolio & operations

Portfolio page — Owned / Listed / Offers / Activity tabs
Multi-select mode — multiple NFT selection for bulk operations
Bulk list modal — single price application or per-NFT override, subtotal and avg calculation
Bulk send flow

Self-custody wallet

Wallet Overview — balance, wallet type, Canton Party ID
Deposit address for CC reception
Send Canton Coin — signing with private key
Send NFTs — via transfer button
Bridge (USDCx) shortcut

Trading primitives & discovery enhancements

On-ledger CC offer escrow: When a buyer submits an offer, their CC is locked on-ledger into an escrow contract before the seller ever sees the offer. This eliminates unfunded offers and materially reduces the unbacked-offer spam pattern common in EVM-based marketplaces, where offers can be made without committed funds and then withdrawn arbitrarily. Every marketplace offer that reaches a seller is fully backed at the moment of receipt.
OpenRarity-based rarity scoring: Industry-standard rarity computation engine implemented for all collections, providing deterministic and reproducible rarity rankings across traits.
Indexed prefix-search optimization: Search infrastructure tuned for low-latency collection and NFT discovery via indexed prefix-matching, supporting marketplace-grade browse experience.

Notifications

Dropdown notification center and dedicated Notifications page
Event types: NFT minted, new offer received, offer accepted, counter-offer received, counter-offer accepted, sale completed, transfer received
Unread counter, mark all read, all/unread filtering

USDCx bridge (Ethereum ↔ Canton)

Bidirectional bridge via Circle's xReserve infrastructure, operational on MainNet under private review — USDC on Ethereum is wrapped to USDCx on Canton

Production infrastructure & operations (live)

Beyond the application layer, Jubilee has shipped production-grade operational infrastructure indicating execution capability beyond DAML contract development:

Live production landing site at jubilee.markets deployed via Cloudflare Pages with custom domain and active SSL
Email infrastructure: Resend Pro with DKIM-verified sending domain, Cloudflare Queues, Batch API, and retry/backoff handling
Waitlist system: Cloudflare D1 + KV with rate limiting, throughput-tested to handle 10,000+ signup requests per minute
Operational maturity: monitoring, deployment automation, and zero-downtime release practices in place

This demonstrates that the team can not only ship Canton smart contracts but also operate the production-side infrastructure required to support a consumer-grade application.

Specification

Note on terminology: Within this document, references to "USDC" in the context of assets held or transacted on Canton refer specifically to USDCx — USDC wrapped onto Canton via Circle's xReserve infrastructure. References to "USDC" in the context of external EVM chains refer to native USDC.

1. Objective

Canton's ecosystem currently lacks an audited, reusable, NFT-focused implementation layer atop the Canton Network Token Standard and a publicly launched production marketplace that validates those components end to end. Jubilee currently implements the CIP-0056 V1 interfaces. CIP-0056 provides generic token interfaces, but it intentionally does not define application-level behavior for collections, unique supply, staged minting, allowlists, creator royalties, listings, backed offers, counter-offers, or marketplace payment distribution.

Jubilee addresses that gap through two connected but separately evaluated workstreams:

Workstream A — Open-source non-fungible asset infrastructure

An Apache 2.0-licensed NFT-focused reference implementation built on CIP-0056 V1, with the full DAML contract suite and atomic payment distribution logic covered by two independent audits, with a documented path for gradual adoption of CIP-0112 V2 features
Reusable collection creation, minting, ownership, transfer, listing, offer, counter-offer, escrow, and atomic payment distribution primitives
A browser-encrypted self-custody wallet reference implementation
Developer documentation, integration examples, and security-audit outputs

Workstream B — Jubilee reference marketplace

A hardened MainNet marketplace validating the primitives in a complete production application
A launchpad enabling Canton ecosystem projects to create and distribute digital asset collections
Creator, user, wallet, marketplace, bridge, embedded OneSwap, and operator surfaces
A first Jubilee reference collection and external collection onboarding

Success looks like:

The Workstream A public goods are documented and released for reuse by Canton developers, with the full DAML contract suite and atomic payment distribution logic covered by two independent audits
The Workstream B marketplace is publicly operational on Canton MainNet and demonstrates the infrastructure end to end
Multi-chain onboarding and the embedded OneSwap integration reduce friction for users entering the marketplace
External Canton teams can evaluate and reuse the open-source modules without rebuilding the same infrastructure from scratch
Collectibles provide the first production validation vertical while the infrastructure remains applicable to broader unique-asset and financial use cases

2. Implementation Mechanics

Jubilee's on-ledger contract logic is built entirely in DAML and follows Canton's native execution model:

Users interact through a web interface
Backend (Node.js) constructs DAML commands and submits via Canton Ledger API
DAML engine enforces all authorization, preconditions, and contract rules
State transitions are atomic and follow a strict create-and-archive model
Ownership is party-based, stored directly in contract state, and enforced via DAML controller rules
Self-custody wallet runs entirely in the browser using an Ed25519 keypair encrypted at rest, with a prepare/sign/submit flow over the validator's external-party surface

The browser-encrypted wallet is one reference client and is not a dependency of the asset layer. Jubilee's CIP-0056-compatible asset and transfer interfaces can be integrated by other compatible wallets, custodians, and settlement venues, including through CIP-0103 dApp API flows. This proposal does not claim an existing institutional custody integration.

Marketplace transactions combine asset transfer, payment settlement, and royalty distribution within a single atomic operation — eliminating the partial-fill and failed-royalty problems common in EVM-based marketplaces. Buyer offers are similarly placed into on-ledger escrow at submission time, ensuring every offer reaching a seller is fully backed by locked CC.

The current MainNet review build uses placeholder fees of 0.1 CC per completed sale and 0.1 CC per minted NFT. The planned public-launch model uses a flat 3 CC platform fee per completed sale and a flat 3 CC platform fee per minted NFT, with no percentage-based platform commission. Creator royalties are optional percentages configured per collection and apply only to secondary sales. The public-launch minimum listing price will be set so that seller proceeds cannot become negative after the flat platform fee and any applicable royalty.

3. Architectural Alignment

Jubilee is fully aligned with Canton's architecture and is positioned as an opinionated, NFT-focused reference implementation of CIP-56 — not a fork, not a competing standard.

Native execution alignment:

DAML-native execution — all contract logic runs natively in DAML, no EVM adaptation
Party-based identity — ownership tied to Canton parties, not addresses
Sub-transaction privacy — ownership visibility restricted to relevant parties only
Atomic state transitions — every trade is all-or-nothing, no intermediate states
Create-and-archive model — immutable contract lifecycle, no mutable state

Disclosure model: Ownership contracts and private settlement legs are visible only to the relevant ledger stakeholders. Jubilee, as marketplace operator, can see the marketplace contracts required to provide the service. Public listings intentionally disclose selected asset metadata and asking prices through the application. Collection statistics are application-published aggregates, not globally replicated ownership records.

Canton Network Token Standard alignment: CIP-0056 V1 and CIP-0112 V2

Jubilee currently implements the CIP-0056 V1 interfaces. CIP-0056 defines the general DAML interfaces required for Canton tokens to interoperate with wallets, exchanges, custody applications, and settlement venues without bespoke integration code: Holding, TransferInstruction, TransferFactory, Allocation, AllocationRequest, AllocationInstruction, AllocationFactory, and Metadata/InstrumentId types. It is intentionally generic and does not define NFT-specific behavior such as collections, mint stages, allowlists, supply caps, creator royalties, or escrowed marketplace offers.

Jubilee's implementation layer fills that application-level gap with NFT-specific primitives built on the V1 interfaces:

Jubilee component	CIP-0056 V1 relationship
NFToken / NFTokenV2 (amount = 1.0)	Implements Holding
JubileeTransferFactory	Implements TransferFactory
Atomic settlement flows (buy, offer accept, counter accept)	Exercise Splice's official AllocationFactory / Allocation implementations for the Canton Coin legs
JubileeBackedOfferV4 (backed-offer escrow)	Locks the buyer's committed CC in a standard Allocation

Official Splice v0.5.18 CIP-0056 DARs are currently vendored as data-dependencies, with interface instance declarations provided against them for the Holding and TransferFactory surfaces. Rather than reimplementing the allocation surfaces, Jubilee's settlement contracts consume Splice's canonical CIP-0056 implementations directly. This means the existing Jubilee implementation interoperates with CIP-0056-compatible infrastructure while the collection and marketplace layer remains opinionated scaffolding above the standard, not a replacement for it.

CIP-0112 is the approved V2 evolution of the Canton Network Token Standard. It is designed as a backwards-compatible progression of CIP-0056 and adds capabilities relevant to privacy-preserving settlement, traditional account structures, committed allocations, standardized batching, and transaction parsing. Workstream A therefore includes a staged V1-to-V2 compatibility track focused on the applicable Holding and Transfer surfaces: an interface and phased V2-adoption map in MS1, compatibility scaffolding and tests in MS2, extension of those tests across the marketplace settlement examples in MS3, and a published V2 adoption guide with tested examples in MS4. Jubilee will preserve V1 interoperability during the transition and add applicable Holding and Transfer V2 interface support where the target Splice packages are available and production-suitable during the grant period. A full V2 Allocation implementation is not committed within this grant.

The analogy is ERC-721: the standard defines the interoperable interface, a reusable library provides application-level building blocks, and a marketplace validates them in a complete product. Jubilee is currently compatible with CIP-0056 V1. CIP-0112 V2 is designed for a high level of backward compatibility with CIP-0056 V1 and supports a gradual cross-version transition. Jubilee's open-source library is the opinionated non-fungible asset implementation layer, while jubilee.markets is the production application built above it.

Other CIP alignment:

CIP-0082 — contributes ecosystem utility through asset infrastructure and reference implementations, both explicitly named eligible categories
CIP-0100 — structured with milestone-based delivery, measurable outputs, and acceptance criteria
CIP-0104 — qualifying marketplace operations where the Jubilee marketplace party is a signatory produce confirmer-based traffic attribution, while generic Canton Coin sends, bridge operations, and one-time account setup remain outside Jubilee attribution

4. Backward Compatibility

The Jubilee asset protocol is additive to the Canton ecosystem. It does not require changes to Canton core, Splice, or DAML. It currently implements CIP-0056 V1 rather than modifying or forking it. CIP-0112 V2 is designed for a high level of backward compatibility with CIP-0056 V1 and supports a gradual cross-version transition. The proposed V2 work is therefore framed as gradual feature adoption rather than a mandatory replacement of the existing V1 implementation.

No backward compatibility impact is introduced by the current implementation or the proposed staged V2 compatibility work.

Milestones and Deliverables

The marketplace and the open-source infrastructure remain technically connected, but each milestone identifies which deliverables belong to Workstream A and which belong to Workstream B.

Milestone 1: MainNet Hardening, Audit Readiness & Public Architecture

Estimated Delivery: 2 weeks
Focus: Hardening Jubilee's existing private MainNet deployment, preparing the security-critical code for independent review, and opening the public architecture layer. The MS1 allocation, available upon acceptance of the MS1 deliverables, is intended to finance the two independent audits commencing at the start of MS2.

Workstream A — Open-source infrastructure

Finalize the public module inventory and Jubilee-to-CIP-0056 V1 implementation-relationship map
Produce a CIP-0056 V1 to CIP-0112 V2 compatibility and phased V2-adoption map for the applicable Holding and Transfer surfaces, while documenting that a full V2 Allocation implementation is outside the current grant scope
Open a public Apache 2.0 repository containing the architecture overview, module boundaries, interface mappings, release roadmap, threat model, security invariants, and initial integration-surface documentation
Finalize the audit package for the full DAML contract suite and atomic payment distribution logic
Finalize commercial terms and provisional schedules with two independent security audit firms, one being Canton Network's official audit solution partner and the other an independent firm with DAML expertise, ready for commissioning upon MS1 acceptance
Expand private test coverage and prepare the audit code freeze

Workstream B — Reference marketplace

Production hardening of all DAML contract templates and application services already deployed to Canton MainNet
Live MainNet validation of mint, list, buy, sell, offer, counter-offer, cancellation, and direct-transfer flows
MainNet validation of the planned launch fee configuration: 3 CC per completed sale and 3 CC per minted NFT, with no percentage-based platform commission
Production monitoring, logging, incident-response, rate-limiting, and edge-case hardening
Load and stability testing under controlled MainNet conditions

Milestone 2: Independent Audits, Core Primitive Preview & Product Readiness

Estimated Delivery: 3–5 weeks, subject to the auditor schedules finalized in MS1
Focus: Commissioning and completing two independent audits of the full DAML contract suite and atomic payment distribution logic; remediating critical and high-severity findings; publishing the first implementation preview; and validating the complete MainNet product surface. The reference collection launch is not dependent on the grant-disbursement schedule and may occur before the audits are completed. If that occurs, exposure will remain controlled through the collection's fixed 1,000-NFT supply and allowlist-gated access at launch. The audits will be commissioned immediately after MS1 acceptance and disbursement; if the grant schedule advances quickly enough, they may still complete before launch. In all cases, audit completion and remediation of critical and high-severity findings are required before allowlist restrictions are removed and the platform is opened to broad public onboarding, and before the final stable public-good release is published.

Workstream A — Open-source infrastructure

Completion of two independent security audits covering the full DAML contract suite and atomic payment distribution logic
Remediation and documentation of all critical and high-severity findings before the affected modules are designated audit-complete
Following completion of the audits and remediation of all critical and high-severity findings affecting those modules, publication of the first open-source implementation preview covering the core non-fungible asset modules: collection creation, minting, ownership, holdings, and transfer
Publication of the corresponding core tests and preliminary developer documentation, clearly labelled as a preview rather than the final stable release
CIP-0112 compatibility scaffolding and tests for the applicable core Holding and Transfer surfaces, while preserving CIP-0056 V1 interoperability
Live MainNet validation of platform fee, creator royalty, seller proceeds, and NFT ownership transfer executing in one atomic operation
Committee delivery of both complete audit reports; public release of reports or summaries will follow the applicable auditor disclosure terms

Workstream B — Reference marketplace

Production hardening and MainNet validation of the existing collection creator panel and creator dashboard, including creator configuration, staged mint, allowlist management, analytics, per-collection management, and export flows
Production hardening and MainNet validation of the existing self-custody wallet and bidirectional Ethereum ↔ Canton USDCx bridge integration, including recovery, Party ID management, Send CC, Send NFTs, deposit, and bridge flows
MainNet edge-case and stability validation of existing bulk-list and bulk-send features
Complete MainNet lifecycle validation for Jubilee's 1,000-piece reference collection, including collection configuration, minting, secondary settlement, and monitoring
Operational evidence, stability findings, and resulting hardening iterations reported based on MainNet validation and any live reference-collection activity available during the milestone

Milestone 3: Settlement Module Preview, Ecosystem Onboarding & Embedded OneSwap Integration

Estimated Delivery: 4 weeks
Focus: Publishing the reusable marketplace and settlement implementation surfaces, validating their V2 compatibility path, enabling external Canton projects to use the Jubilee launchpad, and giving users an embedded OneSwap route through Jubilee's built-in self-custody wallet without leaving the product.

Workstream A — Open-source infrastructure

Publish the preview implementation of the listing, offer, counter-offer, cancellation, allocation-backed escrow, and atomic payment-distribution modules
Publish integration examples and a draft developer guide covering collection creation, minting, transfer, listing, offer, escrow, and atomic settlement
Extend the CIP-0112 compatibility scaffolding and tests across the applicable Holding and Transfer surfaces used by the marketplace settlement examples, while maintaining the existing CIP-0056 V1 path; a full V2 Allocation implementation is not committed within this grant
Document the technical onboarding path for external collections and applications evaluating the modules
Collect structured integration feedback for incorporation into the final stable public-good release

Workstream B — Reference marketplace

Operational launchpad infrastructure with a documented submission process and technical onboarding guide, accepting external collection submissions
OneSwap integration embedded within Jubilee and executable through Jubilee's built-in self-custody wallet without leaving the interface
External-project onboarding, launch support, and marketplace reporting

Milestone 4: USDCx Settlement, Multi-Chain Onboarding & Full Stable Public-Good Release

Estimated Delivery: 4 weeks
Focus: Delivering USDCx-denominated marketplace settlement, expanding asset onboarding, and publishing the complete stable public-good release following the staged MS1-MS3 disclosures, with the full DAML contract suite and atomic payment distribution logic covered by the two independent audits.

Workstream A — Open-source infrastructure

Complete NFT-focused reference library covering collection grouping, mint stages, allowlists, supply caps, per-wallet limits, royalty-aware settlement, and fully backed offers
Complete marketplace primitives for listings, offers, counter-offers, cancellations, allocation-backed escrow, and atomic settlement
Atomic payment distribution templates
Browser-encrypted Ed25519 self-custody wallet reference implementation using the prepare/sign/submit flow, published as a separate public-good component outside the DAML audit scope
USDCx bridge reference integration
Final developer documentation, integration examples, test suite, remediation notes, and public audit reports or summaries consistent with the applicable auditor disclosure terms; both complete reports will have been delivered to the Committee in MS2
CIP-0056 V1 to CIP-0112 V2 adoption guide and tested cross-version examples
A documented, runnable non-collectible worked example, such as a unique license entitlement or private membership certificate, demonstrating how the same collection creation, minting, ownership, transfer, permissioning, and settlement modules can be used outside art and PFP collections
V2 interface support for applicable Holding and Transfer modules where the target Splice packages are available and production-suitable during the grant period, while preserving the documented V1 interoperability path; a full V2 Allocation implementation is outside the current grant scope
Complete stable release of all public-good modules published in the public GitHub repository under Apache License 2.0, with the full DAML contract suite and atomic payment distribution logic covered by the two independent audits

Workstream B — Reference marketplace

NFT listing, offer, and purchase flows denominated in USDCx on Canton
Atomic USDCx settlement distributing seller proceeds, platform fee, and creator royalty where applicable
At least one additional external bridge route or complementary onboarding path demonstrably operational
Production reporting for USDCx-denominated marketplace activity

Acceptance Criteria

The Tech & Ops Committee will evaluate each milestone against two categories:

completion of the technical deliverables defined for that milestone; and
satisfaction of the applicable minimum measurable adoption gates defined below.

Technical acceptance continues to consider:

delivery of the specified functionality;
demonstrated operational readiness;
audit completion and remediation where applicable;
documentation and knowledge transfer;
staged open-source publication and integration usability; and
alignment with the stated value metrics.

If a minimum adoption gate has not been met at the planned milestone review date, the adoption component of that milestone will remain pending until the required evidence is provided. Technical deliverables may still be reviewed separately by the Committee. Jubilee may submit updated adoption evidence during an additional remediation or extension period agreed with the Committee.

Workstream Evaluation Framing

Workstream A — Open-source non-fungible asset infrastructure is the durable public-good layer of the proposal. It produces reusable DAML asset, transfer, escrow, settlement, documentation, testing, compatibility, and reference components that can be evaluated and used independently of Jubilee's private application code.

Because Workstream A is developer-facing infrastructure rather than a standalone consumer application, its adoption gates measure independent technical evaluation, executability, and reproducibility. Milestone acceptance is not made dependent on an external team's separate commercial decision to integrate the modules into its own production product.

Workstream B — Jubilee reference marketplace as production reference implementation and ecosystem validation provides the MainNet environment in which Workstream A primitives are exercised under real production conditions.

Workstream B therefore validates the public-good infrastructure through independent users, external creators and collections, real settlement activity, onboarding flows, and interoperability integrations. Its purpose within the grant is not limited to Jubilee-specific product development: it provides production evidence, ecosystem feedback, and real-world validation for the reusable infrastructure delivered under Workstream A.

Adoption-Gate Definitions

The binding adoption gates below are designed to demonstrate genuine external use without creating incentives for artificial transaction volume.

For purposes of these gates:

Independent / external means a user, developer, collection, or project that is not owned, controlled, or operated by the Jubilee core team and is not participating solely for the purpose of satisfying a grant threshold.
Unique user means a distinct independently controlled Canton Party ID, to the extent reasonably identifiable from Jubilee's application and onboarding records.
Eligible user-initiated marketplace action means a MainNet mint, listing, offer submission or acceptance, purchase, or direct asset transfer executed by the user. Account creation, login, browsing, and other passive activity do not count.
Eligible marketplace activity excludes Jubilee-controlled accounts, operator or reviewer test accounts, self-trading, activity between accounts reasonably known to share the same beneficial controller, repetitive circular activity, and transactions generated primarily to satisfy a grant metric.
Onboarding pipeline means an external project that has formally entered Jubilee's collection/project onboarding process and has a documented onboarding record containing, at minimum, the project identity, submission date, intended collection or use case, and current onboarding status. Informal conversations or expressions of interest alone do not qualify.
Each completed marketplace settlement is counted once, regardless of the number of parties involved.
Raw transaction volume is not used by itself as a binding adoption gate because a small number of high-value or circular transactions can disproportionately affect volume without demonstrating broad adoption.
Jubilee will report the underlying counts and methodology used to determine each adoption gate to the Committee.

The higher transaction and ecosystem targets already included in previous versions of this proposal are retained as operational targets. The thresholds below are the minimum binding adoption gates used for milestone acceptance.

This distinction preserves Jubilee's existing growth targets while avoiding a grant-disbursement incentive to manufacture activity solely to satisfy large transaction-count or volume thresholds.

MS1 has no external adoption gate. MS1 precedes the implementation-preview releases and provides the funding required to commission the two independent audits at the start of MS2. External adoption measurement therefore begins in MS2, when the relevant public and production surfaces become available for meaningful external evaluation.

MS1 — MainNet Hardening, Audit Readiness & Public Architecture

Workstream A acceptance conditions

Public module inventory and Jubilee-to-CIP-0056 V1 implementation-relationship map completed
CIP-0056 V1 to CIP-0112 V2 compatibility and phased V2-adoption map completed for the applicable Holding and Transfer surfaces, with the full V2 Allocation implementation explicitly outside the current grant scope
Public Apache 2.0 repository opened with architecture, module boundaries, interface mappings, release roadmap, threat model, security invariants, and initial integration-surface documentation
Audit package documented for the full DAML contract suite and atomic payment distribution logic
Commercial terms and provisional schedules finalized with two independent audit firms, one being Canton Network's official audit solution partner and the other an independent firm with DAML expertise
Quote, SOW, engagement documentation, or equivalent commercial evidence available for Committee review showing that both audits are ready to be commissioned following MS1 acceptance
Audit code freeze and expanded private test suite prepared

Workstream B acceptance conditions

Existing production reference implementation and core services production-hardened and validated in the controlled Canton MainNet environment
Mint, list, buy, sell, offer, counter-offer, cancellation, and direct-transfer flows revalidated under production conditions and demonstrable to a Committee member or representative
Production monitoring, logging, rate-limiting, and incident-response infrastructure active
End-to-end production behavior of the applicable Workstream A primitives observable through the MainNet reference implementation

MS2 — Independent Audits, Core Primitive Preview & Product Readiness

Workstream A acceptance conditions

Two independent security audit reports covering the full DAML contract suite and atomic payment distribution logic completed and delivered in full to the Committee
All critical and high-severity findings remediated and documented before the affected code is designated audit-complete, before allowlist restrictions are removed for broad public onboarding, and before the final stable public-good release is published
Following completion of the audits and remediation of all critical and high-severity findings affecting the previewed modules, the core collection, minting, ownership, holding, and transfer implementation preview published with tests and preliminary documentation
Applicable CIP-0112 compatibility scaffolding and tests published for the core Holding and Transfer surfaces while preserving the CIP-0056 V1 path
Atomic distribution of platform fee, creator royalty, seller proceeds, and NFT ownership demonstrated on MainNet in a single operation

Workstream A minimum adoption gate

At least one independent Canton developer or external technical team must meaningfully evaluate the published architecture and core implementation preview.

The gate can be satisfied through at least one of the following forms of verifiable external technical evidence:

structured technical feedback through a public GitHub Discussion or equivalent public technical feedback record;
a technical contribution or pull request to the public repository; or
verifiable evidence that a published core example was successfully executed.

The purpose of this gate is to demonstrate that a technical user outside the Jubilee core team can independently inspect and meaningfully evaluate the public implementation.

Workstream B acceptance conditions

Existing creator panel, self-custody wallet, USDCx bridge, bulk-operation surfaces, and creator dashboard production-hardened and validated on MainNet, with resulting operational evidence available to the Committee
Jubilee's 1,000-piece reference collection configured and its complete collection setup, minting, secondary-settlement, and monitoring lifecycle validated end to end on MainNet
If the reference collection launches before both audits and critical/high remediation are complete, its launch supply remains capped at 1,000 NFTs and access remains allowlist-gated until the audit gate for broad public onboarding is satisfied
Primary mint activity reported separately from secondary marketplace activity where live activity exists
Available production-validation metrics reported to the Committee, including minted and listed supply, transaction count, completed sales, unique holders, royalties, seller proceeds, platform fees, and sales volume

Workstream B minimum adoption gate

At least 50 independent, non-team MainNet users complete at least one eligible user-initiated marketplace action through the production reference implementation
At least 25 eligible completed purchase or sale settlements occur

Jubilee-controlled accounts, reviewer/test accounts, self-trading, and circular activity generated primarily to satisfy grant metrics do not count toward these thresholds.

MS2 operational adoption targets — reported but not binding acceptance conditions

The previously stated higher operational targets are retained:

Public launch and full mint completion of the first reference collection
At least 3,000 post-launch non-mint, user-initiated marketplace transactions
At least 1,000 completed purchase or sale transactions

MS3 — Settlement Module Preview, Ecosystem Onboarding & Embedded OneSwap Integration

Workstream A acceptance conditions

Preview source published for listings, offers, counter-offers, cancellations, allocation-backed escrow, and atomic payment distribution
Draft developer integration documentation and runnable examples published for the reusable collection creation, minting, transfer, escrow, and settlement surfaces
CIP-0112 compatibility scaffolding and tests extended across the applicable Holding and Transfer surfaces used by the settlement examples while preserving CIP-0056 V1 interoperability; no full V2 Allocation implementation is required within this grant
External-collection technical onboarding path documented
A structured process for collecting and incorporating external integration feedback operational

Workstream A minimum adoption gate

At least one independent Canton developer or external technical team must successfully execute at least one published settlement or escrow preview/test flow from the public repository without access to Jubilee's private application code.

The gate can be demonstrated through one or more of:

a public GitHub Discussion or equivalent public technical record documenting the result;
an execution log;
relevant transaction evidence; or
equivalent technical evidence that can be verified by the Committee.

Unlike MS2, which measures independent technical review, this gate requires a published settlement or escrow preview implementation itself to be successfully executed outside Jubilee's private application environment.

Workstream B acceptance conditions

Reference onboarding/launchpad surface accepts external collection submissions through a documented process
External creator/project onboarding flow demonstrable in the production environment
A user can execute a swap through the embedded OneSwap integration using Jubilee's built-in self-custody wallet without leaving the Jubilee interface
Marketplace, external-onboarding, and integration metrics reported to the Committee
External onboarding and real-user feedback collected for incorporation into Workstream A documentation and integration guidance

Workstream B minimum adoption gate

At least two external collections or ecosystem projects enter the documented Jubilee onboarding pipeline
At least one of those external collections or ecosystem projects completes a Canton MainNet launch through the production reference implementation
At least 100 cumulative independent, non-team MainNet users complete at least one eligible user-initiated marketplace action
At least 75 cumulative eligible completed purchase or sale settlements occur

MS2 demonstrates initial independent-user and settlement adoption. MS3 demonstrates growth in that activity together with external ecosystem onboarding.

MS3 operational adoption targets — reported but not binding acceptance conditions

The previously stated higher operational targets are retained:

At least three external collections or ecosystem projects enter the onboarding pipeline
At least two external collections launch on MainNet through Jubilee
At least one external technical team reviews the integration surface
At least 5,000 cumulative non-mint, user-initiated marketplace transactions
At least 2,000 cumulative completed purchase or sale transactions

MS4 — USDCx Settlement, Multi-Chain Onboarding & Full Stable Public-Good Release

Workstream A acceptance conditions

Complete stable release of all public-good components published in the public repository under Apache License 2.0, with the full DAML contract suite and atomic payment distribution logic covered by the two independent audits
Repository includes the NFT-focused implementation layer, marketplace primitives, atomic payment distribution templates, allocation-backed offer escrow, the separately published self-custody wallet reference implementation, tests, remediation notes, public audit reports or summaries consistent with auditor disclosure terms, and final developer documentation
CIP-0056 V1 alignment demonstrated through documented Holding and TransferFactory interface relationships, canonical AllocationFactory / Allocation usage for Canton Coin settlement legs, and runnable example flows
CIP-0056 V1 to CIP-0112 V2 adoption guide and tested cross-version examples published
A documented, runnable non-collectible example published demonstrating the reusable collection creation, minting, ownership, transfer, permissioning, and settlement modules outside an art or PFP use case
Applicable Holding and Transfer V2 interfaces implemented where the target Splice packages are available and production-suitable during the grant period; otherwise, the repository includes completed compatibility scaffolding and a tested phased V2-adoption path. A full V2 Allocation implementation remains outside the current grant scope
Published examples can be run and evaluated without access to Jubilee's private application code

Workstream A minimum adoption gate

At least one independent Canton developer or external technical team must install or set up the final stable public-good release outside Jubilee's private application environment using only the published repository and documentation, and successfully execute at least one reusable module flow or runnable example from that final release.

The gate can be demonstrated through one or more of:

reproducible execution evidence;
a relevant transaction record;
an execution log; or
a public GitHub Discussion or equivalent public technical validation record.

The distinction from MS3 is that MS4 validates the final stable release, rather than a preview: an external technical user must be able to reproduce a working flow independently using the public release and its documentation.

Workstream B acceptance conditions

An NFT can be listed, offered, and purchased in USDCx on Canton
Atomic USDCx payment distribution functions for completed settlements
At least one external bridge route or complementary onboarding path is demonstrably operational
USDCx usage, settlement, and interoperability metrics reported to the Committee
Production evidence and external-user feedback incorporated into final Workstream A documentation and integration guidance where applicable

Workstream B minimum adoption gate

At least 150 cumulative independent, non-team MainNet users complete at least one eligible user-initiated marketplace action
At least 50 completed USDCx-denominated purchase or sale settlements occur
Those USDCx settlements collectively involve at least 20 distinct independent, non-team user Party IDs

MS3 measures growth in generic marketplace settlement adoption and external ecosystem onboarding. MS4 measures independent-user adoption of the Workstream A settlement primitives specifically through the USDCx-denominated production settlement surface.

The external-project launch gate is therefore not repeated as a binding MS4 requirement; that adoption dimension is measured in MS3.

MS4 operational adoption targets — reported but not binding acceptance conditions

The previously stated higher USDCx targets are retained:

At least 200 completed non-mint, user-initiated USDCx marketplace transactions
At least 100 completed USDCx purchase or sale transactions

Funding

Total Funding Request: 600,000 CC

The total request is divided explicitly between the two separately evaluated workstreams:

Workstream / Budget Component	Allocation
Workstream A — Reusable public-good engineering & delivery	250,000 CC
Workstream A — Ring-fenced third-party security audits	150,000 CC
Workstream A — Total	400,000 CC
Workstream B — Production Reference Implementation & Ecosystem Validation	200,000 CC
Total Funding Request	600,000 CC

Workstream A receives the larger allocation because it contains the durable, reusable, open-source public-good outputs of the grant.

Of the 400,000 CC Workstream A allocation:

150,000 CC is reserved for two independent third-party security audits; and
250,000 CC supports reusable infrastructure engineering and delivery, including audit preparation and remediation, DAML and settlement-module hardening, CIP compatibility work, testing, public repository releases, developer documentation, runnable examples, the wallet reference implementation, and the final stable public-good release.

The 200,000 CC Workstream B allocation supports the production reference implementation and ecosystem-validation environment required to validate Workstream A under real Canton MainNet conditions.

This includes:

end-to-end MainNet validation of Workstream A primitives;
external creator and collection onboarding surfaces;
reference user and creator interfaces;
ecosystem-project onboarding;
wallet, bridge, OneSwap, and USDCx interoperability validation;
independent-user settlement validation;
production monitoring and operational evidence;
Committee reporting; and
incorporation of external production feedback into Workstream A documentation and integration guidance.

Where the same underlying capability is exercised by both workstreams, reusable protocol/public-good engineering is allocated to Workstream A, while the MainNet reference implementation, integration, and production-validation layer is allocated to Workstream B.

The same engineering deliverable will not be funded twice across the two workstreams.

Audit Budget

Within Workstream A, 150,000 CC is ring-fenced exclusively for the two independent third-party security audits covering the full DAML contract suite and atomic payment distribution logic.

This audit budget is included in the MS1 Workstream A allocation because MS1 acceptance and disbursement is the funding event that enables Jubilee to commission both audit firms immediately at the start of MS2.

At MS1 acceptance, scope, quote, SOW, engagement documentation, or equivalent commercial evidence for the audit engagements will be available for Committee review.

During MS2, Jubilee will provide evidence of audit engagement and payment status to the Committee.

The same third-party audit vendor costs are not budgeted again in MS2.

The 150,000 CC amount reflects the current audit-scoping budget.

If actual third-party audit costs are lower than the amount reserved, the unused balance will be reported to the Committee. It will either be returned by Jubilee or reallocated to another clearly defined grant deliverable only with the Committee's prior written approval.

Payment Breakdown by Milestone and Workstream

The existing milestone totals are unchanged.

Milestone	Workstream A	Workstream B	Total
Milestone 1 — MainNet Hardening, Audit Readiness & Public Architecture	170,000 CC	30,000 CC	200,000 CC
Milestone 2 — Independent Audits, Core Primitive Preview & Product Readiness	90,000 CC	70,000 CC	160,000 CC
Milestone 3 — Settlement Module Preview, Ecosystem Onboarding & Embedded OneSwap Integration	60,000 CC	50,000 CC	110,000 CC
Milestone 4 — USDCx Settlement, Multi-Chain Onboarding & Full Stable Public-Good Release	80,000 CC	50,000 CC	130,000 CC
Total	400,000 CC	200,000 CC	600,000 CC

Of the 170,000 CC Workstream A allocation in MS1, 150,000 CC is the ring-fenced third-party audit budget. The remaining 20,000 CC supports the MS1 Workstream A audit-readiness, architecture, testing, and initial public-repository deliverables.

Cost Drivers per Milestone

MS1 — 200,000 CC: audit readiness, public architecture, initial repository release, MainNet production-reference hardening, and the 150,000 CC ring-fenced Workstream A audit budget required to commission both independent audits at the start of MS2.
MS2 — 160,000 CC: audit remediation and security-response engineering, core primitive preview release, CIP compatibility work, atomic payment-distribution validation, production-reference implementation hardening and validation, creator/wallet validation surfaces, reference-collection lifecycle validation, and MainNet reporting. Third-party audit vendor costs are not duplicated here.
MS3 — 110,000 CC: marketplace and settlement-module preview release, developer integration examples, external technical validation, external collection/project onboarding, reference launchpad/onboarding infrastructure, and embedded OneSwap interoperability validation.
MS4 — 130,000 CC: complete stable public-good release, final documentation and runnable examples, USDCx-denominated production settlement validation, an additional external bridge route or complementary onboarding path, final independent-user adoption validation, interoperability reporting, and publication of audit materials consistent with auditor disclosure terms.

Volatility Stipulation

Project duration is approximately 13–15 weeks (~3–3.5 months), well under the six-month threshold defined in CIP-0100. Should the project timeline extend beyond 6 months due to Committee-requested scope changes, any remaining milestones must be renegotiated to account for significant USD/CC price volatility.

Co-Marketing

Upon each milestone delivery, Jubilee will collaborate with the Canton Foundation on:

Milestone 1: Coordinated MainNet and public-architecture progress announcement
Milestone 2: Technical blog covering DAML contract architecture, security audit outcomes, the core primitive preview, and the Jubilee reference-collection lifecycle
Milestone 3: Developer-preview content covering the settlement modules, an ecosystem onboarding case study, and a joint announcement of the embedded OneSwap integration
Milestone 4: Developer-focused content promoting the full stable public-good release and its audited DAML and atomic-payment components, CIP-0056 V1 interoperability, the CIP-0112 V2 phased V2-adoption path, and the marketplace primitives as Canton ecosystem public goods

Motivation

The Gap

Canton has rapidly matured into institutional-grade infrastructure, with participants including DTCC, BNY, Goldman Sachs, BNP Paribas, and others operating on the network. However, the ecosystem currently lacks a standardized, privacy-native surface for creating, discovering, and trading non-fungible digital assets at consumer scale.

Today there is:

No NFT-focused reference implementation atop CIP-56
No publicly launched production-grade NFT marketplace running on Canton MainNet
No unified asset onboarding interface for Canton-native NFT projects
No open-source primitives that future builders can reuse for non-fungible asset creation and exchange

This creates a structural gap: Canton ecosystem projects cannot easily launch asset collections, institutions lack a native asset interaction layer, and builders lack reusable primitives for asset creation and exchange.

Why Privacy Matters for Non-Fungible Assets

On public blockchains, every NFT ownership record is globally visible. This is fundamentally incompatible with use cases where own

Shown up to 60,000 characters. Read the full file on GitHub ↗

Journey on the board 10 moves, stepped back or reopened 2

Now: Declined, 6.5 days since 14-10-2026
Waiting: decided on the board but the PR is still open. The board shows Declined but the pull request is still open.
First human response: 36 days after opening, by jackcharlesworth (committee side)

Incoming29-04-2026 to 05-05-20265.9 daysmoved by github-project-automation
Needs Champion05-05-2026 to 04-06-202630 daysmoved by hythloda
In Review (Champion Assigned)04-06-2026 to 22-06-202618 daysmoved by jackcharlesworth
Ready for Vote22-06-2026 to 09-07-202617 daysmoved by jackcharlesworth
Voting Live09-07-2026 to 22-07-202613 daysmoved by hythloda
Ready for Vote22-07-2026 to 03-08-202612 daysmoved by hythloda
Voting Live03-08-2026 to 09-09-202637 daysmoved by hythloda
Needs Revision09-09-2026 to 10-09-20261 daymoved by hythloda
Voting Live10-09-2026 to 14-10-202634 daysmoved by hythloda
Declined14-10-2026 to now6.5 daysmoved by hythloda

Rebuilt from the recorded board moves (complete history). get_dev_fund_lifecycle(number) gives the same in the MCP.

Timeline 20 events

29-04-2026review requested from team:admins by Jubilee-Market
29-04-2026review requested from tkatrichenko by Jubilee-Market
29-04-2026review requested from hythloda by Jubilee-Market
29-04-2026review requested from stas-sbi by Jubilee-Market
29-04-2026review requested from waynecollier-da by Jubilee-Market
29-04-2026review requested from isegall-da by Jubilee-Market
29-04-2026added to the project board by github-project-automation[bot]
29-04-2026moved to another column of the project board by github-project-automation[bot]
05-05-2026moved to another column of the project board by hythloda
04-06-2026label added: champion-confirmed by jackcharlesworth
04-06-2026moved to another column of the project board by jackcharlesworth
22-06-2026label added: token-asset-standards by jackcharlesworth
22-06-2026moved to another column of the project board by jackcharlesworth
09-07-2026moved to another column of the project board by hythloda
22-07-2026assigned to jackcharlesworth by jackcharlesworth
22-07-2026moved to another column of the project board by hythloda
03-08-2026moved to another column of the project board by hythloda
09-09-2026moved to another column of the project board by hythloda
10-09-2026moved to another column of the project board by hythloda
14-10-2026moved to another column of the project board by hythloda

← Back to Proposals Open on GitHub ↗