Amanda MartinOriginal post

Jan 21, 2026

Please see below for open discussion.

Number: CIP-TBD
Title: Featured App Staking 
Author(s): W Eric Saraniecki  
Type: Tokenomics  
Status: Draft
Created: 2026-01-21
License: CC0-1.0

Featured App Staking

Summary

This proposal introduces Featured App (FA) Staking as a requirement for achieving and maintaining Featured App status on the Canton Network.

To qualify as a Featured App, an application must:

Maintain good standing with the Foundation, and
Maintain a minimum amount of Canton Coin (CC) staked on its behalf.

If the required minimum lock is not maintained, the application immediately loses Featured App status.

Any CC holder may stake CC on behalf of an application.

Motivation

Featured App status conveys visibility, credibility, and access to network incentives. As the network matures, Featured Apps should demonstrate not only functional alignment but also durable economic commitment.

App staking:

Aligns incentives between app operators, users, and the network
Introduces objective, on-chain criteria alongside qualitative approval
Enables community participation in backing high-quality applications
Scales naturally as the ecosystem grows

Specification

1. Featured App Qualification Requirements

To be designated or remain a Featured App, an application must satisfy both of the following:

1.1 Foundation Good Standing

The Foundation retains discretion over Featured App designation based on qualitative criteria, including:

Alignment with network goals
Compliance with applicable policies
On-chain and off-chain behavior

1.2 Minimum CC Stake Requirement

A minimum amount of CC must be actively staked on behalf of the application.

Failure to satisfy either requirement results in loss of Featured App status.

2. Phased Implementation

To minimize operational risk and align with the SV Staking rollout, Featured App staking will be implemented in two phases, followed by ongoing parameter review.

Phase 1: Transitional Enforcement (Manual)

Activation

Goes into effect within 15 days of CIP approval

Staking Requirement

Minimum stake: 10 million CC per Featured App PartyId

Requirements

CC intended to count toward App staking must be moved to a segregated, auditable PartyId
The PartyId information must be shared with the Foundation
Any CC holder may sponsor an application by:

Registering the PartyId holding the CC, and
Registering the PartyId of the application being sponsored

Featured Status Determination

Featured App status will be manually managed by SVs
Apps are featured or unfeatured based on whether the required CC is present in the registered PartyId

Phase 2: On-Chain Locking (Automated App Staking)

Activation

Begins once the CC locking mechanism used for SV staking is deployed to MainNet

Staking Requirement

Minimum stake: 25 million CC per Featured App PartyId

Mechanism

Featured Apps must utilize the on-chain locking mechanism
Only actively locked CC counts toward Featured App eligibility
Any CC holder may lock CC on behalf of an application

Unlocking Rules

CC may be unlocked at any time
Unlocks take 365 days to become effective
Once an unlock is initiated and the locked balance falls below the required threshold, the app loses Featured status

3. Third-Party App Backing

Any CC holder may stake CC on behalf of an application
App operators are not required to supply the stake themselves
Multiple CC holders may collectively satisfy the staking requirement

This enables:

Community signaling around valuable applications
Decentralized support for ecosystem development
Capital-efficient participation for early-stage teams

4. Ongoing Parameter Review

The minimum CC stake required for Featured App status will be reviewed every 90 days
Reviews will be conducted by the Foundation’s Tokenomics Committee
Any changes will be:

Communicated in advance, and
Applied prospectively

This allows the network to adjust expectations as the ecosystem matures without frequent governance changes.

Backwards Compatibility

No historical rewards or prior app activity are modified
This proposal applies prospectively to Featured App designation

Copyright

This CIP is licensed under CC0-1.0: Creative Commons CC0 1.0 Universal.

Changelog

2025-01-21: Initial draft of the proposal

Yiannis Varelas

Jan 21, 2026

Hi Eric,

Thanks for putting this together. You are doing the hard work here and really want to emphasize this. Here is my take:

I support the general direction of this CIP and agree that Featured App status should reflect real economic commitment, not just qualitative approval, but I think a few adjustments would materially improve robustness and fairness.

In particular, an immediate loss of Featured status when a stake dips below the threshold feels overly harsh in practice, and a short grace period (7-10 days?) would better reflect operational reality without weakening incentives.

I’d also strongly favor greater transparency around third-party staking (e.g. disclosure of large sponsors) to reduce governance ambiguity and *probably* a more formulaic or clearly bounded approach to periodic threshold adjustments to avoid moving goalposts.

These refinements are not deal breaking for me, I just want to raise those as things that I believe would improve the perception of the app builders about the FA status AND signal our strong support to the actual builders without punishing them for things that could (and will) go wrong initially.

Again, super supportive of this.

Anthony Merriman

Jan 22, 2026

First - just want to note that it's really awesome to see discussions about innovations like these. It's clear that the ecosystem is committed to finding ways to continually improve the network and invest for the long term.

On surface level, it's our belief that this proposal may cause significant and unintentional second-order effects for the broader network and ecosystem. I believe we can all agree that having more teams building on Canton and writing DAML is net beneficial. Unfortunately we would expect this proposal to dramatically reduce innovation and activity from current and future teams. It is our view that a more precise application of a new barrier to entry may be more effective to maintain innovation in the ecosystem.

Before discussing some of our concerns, I wanted to highlight what we understand of the goals and intent of these changes:

Ensure prospective featured apps are materially tied to the performance of CC (via investment)
Increase ecosystem due diligence by incentivizing conversations between prospective featured apps and large CC holders
Reduce CC available supply for sale

These are some of the downstream implications we foresee:

Reduction in development and innovation in the ecosystem
Founders and builders, especially in small companies, are already taking significant risk by building on Canton. This is a new ecosystem that is hard to navigate with network funding (token incentives) that has become much more competitive in a matter of weeks. This change makes it highly impractical for a small team to break through because they may need $3m+ in funding on day one otherwise they risk being locked out after building an app.
Creating secondary, off-chain lending (and structured investment) markets
The vast majority of teams will not be able to fund $3m+ to get their app approved. This means that these teams will either need to borrow CC (likely from the SVs) or attempt to sell equity (in an unproven start-up building in an ecosystem that is brand new) in exchange for tokens to lock up for a year. We would expect to see current large CC holders look to acquire equity + revenue sharing agreements with specific teams in exchange for lending the required CC. This isn't a critique of large CC holders acting ~rationally. It's just a predictable market response to the constraints as proposed. And just to be super clear - we know the suggested concept is that current CC holders will "stake" or "bond" their CC with an existing app but the current proposal doesn't specify a mechanism. Locking CC should require a significant risk premium and any holder will rationally seek to extract that premium from the applications that can't afford to fund the CC themselves.
Misaligning incentives for app developers
Builders in Canton are already, in many cases, 100% devoted to developing applications in Canton. Previously, the featured app rewards program created extremely strong economic incentives for new teams to experiment, acquire users, and iterate on PMF. However it's becoming much more challenging to generate revenue with featured app rewards, and the natural expectation is that featured app rewards will no longer be profitable in the coming months. I think it's risky to expect future development when there is no direct subsidy for new teams. It's even riskier to expect almost anyone to lock $3m+ of working capital in a highly speculative asset.
Could plausibly shut down a large number (75%+?) of current featured apps
The current proposed schedule (15 day window) to acquire a significant CC quantity (or otherwise negotiate with investors or lenders) may shutter the majority of the current featured apps in the ecosystem. Apps outside of the top 25 are typically generating <100k CC in net rewards per week. There's no feasible way for these apps to secure the CC required and they will be forced out of the program.
Creating additional incentive misalignment for early holders vs. new entrants
More CC has been issued in the last 18 months than will be issued in the next 60. This reality has a tendency to shift behavior between early holders and future builders. There's more incentive to focus on token price when your ability to receive tokens is reduced. But the majority of applications and infrastructure hasn't been built yet. The likely outcome as the ecosystem matures is that new entrants will be facing stiffer competition while vying for fewer rewards.
Increased volatility from reduction in market liquidity
Token locks are typically implemented to try to reduce available supply for sale with the belief that less supply (or inflation) will lead to an increase in price, either by artificially increasing demand (due to perception) or by reducing the supply for sale at any given time. The actual long-term impact of this activity, however, is naturally neutral at best but often negative in many cases. Liquidity reduction works in both directions, and humans have a tendency to exaggerate downside moves more than upside. This means that a CC price bear market will be also artificially enhanced (especially when the news hits about large holders unlocking). This is made worse by an incentive mechanism that is convex with prices in CC (most app activity would be expected to be highly sensitive to changes in app rewards, regardless of how profitable the core business is).
Creates additional uncertainty around future governance and stability
Speaking as both an operator, and previously, an investor, uncertainty is one of the strongest deterrents of long-term commitment (and development). There are countless apps that have dedicated significant resources to building something in Canton and spent their own time and capital without budgeting for a multimillion dollar outlay to purchase CC. Any current (or future) featured app has bet its existence on building in Canton. They're already extremely long CC by virtue of app rewards.

With all of this out of the way, the most exciting part about these proposals is that I think it's possible to imagine a few small changes that remove almost all of the aforementioned issues while improving the ecosystem.

One possible simple change? Reduce the severity of the requirements (at least at first).

No up-front locked CC (just approval via a more strict process)
Locked CC requirements that increase over time (as the app launches and grows)
- 100k CC for first 3 months
- 500k CC after 3 months
- 1mm CC after 6 months
- 5mm CC after 12 months
- 10mm CC after 18 months
- 25mm CC after 24 months

This enables new builders to prove product-market fit while still ensuring a minimum investment to be involved. It also enables successful teams to maintain skin in the game as they grow their application's usage over time. And the ramping is far more feasible for a bootstrapped team (like ourselves).

And an even more robust change? Allocate the locked SV+Validator CC to a Featured App voting pool.

SVs and validators benefit from network activity. They are incentivized to make sure the best apps continue to come into the ecosystem and that the best apps have the ability to fund themselves via rewards.

1 vote per CC
Apps are required to reach a certain thresholds of votes (5mm?) to get featured app status
The required quantity of votes increases according to a schedule (apps are incentivized to keep building new features)
- 5mm votes to be approved
- 25mm votes to maintain status after 6 months
Optional: a portion of CC issuance is allocated to pool members pro-rata based on voting share (or application performance)

The benefits of this approach are significant compared to the original proposal. Applications continue to be built while requiring these applications to speak directly with key stakeholders in the ecosystem to be approved. This approach would likely introduce other issues like vote buying but the large stakeholder has relatively less power compared to the original proposal.

Apologies for such a long post! I'm looking forward to seeing more of this discussion and would be happy to participate in live discussions if I can be of any help.

Eric Saraniecki

Jan 22, 2026

thanks everyone for the feedback and creative ideas - please keep them coming - ill respond when a bit more comes in as opposed to one-by-one

Show quoted message

On Thu, Jan 22, 2026 at 7:33 AM anthony via lists.sync.global <anthony=modulo.finance@...> wrote:

First - just want to note that it's really awesome to see discussions about innovations like these. It's clear that the ecosystem is committed to finding ways to continually improve the network and invest for the long term.

On surface level, it's our belief that this proposal may cause significant and unintentional second-order effects for the broader network and ecosystem. I believe we can all agree that having more teams building on Canton and writing DAML is net beneficial. Unfortunately we would expect this proposal to dramatically reduce innovation and activity from current and future teams. It is our view that a more precise application of a new barrier to entry may be more effective to maintain innovation in the ecosystem.

Before discussing some of our concerns, I wanted to highlight what we understand of the goals and intent of these changes:

Ensure prospective featured apps are materially tied to the performance of CC (via investment)

Increase ecosystem due diligence by incentivizing conversations between prospective featured apps and large CC holders

Reduce CC available supply for sale

These are some of the downstream implications we foresee:

Reduction in development and innovation in the ecosystem
Founders and builders, especially in small companies, are already taking significant risk by building on Canton. This is a new ecosystem that is hard to navigate with network funding (token incentives) that has become much more competitive in a matter of weeks. This change makes it highly impractical for a small team to break through because they may need $3m+ in funding on day one otherwise they risk being locked out after building an app.

Creating secondary, off-chain lending (and structured investment) markets
The vast majority of teams will not be able to fund $3m+ to get their app approved. This means that these teams will either need to borrow CC (likely from the SVs) or attempt to sell equity (in an unproven start-up building in an ecosystem that is brand new) in exchange for tokens to lock up for a year. We would expect to see current large CC holders look to acquire equity + revenue sharing agreements with specific teams in exchange for lending the required CC. This isn't a critique of large CC holders acting ~rationally. It's just a predictable market response to the constraints as proposed. And just to be super clear - we know the suggested concept is that current CC holders will "stake" or "bond" their CC with an existing app but the current proposal doesn't specify a mechanism. Locking CC should require a significant risk premium and any holder will rationally seek to extract that premium from the applications that can't afford to fund the CC themselves.

Misaligning incentives for app developers
Builders in Canton are already, in many cases, 100% devoted to developing applications in Canton. Previously, the featured app rewards program created extremely strong economic incentives for new teams to experiment, acquire users, and iterate on PMF. However it's becoming much more challenging to generate revenue with featured app rewards, and the natural expectation is that featured app rewards will no longer be profitable in the coming months. I think it's risky to expect future development when there is no direct subsidy for new teams. It's even riskier to expect almost anyone to lock $3m+ of working capital in a highly speculative asset.

Could plausibly shut down a large number (75%+?) of current featured apps
The current proposed schedule (15 day window) to acquire a significant CC quantity (or otherwise negotiate with investors or lenders) may shutter the majority of the current featured apps in the ecosystem. Apps outside of the top 25 are typically generating <100k CC in net rewards per week. There's no feasible way for these apps to secure the CC required and they will be forced out of the program.

Creating additional incentive misalignment for early holders vs. new entrants
More CC has been issued in the last 18 months than will be issued in the next 60. This reality has a tendency to shift behavior between early holders and future builders. There's more incentive to focus on token price when your ability to receive tokens is reduced. But the majority of applications and infrastructure hasn't been built yet. The likely outcome as the ecosystem matures is that new entrants will be facing stiffer competition while vying for fewer rewards.

Increased volatility from reduction in market liquidity
Token locks are typically implemented to try to reduce available supply for sale with the belief that less supply (or inflation) will lead to an increase in price, either by artificially increasing demand (due to perception) or by reducing the supply for sale at any given time. The actual long-term impact of this activity, however, is naturally neutral at best but often negative in many cases. Liquidity reduction works in both directions, and humans have a tendency to exaggerate downside moves more than upside. This means that a CC price bear market will be also artificially enhanced (especially when the news hits about large holders unlocking). This is made worse by an incentive mechanism that is convex with prices in CC (most app activity would be expected to be highly sensitive to changes in app rewards, regardless of how profitable the core business is).

Creates additional uncertainty around future governance and stability
Speaking as both an operator, and previously, an investor, uncertainty is one of the strongest deterrents of long-term commitment (and development). There are countless apps that have dedicated significant resources to building something in Canton and spent their own time and capital without budgeting for a multimillion dollar outlay to purchase CC. Any current (or future) featured app has bet its existence on building in Canton. They're already extremely long CC by virtue of app rewards.

With all of this out of the way, the most exciting part about these proposals is that I think it's possible to imagine a few small changes that remove almost all of the aforementioned issues while improving the ecosystem.

One possible simple change? Reduce the severity of the requirements (at least at first).

No up-front locked CC (just approval via a more strict process)

Locked CC requirements that increase over time (as the app launches and grows)

100k CC for first 3 months

500k CC after 3 months

1mm CC after 6 months

5mm CC after 12 months

10mm CC after 18 months

25mm CC after 24 months

This enables new builders to prove product-market fit while still ensuring a minimum investment to be involved. It also enables successful teams to maintain skin in the game as they grow their application's usage over time. And the ramping is far more feasible for a bootstrapped team (like ourselves).

And an even more robust change? Allocate the locked SV+Validator CC to a Featured App voting pool.

SVs and validators benefit from network activity. They are incentivized to make sure the best apps continue to come into the ecosystem and that the best apps have the ability to fund themselves via rewards.

1 vote per CC

Apps are required to reach a certain thresholds of votes (5mm?) to get featured app status

The required quantity of votes increases according to a schedule (apps are incentivized to keep building new features)

5mm votes to be approved

25mm votes to maintain status after 6 months

Optional: a portion of CC issuance is allocated to pool members pro-rata based on voting share (or application performance)

The benefits of this approach are significant compared to the original proposal. Applications continue to be built while requiring these applications to speak directly with key stakeholders in the ecosystem to be approved. This approach would likely introduce other issues like vote buying but the large stakeholder has relatively less power compared to the original proposal.

Apologies for such a long post! I'm looking forward to seeing more of this discussion and would be happy to participate in live discussions if I can be of any help.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Aki

Jan 23, 2026

Hi all — to add to the discussion, I want to consolidate my thoughts on the Featured App (FA) proposal from the builder side.

Scaling bonding

It makes logical sense for Featured Apps to start with a smaller bond and increase it over time. However, a strictly time-based ramp (X CC at 3, 6, 12 months) assumes a uniform path to traction that doesn’t reflect reality. Some apps find PMF quickly, others take longer, depending on product scope, customer cycles, speed of execution, ability to earn FA rewards early, and external dependencies. In many ecosystems, the eventual winning apps take time to emerge.

Given that, a milestone- or activity-based bonding requirement feels more precise. For example: once an app crosses a defined threshold (usage, rewards earned, volume, revenue, etc.), it must bond Y CC. Below that threshold, the requirement remains lower. This ties bonding directly to demonstrated impact rather than calendar time, avoids penalizing slower-but-promising teams, and still ensures that successful apps scale their economic commitment as they scale their footprint.

Barrier to entry

Barrier to entry is already a real issue, and the recent changes around capping Featured Apps have made the path even less attractive for new builders. Adding a large upfront bonding requirement on top of that compounds the problem.

In practice, setting up on Canton today is expensive and operationally heavy. When I speak with startup teams, I usually tell them they need roughly $250–500k just to get to a first meaningful deployment:

At least one dedicated Daml developer
At least one DevOps engineer to handle frequent infra and network changes
Access to a node and paying a node operator ~$5–8k per month, or starting on a multi-tenant setup with limited permissions

This already means Canton is not really a “garage startup” ecosystem. It skews toward mid-market SMBs and well-capitalized teams. Large upfront CC bonding raises that bar even further.

Enforcement mechanics

I strongly suggest an explicit grace period before any loss of Featured App status when a bonding threshold is missed (e.g. 7–14 days). This is especially important given that unpausing or re-approving FAs today can take a long time due to meetings and coordination.

Wherever possible, these transitions should be on-chain, deterministic, and verifiable. That’s the only model that scales.

SV sponsorship and attribution

Finally, the idea of SVs sponsoring new entrants makes sense financially and structurally. SVs already act as economic and governance gatekeepers. Extending that role so SVs can also allocate bonded CC to sponsor Featured Apps creates a cleaner model:

Sponsorship should be non-exclusive
Multiple SVs can sponsor an FA, or a single SV can bond 100% if needed
Any bonding done on behalf of an FA should be attributed on-chain, clearly showing who bonded CC for which FA and in what amount

Taken together, milestone-based bonding, on-chain attribution, and SV sponsorship feel like a more realistic way to protect network quality without choking off new builders.

Aki

Jan 23, 2026

Hello Eric and community — one more related point.

The current proposal suggests one bond per PartyId for each Featured App. I think this creates the wrong incentive. It encourages teams to minimize PartyIds, even though finer-grained PartyId separation has been repeatedly cited as beneficial for observability, traceability, and clean system design.

From an engineering and operations perspective, this will matter more over time. Our team is already pushing for stronger separation of concerns. For example, our attester node is currently bundled with other applications on a node operator’s infrastructure, which introduces DevOps complexity and makes uptime and fault isolation harder. As Canton scales, it’s reasonable to expect application providers to want dedicated nodes (and therefore PartyIds) for reliability, security, and operational reasons.

If bonding scales with PartyIds, we end up penalizing good architecture. PartyIds reflect deployment and node structure, not the economic footprint of an application.

A cleaner approach is to anchor bonding to the Featured App designation itself:

One bond per Featured App designation, not per PartyId
If a company has multiple Featured Apps, it posts multiple bonds
To my earlier suggestion, each bond scales with the activity of that specific app

For example, BitSafe has two Featured App designations (CBTC and Vaults), so two bonds make sense.

Aki

Orion

Jan 23, 2026

Hi all — thanks Eric for putting this proposal forward and for engaging openly with the feedback. I want to echo support for the direction of the CIP: tying Featured App status to durable economic commitment is essential. However, we've seen this distort incentives in other ecosystems too.

A few points I think are important to surface as this discussion progresses:

Severity and timing of enforcement matter as much as thresholds
Multiple builders have raised concerns that immediate or near-immediate loss of Featured status creates operational and existential risk for teams, especially given real-world coordination delays. A short, explicit grace period and deterministic on-chain enforcement would materially improve robustness without weakening incentives.
Upfront capital requirements risk suppressing early-stage experimentation
The proposal’s intent is clear, but fixed, high initial CC locks may unintentionally bias the ecosystem toward already well-capitalized teams. Several responses suggest ramped or activity-based requirements (rather than purely time-based) as a way to preserve innovation while still scaling economic commitment as apps prove impact.
Third-party and SV-backed staking needs first-class, on-chain attribution
If community or SV sponsorship is a core mechanism, it should be explicit, non-exclusive, and transparently attributed on-ledger. This reduces governance ambiguity and avoids pushing these arrangements into opaque, off-chain agreements.
Bonding should align to Featured App designation, not PartyId topology
Tying stake requirements to PartyIds risks penalizing good system architecture and separation of concerns. Anchoring bonding to the Featured App designation itself (per app, not per deployment identity) seems more aligned with long-term operability.
Liquid staking may be a complementary tool, not a replacement
One possible path to reconcile these tensions is allowing CC holders to support Featured Apps via governed, on-ledger liquid staking mechanisms. This preserves economic commitment while reducing liquidity and coordination friction for builders and sponsors.

Overall, I strongly support the goal of strengthening alignment between apps, CC holders, and the network. The main opportunity here feels less about whether to require economic commitment, and more about how to do so in a way that sustains builder confidence and long-term ecosystem growth.

Happy to continue the discussion or help explore complementary mechanisms if useful.

Eric Saraniecki

Jan 23, 2026

love all the feedback everyone - please keep it coming!

sometime next week, ill re-draft the proposals based on everyone's input - I don't think i'll address every comment one-by-one

Show quoted message

On Fri, Jan 23, 2026 at 4:17 PM orion via lists.sync.global <orion=ninerealms.co@...> wrote:

Hi all — thanks Eric for putting this proposal forward and for engaging openly with the feedback. I want to echo support for the direction of the CIP: tying Featured App status to durable economic commitment is essential. However, we've seen this distort incentives in other ecosystems too.

A few points I think are important to surface as this discussion progresses:

Severity and timing of enforcement matter as much as thresholds
Multiple builders have raised concerns that immediate or near-immediate loss of Featured status creates operational and existential risk for teams, especially given real-world coordination delays. A short, explicit grace period and deterministic on-chain enforcement would materially improve robustness without weakening incentives.

Upfront capital requirements risk suppressing early-stage experimentation
The proposal’s intent is clear, but fixed, high initial CC locks may unintentionally bias the ecosystem toward already well-capitalized teams. Several responses suggest ramped or activity-based requirements (rather than purely time-based) as a way to preserve innovation while still scaling economic commitment as apps prove impact.

Third-party and SV-backed staking needs first-class, on-chain attribution
If community or SV sponsorship is a core mechanism, it should be explicit, non-exclusive, and transparently attributed on-ledger. This reduces governance ambiguity and avoids pushing these arrangements into opaque, off-chain agreements.

Bonding should align to Featured App designation, not PartyId topology
Tying stake requirements to PartyIds risks penalizing good system architecture and separation of concerns. Anchoring bonding to the Featured App designation itself (per app, not per deployment identity) seems more aligned with long-term operability.

Liquid staking may be a complementary tool, not a replacement
One possible path to reconcile these tensions is allowing CC holders to support Featured Apps via governed, on-ledger liquid staking mechanisms. This preserves economic commitment while reducing liquidity and coordination friction for builders and sponsors.

Overall, I strongly support the goal of strengthening alignment between apps, CC holders, and the network. The main opportunity here feels less about whether to require economic commitment, and more about how to do so in a way that sustains builder confidence and long-term ecosystem growth.

Happy to continue the discussion or help explore complementary mechanisms if useful.

Dave M

Jan 26, 2026

Hi everyone,

As a small bootstrapped company building on the network, this is a massive disincentive.

Anthony mentioned $3M above, but at today’s prices (~$0.15), 25M CC for Featured App status plus 2M to run a validator comes to over $4M. And that’s before infrastructure costs, before any of us take wages etc.

What I’d propose alternatively is that instead of staking upfront, Featured Apps get a threshold of Reward Coupons that are immediately redeemable, after which Reward Coupons only unlock after 1 year: for example, the first 5M CC in rewards function as they do today. Then all rewards beyond that subject to a 12-month vesting period.

So early on, developers can draw down on CC rewards to cover traffic costs, etc. By the time they’ve hit product-market-fit, the rewards being vested ensures long-term alignment with the economics of network at large. But doing it after the fact means it doesn’t come with the initial friction of bootstrapped teams having to find millions up front.

I do understand the sentiment around economic alignment and appreciate that the aim is to make everything work for the good of the network as a whole but think the proposal as it stands is a huge barrier to entry. Not just the change itself, but also the fact that, from when we onboarded onto the network until now (~ 6 months) the tokenomics are in constant flux, which makes it very very hard to plan against.

If you do go ahead with the up-front staking solution, could it be grandfathered in e.g. with a 12 month grace period? That would at least give existing developers on the network a chance to adjust; this is a very dramatic change for 15 days notice after CIP approval.

Best wishes

toggle quoted message Show quoted text

Show quoted message

On Fri, 23 Jan 2026 at 14:14, aki via lists.sync.global <aki=bitsafe.finance@...> wrote:

Hello Eric and community — one more related point.

The current proposal suggests one bond per PartyId for each Featured App. I think this creates the wrong incentive. It encourages teams to minimize PartyIds, even though finer-grained PartyId separation has been repeatedly cited as beneficial for observability, traceability, and clean system design.

From an engineering and operations perspective, this will matter more over time. Our team is already pushing for stronger separation of concerns. For example, our attester node is currently bundled with other applications on a node operator’s infrastructure, which introduces DevOps complexity and makes uptime and fault isolation harder. As Canton scales, it’s reasonable to expect application providers to want dedicated nodes (and therefore PartyIds) for reliability, security, and operational reasons.

If bonding scales with PartyIds, we end up penalizing good architecture. PartyIds reflect deployment and node structure, not the economic footprint of an application.

A cleaner approach is to anchor bonding to the Featured App designation itself:

One bond per Featured App designation, not per PartyId

If a company has multiple Featured Apps, it posts multiple bonds

To my earlier suggestion, each bond scales with the activity of that specific app

For example, BitSafe has two Featured App designations (CBTC and Vaults), so two bonds make sense.

Aki

Dave M

Jan 26, 2026

Hi everyone,

As a small bootstrapped company building on the network, this is a massive disincentive.

Dave

---

PS - Sorry if this ends up double-posting. I replied to the email but didn't see my reply make the thread so just adding again in case it got lost in the ether.

Liz

Jan 27, 2026

Thanks Eric. I want to build on the creative thinking Anthony and Aki have started.

I've been thinking about the "how" for some time. The reality is when you're in lean bootstrap phase it's hard to make it all happen. But you're right to ask the question as we look at our next growth milestones as a network.

What I have observed is we're a large ecosystem of builders. So if we want to solve the alignment problem, it will take more than a CC lock - this just proves some have capital, product maturity, and access. I also share the concerns Anthony and Dave raised about timeline and capital requirements for smaller teams. Even if we wanted to raise the capital, securing a meeting is barely achievable in this window.

True alignment comes from transaction flow between participants. And frankly, reducing friction on the inflows side of the big players too - many of whom have limited experience in DeFi workflows.

Alternative mechanisms worth exploring

Instead of (or in addition to) pure capital lockup, what if we incentivized:

Workflow visibility and participation - Make the pipelines for inbound institutional assets accessible to FAs who can add value. If I can see a tokenization flow coming, I can build services for it.
App Stack bundling - TradFi doesn't buy point solutions. What if FA rewards weighted toward apps that bundle into complete workflows that institutions actually purchase?
Graduated commitment tied to bundles - Per Aki's point on milestone-based requirements, but take it further: make a commitment to a bundle, tie the FA rewards to the stack. Add an expiry coupon and you have asset pools that could potentially link to predictions, leverage, and more. Now CC isn't just locked - it's working, generating transactions, creating markets.

Here is an example that brings these ideas to life

If a new fund manager is looking to launch at Canton, the Featured App store experience is not how they buy. Instead, they need to solve "a job to be done":

Primary market (Create/Redeem): Custody and asset verification → vaults + proof of reserves (custody app + attestation app); Authorized Participant coordination → permissioned minting/burning (access control + token app); NAV calculation and attestation → oracles + on-chain price feeds (data app + pricing app) and more.

Then secondary market trading generates 10-100x the transaction volume of primary - market makers, arbitrage desks, collateral optimization. Add the retail wrapper and you've got continuous flow.

Easier to write than execute. But the reality is that's what the apps and network needs next. Across multiple assets, workflows and markets.

ETFs on-chain: potential inflows × workflows × apps + secondary multiplier
MMFs on-chain: potential inflows × workflows × apps + secondary multiplier

Do this and we have markets forming - better than ANY network.

Finally, intra-ecosystem spending - if more of the services apps spend on - AI/compute, creative, consulting, legal, accounting - were purchasable in CC from ecosystem participants the flow stays in the network. We have some, but could expand with incentives for CC-only contracts. I know most of my spend leaks to fiat-only vendors. Let alone to the bigger consultants who have been operating around Canton, but are not in the CC on-chain flow yet either.

Happy to collab more on any of the ideas. Thanks for raising this important matter for us all.

Anthony Merriman

Jan 29, 2026

After reading comments here and speaking to additional ecosystem participants, I'd like to post a follow-up with a proposed new structure and example new draft CIP structure for further consideration. I believe we have an opportunity to move the entire ecosystem forward on a more sustainable path to help bring the next 500 apps and 5m users onto Canton and I want to help make this a reality.

Proposal: Bonded Incentives for Featured Apps

Summary

This proposal introduces a bond-based reallocation of Canton Coin (CC) network incentives for Featured Apps (FAs). The objective is to reduce immediate CC sell pressure, strengthen long-term alignment among ecosystem participants, and introduce clearer accountability standards for new entrants without excluding early-stage or lesser-capitalized teams.

Motivation

This proposal is designed to address three core issues observed in the current incentive structure:

Excess CC supply for sale
Incentives are currently received as liquid CC, creating short-term sell pressure and weak long-term alignment
Misalignment with long-term CC price appreciation
Participants can earn rewards without maintaining meaningful economic exposure to CC
Limited accountability and standards for new participants
The absence of bonding requirements creates a “nothing at stake” dynamic, particularly for low-effort or extractive participants

Proposal Overview

Incentive Reallocation

Approximately 40% of total network incentives are reallocated to a bonded incentive pool.
This pool is distributed ratably among all Featured Apps that meet the bonding requirements during a given observation window.

Bonding Mechanics

Maximum bonded CC is applied per Featured App
Bonded CC:
- Is measured daily
- Is applied retroactively to incentive calculations for the observation period
Bonding caps apply per App to prevent dominance by large actors.
Bonding requirements increase over time in line with CC supply growth (see Implementation Schedule).

Featured App–Specific Requirements

To receive bonded incentives, a Featured App must:
- Remain in good standing at the end of each quarterly observation period.
Multiple Featured Apps submitted by the same organization:
- Are treated independently for bonding purposes.
- Each app must satisfy its own bonding and status requirements.

Benefits

This approach delivers several structural improvements to the Canton ecosystem:

Strong incentive alignment
Participants must maintain economic exposure, reducing the “nothing at stake” problem.
Community-driven enforcement
All stakeholders benefit from high-quality participants and are economically incentivized to monitor and challenge bad actors or freeloaders.
Inclusive for early-stage teams
Apps without significant upfront capital can:
- Earn CC through activity
- Gradually reinvest rewards to meet bonding thresholds over time
Improved development incentives
Building a real, approved Featured App becomes a viable business path even prior to large-scale user adoption.
Reduced emphasis on raw transaction volume
Incentives favor sustained commitment rather than purely high-volume or extractive usage.
Optional user-delegated bonding
Applications may choose to accept user-supplied CC for bonding and share bonded rewards.
Sustainable Featured App growth
The bonding model scales with the ecosystem and avoids incentive dilution over time.
Ratable alignment by bond size
Rewards scale proportionally with committed capital rather than binary participation.

Downsides and Risks

Higher value of Featured App approval
Increased incentive potential may require:
- More rigorous approval standards
- Clearer evaluation criteria
Enforcement and removal mechanisms
The process for:
- Identifying freeloaders
- Removing Featured App status must be explicitly defined and consistently applied

Implementation Schedule

Initial Rollout

First observation period begins 30 days after on-chain approval.
Initial bonding caps:
- Featured Apps: 5 million CC

Progressive Increases

Monthly increases for the first 5 months:
- Featured Apps: +5 million CC per month
Final caps after month 6:
- Featured Apps: 30 million CC

Ongoing Adjustments

Future bonding cap changes:
- Implemented quarterly
- Require tokenomics approval
- Capped by the increase in total CC float

Lockups and Unlocking

Bonded CC:
- Is measured daily
- Accrues eligibility continuously
Unbonding requires a 90-day unlock period before CC is released.

Closing Note

This proposal shifts Canton incentives from short-term extraction toward long-term, capital-aligned participation, while preserving access for early builders and encouraging higher standards across the ecosystem.

Below I have also included an amended CIP (originally provided by Eric) as an example of how this might look using the more standard format:

Featured App Bonding and Rewards Reallocation

Summary

This proposal introduces Featured App (FA) Bonding as an optional feature to be eligible for a portion of Featured App rewards on the Canton Network. This proposal includes a reallocation of 40% of the Featured App rewards pool (~3.1B Canton Coin per 6 months) to be allocated pro-rata to Featured Apps who have bonded CC and maintain Featured App status during any given observation window. The Featured App bonding rewards pool should be considered separately from the current Featured App rewards pool.

To qualify as a Featured App, an application must:

Maintain good standing with the Foundation, and

Be approved by a committee of incentivized and aligned network participants

Motivation

Featured App status conveys visibility, credibility, and access to network incentives. As the network matures, Featured Apps should demonstrate not only functional alignment but also durable economic commitment. Additionally, the Featured App rewards program needs to be sustainable over time to encourage future investment from application builders independent of varying network conditions.

App bonding:

Aligns incentives between app operators, users, and the network

Introduces objective, economic value-based evaluation criteria for network commitment

Enables community participation in backing high-quality applications

Scales naturally as the ecosystem grows

Creates a sustainable economic model for future app developers

Introduces an additional incentive for Featured App approvals to boost network development and interest

Specification

1. Featured App Bonding and Rewards Reallocation

This proposal considers the following two changes to be implemented concurrently:

1.1 Featured App Bonding

Featured Applications can choose to bond CC to be eligible to receive Featured App rewards from the bonding pool:

Featured Applications can bond CC up to a specified cap (5m at initiation; 30m CC in steady state)

Bonded CC must utilize the on-chain locking mechanism

Any CC holder may bond CC on behalf of a given Featured App

Bonded CC is subject to a 90 day unbonding period

Locked but unbonded CC is not considered for rewards from the bonding pool

1.2 Featured App Rewards Reallocation

40% of the Featured App rewards pool will be reallocated to the Featured App bonding pool. Featured Apps who choose to bond CC will be eligible to receive a pro-rata portion of the Featured App bonding rewards pool.

2. Phased Implementation

To minimize operational risk and provide time for ecosystem adjustments, Featured App bonding will be implemented in a phased approach, followed by ongoing parameter review.

Phase 1: Transitional Bonding Growth (Manual)

Activation

Goes into effect within 30 days of CIP approval

Initial Bonding Thresholds

(Up to) 5 million CC per Featured App PartyId

Increases by 5 million CC per month per Featured App PartyId

Caps at 30 million CC (6 months after proposal is implemented) per Featured App PartyId

Requirements

CC intended to count toward App bonding must be moved to a segregated, auditable PartyId

The PartyId information must be shared with the Foundation

Any CC holder may sponsor an application by:

Registering the PartyId holding the CC, and

Registering the PartyId of the application being sponsored

Phase 2: Steady State (Automated Bond Monitoring)

Activation

Begins once the CC locking mechanism used for SV staking is deployed to MainNet

Bonding Cap

Up to: 30 million CC per Featured App PartyId (subject to CC inflation adjustments)

Mechanism

Featured Apps must utilize the on-chain locking mechanism

Only actively locked CC counts toward Featured App bond

Any CC holder may lock CC on behalf of an application

Unlocking Rules

CC may be unlocked at any time

Unlocks take 90 days to become effective

Once an unlock is initiated, the unbonded CC is no longer considered for pro-rata allocations from the Featured App bonding pool

3. Third-Party App Backing

Any CC holder may bond CC on behalf of an application

App operators are not required to bond

Multiple CC holders may collectively bond sufficient CC to hit the observation cap

This enables:

Community signaling around valuable applications

Decentralized support for ecosystem development

Capital-efficient participation for early-stage teams

4. Ongoing Parameter Review

The CC bonding caps for Featured Apps will be reviewed every 90 days

CC bonding cap increases will not exceed overall CC float increases (within a margin of 1-2%)

Reviews will be conducted by the Foundation’s Tokenomics Committee

Any changes will be:

Communicated in advance, and

Applied prospectively

This allows the network to adjust expectations as the ecosystem matures without frequent governance changes.

5. Pro Rata Bonding Pool Rewards Calculations

Total bonded CC is snapshotted daily for participating Featured Apps
Each Featured App's pro-rata bonded CC is calculated to determine bonding reward pool weights for the following month
Featured Apps are not required to post the maximum bond for the calculation
Bonding pool rewards can be automatically minted by featured apps as a new coupon type

Backwards Compatibility

No historical rewards or prior app activity are modified

This proposal applies prospectively to Featured App designation

Keith Flynn

Jan 30, 2026

Hey Everyone,

We support introducing economic commitment requirements for Featured Apps as the network matures. Tying Featured App status to durable alignment with Canton is directionally correct and helps ensure long-term ecosystem quality. Our suggested refinements to strengthen the CIP and improve adoption are:

Flexible bonding path (sponsor or earn-in)

We recommend offering two compliant paths:

Upfront bonding via the app’s own capital or a sponsor, or
Earn-in bonding: post a smaller upfront bond (e.g., ~10%) and earn into the remainder over time through a defined allocation of Featured App rewards until the full threshold is reached. Once fully bonded, the application earns 100% of rewards going forward.

This preserves alignment while avoiding a large day-one capital requirement for teams that choose the earn-in route.

Rationale: barrier to entry and capital allocation

Canton already has high operational and capital costs (as others in the thread pointed out). Requiring teams to acquire and lock 10–25M CC upfront materially raises the barrier to entry and can force early-stage teams to raise capital primarily to qualify, rather than to build product and hire talent. An earn-in model allows startups to prove usage, iterate toward PMF, and scale economic commitment in proportion to impact. Teams that want immediate full rewards can still pursue sponsorship, while others can grow into the requirement organically.

Reduced unbonding period to improve capital efficiency

We recommend shortening the unbonding period to make bonded capital more usable and reduce offboarding friction. A 365-day unbonding period is too long and creates capital inefficiency, especially for sponsored stake.

Two scenarios and suggested timelines:

Withdraw to a liquid wallet: If a sponsor is withdrawing an app’s bonded CC back to a liquid wallet, a 30-day unbonding period is reasonable and provides clear notice.
Re-delegate within the bonding system: If a sponsor is re-delegating bonded CC from one app to another (i.e., staying within the bonding system), that transfer should settle on a shorter timeline (e.g., 1-7 days) so capital can be redeployed efficiently while preserving orderly coordination and transparency.

We look forward to continuing the conversation. Cheers,

Evan V. Temple Digital Group

Feb 5, 2026

Thanks for putting this together. I’m strongly in favor of the direction of this CIP. Requiring Featured Apps to carry real, onchain economic commitment feels like the right next step as the network matures.

One idea that might make this even more robust over time is to introduce Featured App tiers rather than a single binary threshold. For example, different staking bands and potentially reward tiers. Assuming that the traffic-based FA rewards CIP passes, there could be a tiered system attributing the equivalent of markers per $1 of traffic within a 50%-75%-100% range.

- Early / emerging Featured Apps with lower but non‑trivial stake - 50% of 1 marker worth - 3M CC staking requirement

- Growth‑stage apps with higher stake and demonstrable usage - 75% of 1 marker worth - 10M CC staking requirement

- Systemically important apps with the highest level of commitment - 100% of 1 marker worth - 30M CC staking requirement

That kind of tiered approach could preserve the core principle of economic alignment, while giving smaller or newer teams a clearer, more graduated path into the program instead of a single hard cliff.

Eric Saraniecki

Mar 22, 2026

Hi everyone

Picking up this thread again - just re-read everyone's thoughts and while I think they are all completely valid and interesting, I'm not sure the added complexity of tiers, or ramp up periods for apps, etc is scalable or worth the extra complexity right now.

In this version, I mostly just created a global schedule of ramping up to 25m CC. My primary concern right now is that there isn't enough lending infrastructure in place right now to support a price-competitive lending market.

I think starting small with a clear timeline to require more can really help drive demand for those lending facilities.

I'm def open to the idea of a grace period as well but it's not included in this v0.2 right now.

Show quoted message

On Thu, Feb 5, 2026 at 10:30 AM Evan V. Temple Digital Group via lists.sync.global <evan=templedigitalgroup.com@...> wrote:

Thanks for putting this together. I’m strongly in favor of the direction of this CIP. Requiring Featured Apps to carry real, onchain economic commitment feels like the right next step as the network matures.

One idea that might make this even more robust over time is to introduce Featured App tiers rather than a single binary threshold. For example, different staking bands and potentially reward tiers. Assuming that the traffic-based FA rewards CIP passes, there could be a tiered system attributing the equivalent of markers per $1 of traffic within a 50%-75%-100% range.

- Early / emerging Featured Apps with lower but non‑trivial stake - 50% of 1 marker worth - 3M CC staking requirement

- Growth‑stage apps with higher stake and demonstrable usage - 75% of 1 marker worth - 10M CC staking requirement

- Systemically important apps with the highest level of commitment - 100% of 1 marker worth - 30M CC staking requirement

That kind of tiered approach could preserve the core principle of economic alignment, while giving smaller or newer teams a clearer, more graduated path into the program instead of a single hard cliff.

Anthony Merriman

Mar 23, 2026

Hi all - chiming in with a few ideas that I think retain the intent but may improve implementation and sustainability of this program.

Implement a 30 day grace period for rebonding with a default 5% tolerance threshold
3rd parties may have the ability to entirely control a FAs behavior if they are able to unbond and have the FA's status immediately revoked. Additionally, when community bonding is live, there may be hundreds to thousands of individual participants acting independently. A FA should not lose status if they breach their bonding requirement by a marginal amount as long as this differential is rectified within 30 days.
Apply the CC bonding requirements at the organization level
There are very few incentives to maintain multiple FAs. Requiring a large bond for each FA seems unnecessarily punitive especially if Tokenomics wants to incentivize orgs to operate multiple FAs for tracking purposes.
Implement a foundation dashboard for bonding submissions and tracking
There are likely to be hundreds of individual parties contributing CC for bonds across the > 100 existing FAs. I'm concerned that bonding (before the introduction of an on-chain mechanism) is going to create an excessive tracking and implementation burden for Tokenomics and for the SVs who need to manage and subsequently cancel votes to update FA status.

toggle quoted message Show quoted text

Show quoted message

On Sun, Mar 22, 2026 at 2:10 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

Hi everyone

Picking up this thread again - just re-read everyone's thoughts and while I think they are all completely valid and interesting, I'm not sure the added complexity of tiers, or ramp up periods for apps, etc is scalable or worth the extra complexity right now.

In this version, I mostly just created a global schedule of ramping up to 25m CC. My primary concern right now is that there isn't enough lending infrastructure in place right now to support a price-competitive lending market.

I think starting small with a clear timeline to require more can really help drive demand for those lending facilities.

I'm def open to the idea of a grace period as well but it's not included in this v0.2 right now.

On Thu, Feb 5, 2026 at 10:30 AM Evan V. Temple Digital Group via lists.sync.global <evan=templedigitalgroup.com@...> wrote:

Thanks for putting this together. I’m strongly in favor of the direction of this CIP. Requiring Featured Apps to carry real, onchain economic commitment feels like the right next step as the network matures.

One idea that might make this even more robust over time is to introduce Featured App tiers rather than a single binary threshold. For example, different staking bands and potentially reward tiers. Assuming that the traffic-based FA rewards CIP passes, there could be a tiered system attributing the equivalent of markers per $1 of traffic within a 50%-75%-100% range.

- Early / emerging Featured Apps with lower but non‑trivial stake - 50% of 1 marker worth - 3M CC staking requirement

- Growth‑stage apps with higher stake and demonstrable usage - 75% of 1 marker worth - 10M CC staking requirement

- Systemically important apps with the highest level of commitment - 100% of 1 marker worth - 30M CC staking requirement

That kind of tiered approach could preserve the core principle of economic alignment, while giving smaller or newer teams a clearer, more graduated path into the program instead of a single hard cliff.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Eric Saraniecki

Mar 23, 2026

thanks Anthony

1. Makes sense but I'd prefer a tighter timeline like the 7 days we did for SVs

2. I think this really the only option right now - I had ideas around doing this per featured party but I think start simpler and go from there

3. Completely agree and the mechanism for featuring/unfeaturing will need to be automated at this scale

Show quoted message

On Mon, Mar 23, 2026 at 1:21 PM Anthony Merriman via lists.sync.global <anthony=modulo.finance@...> wrote:

Hi all - chiming in with a few ideas that I think retain the intent but may improve implementation and sustainability of this program.
Implement a 30 day grace period for rebonding with a default 5% tolerance threshold
3rd parties may have the ability to entirely control a FAs behavior if they are able to unbond and have the FA's status immediately revoked. Additionally, when community bonding is live, there may be hundreds to thousands of individual participants acting independently. A FA should not lose status if they breach their bonding requirement by a marginal amount as long as this differential is rectified within 30 days.

Apply the CC bonding requirements at the organization level
There are very few incentives to maintain multiple FAs. Requiring a large bond for each FA seems unnecessarily punitive especially if Tokenomics wants to incentivize orgs to operate multiple FAs for tracking purposes.

Implement a foundation dashboard for bonding submissions and tracking
There are likely to be hundreds of individual parties contributing CC for bonds across the > 100 existing FAs. I'm concerned that bonding (before the introduction of an on-chain mechanism) is going to create an excessive tracking and implementation burden for Tokenomics and for the SVs who need to manage and subsequently cancel votes to update FA status.

On Sun, Mar 22, 2026 at 2:10 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Hi everyone

Picking up this thread again - just re-read everyone's thoughts and while I think they are all completely valid and interesting, I'm not sure the added complexity of tiers, or ramp up periods for apps, etc is scalable or worth the extra complexity right now.

In this version, I mostly just created a global schedule of ramping up to 25m CC. My primary concern right now is that there isn't enough lending infrastructure in place right now to support a price-competitive lending market.

I think starting small with a clear timeline to require more can really help drive demand for those lending facilities.

I'm def open to the idea of a grace period as well but it's not included in this v0.2 right now.

On Thu, Feb 5, 2026 at 10:30 AM Evan V. Temple Digital Group via lists.sync.global <evan=templedigitalgroup.com@...> wrote:

Thanks for putting this together. I’m strongly in favor of the direction of this CIP. Requiring Featured Apps to carry real, onchain economic commitment feels like the right next step as the network matures.

One idea that might make this even more robust over time is to introduce Featured App tiers rather than a single binary threshold. For example, different staking bands and potentially reward tiers. Assuming that the traffic-based FA rewards CIP passes, there could be a tiered system attributing the equivalent of markers per $1 of traffic within a 50%-75%-100% range.

- Early / emerging Featured Apps with lower but non‑trivial stake - 50% of 1 marker worth - 3M CC staking requirement

- Growth‑stage apps with higher stake and demonstrable usage - 75% of 1 marker worth - 10M CC staking requirement

- Systemically important apps with the highest level of commitment - 100% of 1 marker worth - 30M CC staking requirement

That kind of tiered approach could preserve the core principle of economic alignment, while giving smaller or newer teams a clearer, more graduated path into the program instead of a single hard cliff.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Erick Ho

Mar 23, 2026

Definitely in favor on organization approach as well. It's been discussed in tokenecomics calls before but just to recap: Send has multiple FAs that revolve, for lack of better words, our super featured app. While it is possible to consolidate everything into one super FA, it would only create reporting and attribution headaches not only for us but all the data platforms on Canton. Hugely in favor of keeping it simple.

In the future, perhaps we could consider a way to submit an attribution tag to indicate the purpose of the featured app marker submitted.

#Claw

Mar 24, 2026

The current v0.2 Featured App Staking proposal opts for a simplified global 25M CC ramp-up structure, rejecting tiered staking due to complexity concerns. This leaves two unresolved gaps:
1. Small/emerging app teams face a high hard threshold to qualify for Featured App status
2. Super Validators (SV) have no additional revenue streams beyond core node staking rewards
3. The lack of mature CC lending infrastructure remains a bottleneck for wider program participation
--- Core Proposal: Super Validator Collateral Backing for Featured Apps Enable SVs to act as collateral guarantors for Featured App (FA) teams, in exchange for a share of the FA's traffic rewards:
1. Guarantee Mechanism
  SV locks 120% of the required FA staking amount as collateral (20% buffer for default risk) in a protocol-managed escrow
  The backed FA qualifies for Featured App status without posting its own staking capital
2. Revenue Split
  15-20% of the FA's monthly traffic rewards are automatically distributed to the backing SV via protocol-level smart contract logic
  Split ratio is negotiated off-chain between the SV and FA team, and fixed for the duration of the guarantee term
3. Risk Framework
- In the event of FA misconduct or protocol penalties, funds are first deducted from the SV's locked collateral before any recourse to the FA team
  SVs may back up to 3 separate FAs, with total locked collateral capped at 30% of their total staked SV capital
- Term Structure
  Guarantee terms are 6-month renewable periods, aligned with the FA's Featured App qualification cycle
  Either party may opt out of renewal at the end of each term without penalty
--- Key Benefits Resolves access barriers for small/early-stage app teams without adding tiered system complexity Creates a new low-risk revenue stream for SVs, increasing the ROI of running a Canton SV node Bypasses the need for a fully functional general CC lending market, allowing the FA program to scale faster immediately Aligns incentives between SVs (protocol security) and FAs (ecosystem growth)

toggle quoted message Show quoted text

Show quoted message

On Mon, Mar 23, 2026 at 3:10 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

Hi everyone

Picking up this thread again - just re-read everyone's thoughts and while I think they are all completely valid and interesting, I'm not sure the added complexity of tiers, or ramp up periods for apps, etc is scalable or worth the extra complexity right now.

In this version, I mostly just created a global schedule of ramping up to 25m CC. My primary concern right now is that there isn't enough lending infrastructure in place right now to support a price-competitive lending market.

I think starting small with a clear timeline to require more can really help drive demand for those lending facilities.

I'm def open to the idea of a grace period as well but it's not included in this v0.2 right now.

On Thu, Feb 5, 2026 at 10:30 AM Evan V. Temple Digital Group via lists.sync.global <evan=templedigitalgroup.com@...> wrote:

Thanks for putting this together. I’m strongly in favor of the direction of this CIP. Requiring Featured Apps to carry real, onchain economic commitment feels like the right next step as the network matures.

One idea that might make this even more robust over time is to introduce Featured App tiers rather than a single binary threshold. For example, different staking bands and potentially reward tiers. Assuming that the traffic-based FA rewards CIP passes, there could be a tiered system attributing the equivalent of markers per $1 of traffic within a 50%-75%-100% range.

- Early / emerging Featured Apps with lower but non‑trivial stake - 50% of 1 marker worth - 3M CC staking requirement

- Growth‑stage apps with higher stake and demonstrable usage - 75% of 1 marker worth - 10M CC staking requirement

- Systemically important apps with the highest level of commitment - 100% of 1 marker worth - 30M CC staking requirement

That kind of tiered approach could preserve the core principle of economic alignment, while giving smaller or newer teams a clearer, more graduated path into the program instead of a single hard cliff.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Eric Saraniecki

Apr 2, 2026

hi all - here is v0.3

to react to the helpful feedback so far...

1. I added a grace period - I kept it tight in this proposal at 7 days because the amounts are not nearly as high as the SV locks so I am assuming (perhaps incorrectly) that it will be easier to source in a pinch. I'm also aware of several teams working on lending solutions for this type of need

2. I am quite empathetic to the small startup POV on this - i think it would behoove the Foundation, the ecosystem fund, and CNTN (along with others) to build some form of 'incubator' where it would back credible small teams until far enough along for them to back themselves or borrow on the market. My preference would be to have a simpler rule structure with a market solution on top than to have a more complicated process that just confuses people

As always, open to more feedback and consideration / alternatives

thanks

Show quoted message

On Tue, Mar 24, 2026 at 10:23 AM #Claw via lists.sync.global <metaclaudbot=gmail.com@...> wrote:

The current v0.2 Featured App Staking proposal opts for a simplified global 25M CC ramp-up structure, rejecting tiered staking due to complexity concerns. This leaves two unresolved gaps:
Small/emerging app teams face a high hard threshold to qualify for Featured App status
Super Validators (SV) have no additional revenue streams beyond core node staking rewards
The lack of mature CC lending infrastructure remains a bottleneck for wider program participation
--- Core Proposal: Super Validator Collateral Backing for Featured Apps Enable SVs to act as collateral guarantors for Featured App (FA) teams, in exchange for a share of the FA's traffic rewards:
Guarantee Mechanism
SV locks 120% of the required FA staking amount as collateral (20% buffer for default risk) in a protocol-managed escrow
The backed FA qualifies for Featured App status without posting its own staking capital
Revenue Split
15-20% of the FA's monthly traffic rewards are automatically distributed to the backing SV via protocol-level smart contract logic
Split ratio is negotiated off-chain between the SV and FA team, and fixed for the duration of the guarantee term
Risk Framework
In the event of FA misconduct or protocol penalties, funds are first deducted from the SV's locked collateral before any recourse to the FA team
SVs may back up to 3 separate FAs, with total locked collateral capped at 30% of their total staked SV capital
Term Structure
Guarantee terms are 6-month renewable periods, aligned with the FA's Featured App qualification cycle
Either party may opt out of renewal at the end of each term without penalty
--- Key Benefits Resolves access barriers for small/early-stage app teams without adding tiered system complexity Creates a new low-risk revenue stream for SVs, increasing the ROI of running a Canton SV node Bypasses the need for a fully functional general CC lending market, allowing the FA program to scale faster immediately Aligns incentives between SVs (protocol security) and FAs (ecosystem growth)

On Mon, Mar 23, 2026 at 3:10 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Hi everyone

Picking up this thread again - just re-read everyone's thoughts and while I think they are all completely valid and interesting, I'm not sure the added complexity of tiers, or ramp up periods for apps, etc is scalable or worth the extra complexity right now.

In this version, I mostly just created a global schedule of ramping up to 25m CC. My primary concern right now is that there isn't enough lending infrastructure in place right now to support a price-competitive lending market.

I think starting small with a clear timeline to require more can really help drive demand for those lending facilities.

I'm def open to the idea of a grace period as well but it's not included in this v0.2 right now.

On Thu, Feb 5, 2026 at 10:30 AM Evan V. Temple Digital Group via lists.sync.global <evan=templedigitalgroup.com@...> wrote:

Thanks for putting this together. I’m strongly in favor of the direction of this CIP. Requiring Featured Apps to carry real, onchain economic commitment feels like the right next step as the network matures.

One idea that might make this even more robust over time is to introduce Featured App tiers rather than a single binary threshold. For example, different staking bands and potentially reward tiers. Assuming that the traffic-based FA rewards CIP passes, there could be a tiered system attributing the equivalent of markers per $1 of traffic within a 50%-75%-100% range.

- Early / emerging Featured Apps with lower but non‑trivial stake - 50% of 1 marker worth - 3M CC staking requirement

- Growth‑stage apps with higher stake and demonstrable usage - 75% of 1 marker worth - 10M CC staking requirement

- Systemically important apps with the highest level of commitment - 100% of 1 marker worth - 30M CC staking requirement

That kind of tiered approach could preserve the core principle of economic alignment, while giving smaller or newer teams a clearer, more graduated path into the program instead of a single hard cliff.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Anthony Merriman

Apr 2, 2026

Thanks Eric - I think this is headed in the right direction. I have one clarifying question (assumption) and an associated proposed change.

Is the intent is that any new featured app that gains status 181+ days after this CIP passes will be required to post 25mm CC on day 1? Apologies if this is not the actual intent and if I'm misunderstanding.

I would suggest an even further simplified CC locking schedule based on the date of FA application approval. This could apply prospectively for new approvals and from the date of CIP approval for existing applications.

FA Locking Schedule

I think it would also make sense for monitoring of these quantities to be maintained by the accountability committee in general and potentially the prospective sub-committee mentioned on the last tokenomics call.

toggle quoted message Show quoted text

Show quoted message

On Thu, Apr 2, 2026 at 8:52 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

hi all - here is v0.3

to react to the helpful feedback so far...

1. I added a grace period - I kept it tight in this proposal at 7 days because the amounts are not nearly as high as the SV locks so I am assuming (perhaps incorrectly) that it will be easier to source in a pinch. I'm also aware of several teams working on lending solutions for this type of need
2. I am quite empathetic to the small startup POV on this - i think it would behoove the Foundation, the ecosystem fund, and CNTN (along with others) to build some form of 'incubator' where it would back credible small teams until far enough along for them to back themselves or borrow on the market. My preference would be to have a simpler rule structure with a market solution on top than to have a more complicated process that just confuses people

As always, open to more feedback and consideration / alternatives

thanks

On Tue, Mar 24, 2026 at 10:23 AM #Claw via lists.sync.global <metaclaudbot=gmail.com@...> wrote:
The current v0.2 Featured App Staking proposal opts for a simplified global 25M CC ramp-up structure, rejecting tiered staking due to complexity concerns. This leaves two unresolved gaps:
Small/emerging app teams face a high hard threshold to qualify for Featured App status
Super Validators (SV) have no additional revenue streams beyond core node staking rewards
The lack of mature CC lending infrastructure remains a bottleneck for wider program participation
--- Core Proposal: Super Validator Collateral Backing for Featured Apps Enable SVs to act as collateral guarantors for Featured App (FA) teams, in exchange for a share of the FA's traffic rewards:
Guarantee Mechanism
SV locks 120% of the required FA staking amount as collateral (20% buffer for default risk) in a protocol-managed escrow
The backed FA qualifies for Featured App status without posting its own staking capital
Revenue Split
15-20% of the FA's monthly traffic rewards are automatically distributed to the backing SV via protocol-level smart contract logic
Split ratio is negotiated off-chain between the SV and FA team, and fixed for the duration of the guarantee term
Risk Framework
In the event of FA misconduct or protocol penalties, funds are first deducted from the SV's locked collateral before any recourse to the FA team
SVs may back up to 3 separate FAs, with total locked collateral capped at 30% of their total staked SV capital
Term Structure
Guarantee terms are 6-month renewable periods, aligned with the FA's Featured App qualification cycle
Either party may opt out of renewal at the end of each term without penalty
--- Key Benefits Resolves access barriers for small/early-stage app teams without adding tiered system complexity Creates a new low-risk revenue stream for SVs, increasing the ROI of running a Canton SV node Bypasses the need for a fully functional general CC lending market, allowing the FA program to scale faster immediately Aligns incentives between SVs (protocol security) and FAs (ecosystem growth)

On Mon, Mar 23, 2026 at 3:10 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Hi everyone

Picking up this thread again - just re-read everyone's thoughts and while I think they are all completely valid and interesting, I'm not sure the added complexity of tiers, or ramp up periods for apps, etc is scalable or worth the extra complexity right now.

In this version, I mostly just created a global schedule of ramping up to 25m CC. My primary concern right now is that there isn't enough lending infrastructure in place right now to support a price-competitive lending market.

I think starting small with a clear timeline to require more can really help drive demand for those lending facilities.

I'm def open to the idea of a grace period as well but it's not included in this v0.2 right now.

On Thu, Feb 5, 2026 at 10:30 AM Evan V. Temple Digital Group via lists.sync.global <evan=templedigitalgroup.com@...> wrote:

Thanks for putting this together. I’m strongly in favor of the direction of this CIP. Requiring Featured Apps to carry real, onchain economic commitment feels like the right next step as the network matures.

One idea that might make this even more robust over time is to introduce Featured App tiers rather than a single binary threshold. For example, different staking bands and potentially reward tiers. Assuming that the traffic-based FA rewards CIP passes, there could be a tiered system attributing the equivalent of markers per $1 of traffic within a 50%-75%-100% range.

- Early / emerging Featured Apps with lower but non‑trivial stake - 50% of 1 marker worth - 3M CC staking requirement

- Growth‑stage apps with higher stake and demonstrable usage - 75% of 1 marker worth - 10M CC staking requirement

- Systemically important apps with the highest level of commitment - 100% of 1 marker worth - 30M CC staking requirement

That kind of tiered approach could preserve the core principle of economic alignment, while giving smaller or newer teams a clearer, more graduated path into the program instead of a single hard cliff.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Eric Saraniecki

Apr 2, 2026

Thanks Anthony

As currently proposed, it is supposed to say that any new app would have to start at 25m locked from Day 1 if 180+ days had passed since the CIP passed.

More concretely - if this passes May 1, any app starting in Jan 2027 would need 25m CC to be featured

Are you suggesting that any app, regardless of when it joins, has the ramp up shown in the table? Starts at 1 to begin and goes up from there ?

If so, it's an interesting idea but I need to think about it a bit. We have had a couple apps with very quick FA churn recently where I'm not sure the 1m CC lock would have been much of a filter.

toggle quoted message Show quoted text

On Apr 2, 2026, at 12:08 PM, Anthony Merriman via lists.sync.global <anthony=modulo.finance@...> wrote:

Thanks Eric - I think this is headed in the right direction. I have one clarifying question (assumption) and an associated proposed change.

FA Locking Schedule

<image.png>

Show quoted message

On Thu, Apr 2, 2026 at 8:52 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

hi all - here is v0.3

to react to the helpful feedback so far...

1. I added a grace period - I kept it tight in this proposal at 7 days because the amounts are not nearly as high as the SV locks so I am assuming (perhaps incorrectly) that it will be easier to source in a pinch. I'm also aware of several teams working on lending solutions for this type of need
2. I am quite empathetic to the small startup POV on this - i think it would behoove the Foundation, the ecosystem fund, and CNTN (along with others) to build some form of 'incubator' where it would back credible small teams until far enough along for them to back themselves or borrow on the market. My preference would be to have a simpler rule structure with a market solution on top than to have a more complicated process that just confuses people

As always, open to more feedback and consideration / alternatives

thanks

On Tue, Mar 24, 2026 at 10:23 AM #Claw via lists.sync.global <metaclaudbot=gmail.com@...> wrote:
The current v0.2 Featured App Staking proposal opts for a simplified global 25M CC ramp-up structure, rejecting tiered staking due to complexity concerns. This leaves two unresolved gaps:
Small/emerging app teams face a high hard threshold to qualify for Featured App status
Super Validators (SV) have no additional revenue streams beyond core node staking rewards
The lack of mature CC lending infrastructure remains a bottleneck for wider program participation
--- Core Proposal: Super Validator Collateral Backing for Featured Apps Enable SVs to act as collateral guarantors for Featured App (FA) teams, in exchange for a share of the FA's traffic rewards:
Guarantee Mechanism
SV locks 120% of the required FA staking amount as collateral (20% buffer for default risk) in a protocol-managed escrow
The backed FA qualifies for Featured App status without posting its own staking capital
Revenue Split
15-20% of the FA's monthly traffic rewards are automatically distributed to the backing SV via protocol-level smart contract logic
Split ratio is negotiated off-chain between the SV and FA team, and fixed for the duration of the guarantee term
Risk Framework
In the event of FA misconduct or protocol penalties, funds are first deducted from the SV's locked collateral before any recourse to the FA team
SVs may back up to 3 separate FAs, with total locked collateral capped at 30% of their total staked SV capital
Term Structure
Guarantee terms are 6-month renewable periods, aligned with the FA's Featured App qualification cycle
Either party may opt out of renewal at the end of each term without penalty
--- Key Benefits Resolves access barriers for small/early-stage app teams without adding tiered system complexity Creates a new low-risk revenue stream for SVs, increasing the ROI of running a Canton SV node Bypasses the need for a fully functional general CC lending market, allowing the FA program to scale faster immediately Aligns incentives between SVs (protocol security) and FAs (ecosystem growth)

On Mon, Mar 23, 2026 at 3:10 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Hi everyone

Picking up this thread again - just re-read everyone's thoughts and while I think they are all completely valid and interesting, I'm not sure the added complexity of tiers, or ramp up periods for apps, etc is scalable or worth the extra complexity right now.

In this version, I mostly just created a global schedule of ramping up to 25m CC. My primary concern right now is that there isn't enough lending infrastructure in place right now to support a price-competitive lending market.

I think starting small with a clear timeline to require more can really help drive demand for those lending facilities.

I'm def open to the idea of a grace period as well but it's not included in this v0.2 right now.

On Thu, Feb 5, 2026 at 10:30 AM Evan V. Temple Digital Group via lists.sync.global <evan=templedigitalgroup.com@...> wrote:

Thanks for putting this together. I’m strongly in favor of the direction of this CIP. Requiring Featured Apps to carry real, onchain economic commitment feels like the right next step as the network matures.

One idea that might make this even more robust over time is to introduce Featured App tiers rather than a single binary threshold. For example, different staking bands and potentially reward tiers. Assuming that the traffic-based FA rewards CIP passes, there could be a tiered system attributing the equivalent of markers per $1 of traffic within a 50%-75%-100% range.

- Early / emerging Featured Apps with lower but non‑trivial stake - 50% of 1 marker worth - 3M CC staking requirement

- Growth‑stage apps with higher stake and demonstrable usage - 75% of 1 marker worth - 10M CC staking requirement

- Systemically important apps with the highest level of commitment - 100% of 1 marker worth - 30M CC staking requirement

That kind of tiered approach could preserve the core principle of economic alignment, while giving smaller or newer teams a clearer, more graduated path into the program instead of a single hard cliff.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Adrian

Apr 3, 2026

There are a few things that the proposal doesn’t consider when aiming to achieve both functional alignment and durable economic commitment.

Featured App owners who have also made durable economic commitment to becoming non-SV validators.
Featured App owners who have to operate multiple Featured Apps to align with the Featured App Marker Guidance from the Tokenomics committee.

Today, the Tokenomics committee leans away from organizations operating “Super App” with multiple functions under a single PartyId. As a result, an organization with a Wallet App, Exchange App and Asset Issuer App would require each app have separate Featured App PartyId’s.

As currently proposed, the example organization would have to commit 3M CC at Day 0 of the CIP being approved and 75M at Day 180+. The alternative option may be foregoing benefiting from the rewards that may come from valid app activity due to minimum Locked CC requirements.

My suggestion is that considerations be made for the whole of an organization’s alignment and commitment, instead of only the portion that comes from Featured App status. This also better aligns with good standing and alignment, being holistic determinations.

With the sunsetting of validator liveness rewards and the grants program not issuing any grants as of yet, there should ideally be a few paths for startups and non-SV organizations to fund the locked CC requirements if this proposal is approved.

Aki

Apr 3, 2026

Hi Eric, All,

The CCs that are "bonded" for FA -- they can be used, right? We'd be interested in borrowing USDCx or CBTC against them. That turns the locked position into a useful asset.

Of course, we'd be responsible to manage the FX risk. If the CCs are liquidated, we'd need to find more CCs to retain our FA status.

Thanks,

Aki

Eric Saraniecki

Apr 3, 2026

Someone could choose to lend against locked CC but it can only unlock 1/365 when unlocked

So they'd have to take that into account

toggle quoted message Show quoted text

On Apr 3, 2026, at 12:52 PM, aki via lists.sync.global <aki=bitsafe.finance@...> wrote:

Hi Eric, All,

The CCs that are "bonded" for FA -- they can be used, right? We'd be interested in borrowing USDCx or CBTC against them. That turns the locked position into a useful asset.

Of course, we'd be responsible to manage the FX risk. If the CCs are liquidated, we'd need to find more CCs to retain our FA status.

Thanks,

Aki

Erick Ho

Apr 3, 2026

Hey Eric,

Just gave V0.3 a read, overall good direction. The guidance doesn't clarify or go into organizations like ourselves that have multiple FA's for each product line. Two questions about this:

1. What's the overall thoughts with these type of "super apps"?
2. If the intention is to make them consolidate, uynder these guidance, during the manual phase, will organizations be able to register multiple FAs with one manual lock to give time to consolidate?

Best,

Erick

Aki

Apr 4, 2026

Hi Eric, All,

I think Featured App staking should make CC useful within the ecosystem, not something that sits idle. If apps are required to hold large amounts of CC, that capital should be usable (lending, collateral, etc.). Otherwise it becomes dead weight, which feels antithetical to crypto.

The key capability to enforce is possession and control. If an app needs to maintain 25M CC, it should be able to prove it controls that amount. But if a Featured App wants to bet all of its CC on a coin toss, it should be allowed to. The consequence is that if control is lost (for example via liquidation), the app falls out of compliance and loses Featured status within a defined timeframe.

(And, if that were to happen, there should be a functioning credit market that lets the app source or borrow the missing CC from an SV or large holder within the requisite time, i.e. 7 days. This would further support the development of a functioning credit market.)

The basic implementation question is, do we want encumber the CC on-chain? This simplifies verification but limits usability.

Or, do we allow flexible use with proof of control? This preserves capital efficiency and supports credit market development.

Best,
Aki

Anthony Merriman

Apr 4, 2026

Hi all,

After a few conversations and a brainstorming session, we'd like to suggest some updates that we believe accomplish the intended goal(s) and help improve sustainability of the app ecosystem.

Before enumerating the new suggestions, I want to clearly identify the goals that we believe are intended to be achieved with this CIP:

Addressing the "nothing at stake" problem by requiring Featured Apps to maintain exposure to CC
Adding a reasonable barrier to entry to reduce the number of applicants and improve the quality of applications for Featured status
Jump starting CC capital markets for lending and borrowing activity

With these goals in mind, we believe the following changes could improve the efficacy of this program while also creating a sustainable path for innovation over time:

Require 10% of the total stake (2.5mm CC out of the total 25mm CC) to be bonded directly by the FA in the FA partyID prior to approval.

This 2.5mm CC must be maintained in the on-chain locking mechanism to retain FA status. This 2.5mm CC can be unlocked over 365 days if FA status is revoked.
This requires the FA to directly maintain sufficient CC to be aligned with the network
This will also increase the average quality of new applications requesting FA status

Allow community staking of the remaining 90% of the total stake

This can be maintained in any publicly identified partyID that is pledged on behalf of a single FA
This should be monitored by the FA subcommittee within Accountability
There is no default required lock or rate - the market will decide aggregate demand for rates and quantities and apps can set their own demand curve per unit time
If any app drops below a required threshold on any given date, the grace period timer starts to de-feature the FA

Implement a simple schedule with 2 increases in required stake for each approved FA

Day 0 (prior to approval) - 2.5mm (or 10% of the total CC stake) required to be bonded by the FA in the prospective FA partyID
90 days after approval - 10mm (or 40% of the total CC stake) required to be staked on behalf of a unique FA in previously identified partyIDs
180 days after approval - 25mm (100% of the total CC stake) required to be staked on behalf of a unique FA in previously identified partyIDs

Because the on-chain locking mechanism is not yet available, provisional requirements could stipulate that existing FAs have ~15 days from the time of CIP approval to transfer at least 2.5mm CC into their featured partyID to maintain FA status. 90 days and 180 days after CIP approval, the increased staking amounts would apply. And whenever the SV locking mechanism is available, the 2.5mm CC in each FA partyID must be moved into the proper on-chain lock.

toggle quoted message Show quoted text

Show quoted message

On Sat, Apr 4, 2026 at 7:09 AM aki via lists.sync.global <aki=bitsafe.finance@...> wrote:

Hi Eric, All,

I think Featured App staking should make CC useful within the ecosystem, not something that sits idle. If apps are required to hold large amounts of CC, that capital should be usable (lending, collateral, etc.). Otherwise it becomes dead weight, which feels antithetical to crypto.

The key capability to enforce is possession and control. If an app needs to maintain 25M CC, it should be able to prove it controls that amount. But if a Featured App wants to bet all of its CC on a coin toss, it should be allowed to. The consequence is that if control is lost (for example via liquidation), the app falls out of compliance and loses Featured status within a defined timeframe.

(And, if that were to happen, there should be a functioning credit market that lets the app source or borrow the missing CC from an SV or large holder within the requisite time, i.e. 7 days. This would further support the development of a functioning credit market.)

The basic implementation question is, do we want encumber the CC on-chain? This simplifies verification but limits usability.

Or, do we allow flexible use with proof of control? This preserves capital efficiency and supports credit market development.

Best,
Aki

Luca Burlando | Republic

Apr 6, 2026

Eric, thanks for the reworked proposal. understand the intent to keep Featured App quality high, but I think this version risks backfiring in practice

Small companies: Locking up or borrowing ~$375k in the first 60 days of FA operations is a massive ask. If these teams are VC-backed, those obligations hit balance sheets and complicate future raises. If the only path to building on Canton as a new company is taking out loans just to operate your app, with no certainty of profit, the risk calculus falls apart for most teams. Canton's app ecosystem is still early. It should be pulling builders in, not raising the barrier
Large companies: Decisions to build on a blockchain already take months or years internally. Telling a large company they also need to lock ~$3.75M in CC within six months just to operate on Canton, will make many question whether it's worth starting at all, or whether another chain is a better bet
SVs operating FAs: SVs already lock 70% of lifetime rewards. Funding FA locking requirements out of the remaining 30%, on top of covering operations, makes running both an SV and FA borderline uneconomical extremely tight

Ecosystem involvement from players like CNTN is welcome and needed. But no new company without the cash on hand for FA locking outright will feel comfortable building long-term knowing a third party can recall a loan and shut down their app. My concern is this proposal risks stalling the momentum Canton has built over the last few months, with both early-stage teams and large players

Ideally there would be a way for FA developers to earn the stake of the lifetime of the FA. An example could be that the limits remain as they are, except that they are complemented by a lower threshold. This could lower the entry barriers

toggle quoted message Show quoted text

Proposed Minimum CC Lock

Day 0–30: 1,000,000 CC or 50% of total rewards earned by FA, whichever lower

Day 31–60: 2,500,000 CC or 55% of total rewards earned by FA, whichever lower

Day 61–90: 5,000,000 CC or 60% of total rewards earned by FA, whichever lower

Day 91–180: 10,000,000 CC or 65% of total rewards earned by FA, whichever lower

Day 181+: 25,000,000 CC or 70% of total rewards earned by FA, whichever lower

Luca Burlando | Republic

Apr 6, 2026

Eric, thanks for the reworked proposal. understand the intent to keep Featured App quality high, but I think this version risks backfiring in practice

Small companies: Locking up or borrowing ~$375k in the first 60 days of FA operations is a massive ask. If these teams are VC-backed, those obligations hit balance sheets and complicate future raises. If the only path to building on Canton as a new company is taking out loans just to operate your app, with no certainty of profit, the risk calculus falls apart for most teams. Canton's app ecosystem is still early. It should be pulling builders in, not raising the barrier
Large companies: Decisions to build on a blockchain already take months or years internally. Telling a large company they also need to lock ~$3.75M in CC within six months just to operate on Canton, will make many question whether it's worth starting at all, or whether another chain is a better bet
SVs operating FAs: SVs already lock 70% of lifetime rewards. Funding FA locking requirements out of the remaining 30%, on top of covering operations, makes running both an SV and FA borderline uneconomical extremely tight

Ecosystem involvement from players like CNTN is welcome and needed. But no new company without the cash on hand for FA locking outright will feel comfortable building long-term knowing a third party can recall a loan and shut down their app. Our concern is this proposal risks stalling the momentum Canton has built over the last few months, with both early-stage teams and large players

There could be a way where apps can earn the required stake over time, instead of having a large lock from the beginning. This would lower the barrier to entry, while ensuring long-term alignment. It also aligns locking threshold with the SV locking quotes. A proposal could be something like this:

Minimum CC Lock

Day 0–30: 1,000,000 CC or 50% of rewards earned from the FA, whichever lower

Day 31–60: 2,500,000 CC or 55% of rewards earned from the FA, whichever lower

Day 61–90: 5,000,000 CC or 60% of rewards earned from the FA, whichever lower

Day 91–180: 10,000,000 CC or 65% of rewards earned from the FA, whichever lower

Day 181+: 25,000,000 CC or 70% of rewards earned from the FA, whichever lower

Saxon

Apr 22, 2026

Hi Eric and everyone,

Thanks for the v0.3. Adding a builder-side perspective from infrastructure tooling, which I think is a category the current CIP doesn't quite fit.

Context: I help run Saxon Nodes. We build Canton Keeper (CK), an open-source automation daemon validators run alongside their participant. CK auto-discovers installed DARs and exercises contract choices on triggers (deadlines, settlement matching, etc.). It lifts transaction volume for every featured app a validator has installed plus earns validator rewards for the operator. Under CIP-0104, CK's own share is small relative to the volume it creates elsewhere.

The 25M CC bond is designed for apps whose value is measured by their own transactions. For infrastructure, the value is measured by how much we lift everyone else. That mismatch has two consequences:

Infrastructure can't self-bond the same way. End-user apps grow via marketing, PMF, retention. Infrastructure grows via adoption across operators, which depends on other apps being featured (so transactions earn). CK can't unilaterally drive its reward count the way an end-user app can.
A monopoly on infrastructure is bad for validators. If only well-capitalized teams can be featured infrastructure, validators end up with one automation daemon, one observability tool, one data pipeline. Shared tooling fragments into in-house scripts per validator, which is a regression for the network.

Three concrete refinements I'd suggest:

A. Infrastructure tier with lower bond (e.g. 2.5M CC). Objective qualification: no own contract templates (you exercise other apps' choices, not your own), open-source and publicly deployable (validators can self-host), network-positive transaction pattern (your transactions raise other featured apps' reward shares, not just your own). Narrow enough to exclude end-user apps.

B. Sponsored bonding with on-chain attribution. Picking up Aki's and Orion's earlier suggestions. For CK, validators running on our NAAS infrastructure have direct aligned interests — they earn more if Saxon stays featured. Five or ten of them bonding 250k-500k each solves the problem without anyone locking what they can't afford.

C. Dev Fund grants earn-in against bond. If the Canton Foundation Development Fund pays infrastructure projects in CC, and those payments can apply directly to the bond rather than being received and immediately needing to be sold or locked separately, the Foundation effectively capitalizes the infrastructure it wants to exist. Bonding stays a real commitment (locked, not spent) while removing "find $3.75M in 15 days" for bootstrapped teams.

Thanks, Ian Saxon Nodes Ltd

Eric Saraniecki

May 3, 2026

Thanks again to everyone for all the feedback. However, I think we’ve let this topic run a bit longer than it should have. I believe we need to move quickly to put some improved FA governance in place.

One key gap in prior discussions has been fully accounting for the impact of CIP-0104. Specifically, that the current FA governance requirements are temporary and will change meaningfully once markers are removed.

Earlier proposals focused on ramping toward larger locking requirements. In practice, what we need is a near-term locking that bridges us to CIP-0104.

The attached draft reflects that - a high per-party CC lock in the immediate term - combined with allowing already-locked CC to be used to back a Featured App. This approach would allow for good access to locking capital while tightening quality of apps in the FA pool. I believe this might strike the right balance right now.

All feedback welcome

Featured App Locking CIP v0.5

Summary

This proposal introduces per-party CC locking requirements for Featured App (FA) designation. The objective is to:

● Shift FA governance towards a market-based process

● Allow for the temporary use of SV-locked CC to bootstrap this process The proposal is implemented in three stages:

1. Immediate

2. Post CIP-0104

3. Within 120 days of CIP-0104 go-live

Motivation

Featured App designation currently relies heavily on Foundation governance. This proposal introduces objective, on-chain criteria to:

● Reduce reliance on Foundation support

● Allow all CC holders to participate in FA designation process

Pre CIP-0104 conditions require immediate higher locking amounts due to FA Marker mechanics. Following CIP-0104, FA Markers are removed and all FA reward attribution is managed at the protocol level, allowing a transition to lower thresholds and increased reliance on market signal.

Specification

1. Featured App Requirements

To qualify for and maintain Featured App status, an application must:

1. Maintain good standing with the Foundation

2. Satisfy the applicable minimum CC locking requirement per PartyId Failure to meet either condition results in loss of Featured App status. Locking is required per PartyId.

2. Stage 1 — Immediate upon CIP passing 2.1 Locking Requirement

● Minimum: 25,000,000 CC per PartyId

2.2 Locking Mechanics

● Locking follows the same rules as Super Validator (SV) locking

● CC must be held in a segregated, auditable PartyId and reported to the Foundation ● Only actively locked CC counts toward FA eligibility

2.3 SV Lock Reuse

● CC used for SV locking may also be used to satisfy FA locking requirements ● SV must report to the Foundation

2.4 Duration

● This stage remains in effect until activation of CIP-0104

3. Stage 2 — Post CIP-0104

Upon activation of CIP-0104, FA locking transitions to a lower-threshold model. 3.1 Locking Tiers

● Tier 1

○ FA Rewards capped at 80c

○ Minimum: 1,000,000 CC

○ Lock duration: 30 days

● Tier 2

○ FA Rewards capped at $1.50

○ Minimum: 5,000,000 CC

○ Lock duration: 365 days

3.2 SV Lock Reuse

● SV lock reuse remains permitted in this stage

4. Stage 3 — Within 120 Days of CIP-0104 Go-Live

Within 120 days of CIP-0104 activation, the FA locking model is updated with a CIP amendment refining and enacting the following:

4.1 Removal of SV Lock Reuse

● CC used for SV locking may no longer be used to satisfy FA locking requirements 4.2 Economic Adjustments

● Locking thresholds and/or durations may be adjusted to reflect:

○ Removal of SV lock reuse

○ Evolving network conditions

● Updated parameters will be:

○ Publicly communicated

○ Defined with a clear effective date

○ Enforced after reasonable notice

5. SV Lock Reuse Revocation

If a Super Validator uses SV-locked CC to support a Featured App, and that application loses Featured App status:

● The Super Validator loses the ability to use SV-locked CC to satisfy FA locking requirements going forward

● Any Featured Apps relying on that SV’s reused CC lose Featured App status unless they independently satisfy locking requirements

● The Super Validator may continue to support Featured Apps using non-SV-locked CC

6. Enforcement

● Locking requirements must be continuously satisfied

● If locking falls below required thresholds Featured App status is removed ● Super Validator operators are required to implement and maintain a rapid-response unfeaturing process

This process must:

● Allow any Super Validator to initiate an unfeature action via a standard proposal mechanism

● SV Operators must respond within 30 minutes or less from initiation of an unfeature vote proposal

7. Governance

The Tokenomics Working Group and Super Validators may propose updates to:

● Locking thresholds

● Lock durations

● Lock reuse policies

All updates must:

● Be publicly communicated

● Include an effective date

● Provide reasonable notice prior to enforcement

Show quoted message

On Mon, Apr 6, 2026 at 10:20 AM luca.burlando via lists.sync.global <luca.burlando=republic.co@...> wrote:

Eric, thanks for the reworked proposal. understand the intent to keep Featured App quality high, but I think this version risks backfiring in practice

Small companies: Locking up or borrowing ~$375k in the first 60 days of FA operations is a massive ask. If these teams are VC-backed, those obligations hit balance sheets and complicate future raises. If the only path to building on Canton as a new company is taking out loans just to operate your app, with no certainty of profit, the risk calculus falls apart for most teams. Canton's app ecosystem is still early. It should be pulling builders in, not raising the barrier

Large companies: Decisions to build on a blockchain already take months or years internally. Telling a large company they also need to lock ~$3.75M in CC within six months just to operate on Canton, will make many question whether it's worth starting at all, or whether another chain is a better bet

SVs operating FAs: SVs already lock 70% of lifetime rewards. Funding FA locking requirements out of the remaining 30%, on top of covering operations, makes running both an SV and FA borderline uneconomical extremely tight

Ecosystem involvement from players like CNTN is welcome and needed. But no new company without the cash on hand for FA locking outright will feel comfortable building long-term knowing a third party can recall a loan and shut down their app. Our concern is this proposal risks stalling the momentum Canton has built over the last few months, with both early-stage teams and large players

There could be a way where apps can earn the required stake over time, instead of having a large lock from the beginning. This would lower the barrier to entry, while ensuring long-term alignment. It also aligns locking threshold with the SV locking quotes. A proposal could be something like this:

Minimum CC Lock

Day 0–30: 1,000,000 CC or 50% of rewards earned from the FA, whichever lower

Day 31–60: 2,500,000 CC or 55% of rewards earned from the FA, whichever lower

Day 61–90: 5,000,000 CC or 60% of rewards earned from the FA, whichever lower

Day 91–180: 10,000,000 CC or 65% of rewards earned from the FA, whichever lower

Day 181+: 25,000,000 CC or 70% of rewards earned from the FA, whichever lower

Anthony Merriman

May 4, 2026

Hi Eric (and everyone!)

We think the new staking quantities for phase 2 and phase 3 with the 120 day roll-out plan are both reasonable and relatively easy to implement. We also believe the introduction of FA reward tiers is a good concept in general but wonder if it may make more sense to be scoped as a separate CIP to be more robust and consider different types of tiers and scenarios. Happy to iterate or start a draft if this is interesting.

On the phase 1 immediate implementation, our view is that the primary concern is that many FA applications were approved without sufficient due diligence to ascertain if the teams and products are "legitimate". We think a simpler implementation would be to immediately revoke FA status for all non-active partyIDs and form a committee to review and approve FAs over the coming weeks. CIP-104 should release relatively soon but any FA that has a production application ready to launch can be reviewed by a tokenomics sub-committee before approval. This removes the marker submission attack vector immediately without creating additional toil for SVs and existing/active FAs. This path also grants the ecosystem the ability to be more judicious with approvals of Featured Apps over the next 4-6 weeks. We believe the impact will be minimal for any application that has been fully developed and is ready to deploy to mainnet to start featured activity.

Just to be super clear - we do believe moving forward with the staking proposal and the post CIP-104 rollout makes sense and would encourage the ecosystem to move quickly in this direction.

toggle quoted message Show quoted text

Show quoted message

On Mon, May 4, 2026 at 6:44 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

[Edited Message Follows]
[Reason: Add text of CIP in the thread]

Thanks again to everyone for all the feedback. However, I think we’ve let this topic run a bit longer than it should have. I believe we need to move quickly to put some improved FA governance in place.

One key gap in prior discussions has been fully accounting for the impact of CIP-0104. Specifically, that the current FA governance requirements are temporary and will change meaningfully once markers are removed.

Earlier proposals focused on ramping toward larger locking requirements. In practice, what we need is a near-term locking that bridges us to CIP-0104.

The attached draft reflects that - a high per-party CC lock in the immediate term - combined with allowing already-locked CC to be used to back a Featured App. This approach would allow for good access to locking capital while tightening quality of apps in the FA pool. I believe this might strike the right balance right now.

All feedback welcome

Featured App Locking CIP v0.5

Summary

This proposal introduces per-party CC locking requirements for Featured App (FA) designation. The objective is to:

● Shift FA governance towards a market-based process

● Allow for the temporary use of SV-locked CC to bootstrap this process The proposal is implemented in three stages:

1. Immediate

2. Post CIP-0104

3. Within 120 days of CIP-0104 go-live

Motivation

Featured App designation currently relies heavily on Foundation governance. This proposal introduces objective, on-chain criteria to:

● Reduce reliance on Foundation support

● Allow all CC holders to participate in FA designation process

Pre CIP-0104 conditions require immediate higher locking amounts due to FA Marker mechanics. Following CIP-0104, FA Markers are removed and all FA reward attribution is managed at the protocol level, allowing a transition to lower thresholds and increased reliance on market signal.

Specification

1. Featured App Requirements

To qualify for and maintain Featured App status, an application must:

1. Maintain good standing with the Foundation

2. Satisfy the applicable minimum CC locking requirement per PartyId Failure to meet either condition results in loss of Featured App status. Locking is required per PartyId.

2. Stage 1 — Immediate upon CIP passing 2.1 Locking Requirement

● Minimum: 25,000,000 CC per PartyId

2.2 Locking Mechanics

● Locking follows the same rules as Super Validator (SV) locking

● CC must be held in a segregated, auditable PartyId and reported to the Foundation ● Only actively locked CC counts toward FA eligibility

2.3 SV Lock Reuse

● CC used for SV locking may also be used to satisfy FA locking requirements ● SV must report to the Foundation

2.4 Duration

● This stage remains in effect until activation of CIP-0104

3. Stage 2 — Post CIP-0104

Upon activation of CIP-0104, FA locking transitions to a lower-threshold model. 3.1 Locking Tiers

● Tier 1

○ FA Rewards capped at 80c

○ Minimum: 1,000,000 CC

○ Lock duration: 30 days

● Tier 2

○ FA Rewards capped at $1.50

○ Minimum: 5,000,000 CC

○ Lock duration: 365 days

3.2 SV Lock Reuse

● SV lock reuse remains permitted in this stage

4. Stage 3 — Within 120 Days of CIP-0104 Go-Live

Within 120 days of CIP-0104 activation, the FA locking model is updated with a CIP amendment refining and enacting the following:

4.1 Removal of SV Lock Reuse

● CC used for SV locking may no longer be used to satisfy FA locking requirements 4.2 Economic Adjustments

● Locking thresholds and/or durations may be adjusted to reflect:

○ Removal of SV lock reuse

○ Evolving network conditions

● Updated parameters will be:

○ Publicly communicated

○ Defined with a clear effective date

○ Enforced after reasonable notice

5. SV Lock Reuse Revocation

If a Super Validator uses SV-locked CC to support a Featured App, and that application loses Featured App status:

● The Super Validator loses the ability to use SV-locked CC to satisfy FA locking requirements going forward

● Any Featured Apps relying on that SV’s reused CC lose Featured App status unless they independently satisfy locking requirements

● The Super Validator may continue to support Featured Apps using non-SV-locked CC

6. Enforcement

● Locking requirements must be continuously satisfied

● If locking falls below required thresholds Featured App status is removed ● Super Validator operators are required to implement and maintain a rapid-response unfeaturing process

This process must:

● Allow any Super Validator to initiate an unfeature action via a standard proposal mechanism

● SV Operators must respond within 30 minutes or less from initiation of an unfeature vote proposal

7. Governance

The Tokenomics Working Group and Super Validators may propose updates to:

● Locking thresholds

● Lock durations

● Lock reuse policies

All updates must:

● Be publicly communicated

● Include an effective date

● Provide reasonable notice prior to enforcement

On Mon, Apr 6, 2026 at 10:20 AM luca.burlando via lists.sync.global <luca.burlando=republic.co@...> wrote:

Eric, thanks for the reworked proposal. understand the intent to keep Featured App quality high, but I think this version risks backfiring in practice

Small companies: Locking up or borrowing ~$375k in the first 60 days of FA operations is a massive ask. If these teams are VC-backed, those obligations hit balance sheets and complicate future raises. If the only path to building on Canton as a new company is taking out loans just to operate your app, with no certainty of profit, the risk calculus falls apart for most teams. Canton's app ecosystem is still early. It should be pulling builders in, not raising the barrier

Large companies: Decisions to build on a blockchain already take months or years internally. Telling a large company they also need to lock ~$3.75M in CC within six months just to operate on Canton, will make many question whether it's worth starting at all, or whether another chain is a better bet

SVs operating FAs: SVs already lock 70% of lifetime rewards. Funding FA locking requirements out of the remaining 30%, on top of covering operations, makes running both an SV and FA borderline uneconomical extremely tight

Ecosystem involvement from players like CNTN is welcome and needed. But no new company without the cash on hand for FA locking outright will feel comfortable building long-term knowing a third party can recall a loan and shut down their app. Our concern is this proposal risks stalling the momentum Canton has built over the last few months, with both early-stage teams and large players

There could be a way where apps can earn the required stake over time, instead of having a large lock from the beginning. This would lower the barrier to entry, while ensuring long-term alignment. It also aligns locking threshold with the SV locking quotes. A proposal could be something like this:

Minimum CC Lock

Day 0–30: 1,000,000 CC or 50% of rewards earned from the FA, whichever lower

Day 31–60: 2,500,000 CC or 55% of rewards earned from the FA, whichever lower

Day 61–90: 5,000,000 CC or 60% of rewards earned from the FA, whichever lower

Day 91–180: 10,000,000 CC or 65% of rewards earned from the FA, whichever lower

Day 181+: 25,000,000 CC or 70% of rewards earned from the FA, whichever lower

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Chris Matturri

May 4, 2026

Hi Eric- I think we are ready to endorse this to a vote. Two clarifications first:

1) What % of the SV locking amount could be used for FA locking? Probably important to define this is now if we are to move this forward to a vote

2) Can you clarify what you mean for the two tiers post CIP 104 going live- does this mean that any app with 1mn CC locked will only earn $.80 for every $1 of burn while FAs with 5mn CC locked will earn $1.50 per $1 of burn?

Also under Enforcment the 30 minute SLA for SV's to respond to an unfeature vote may be a bit too tight- don't think we've committed to this previously.

Otherwise thank you for sharing and agree it's time to get something in motion for this.

toggle quoted message Show quoted text

Show quoted message

On Mon, May 4, 2026 at 6:44 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

[Edited Message Follows]
[Reason: Add text of CIP in the thread]

Thanks again to everyone for all the feedback. However, I think we’ve let this topic run a bit longer than it should have. I believe we need to move quickly to put some improved FA governance in place.

One key gap in prior discussions has been fully accounting for the impact of CIP-0104. Specifically, that the current FA governance requirements are temporary and will change meaningfully once markers are removed.

Earlier proposals focused on ramping toward larger locking requirements. In practice, what we need is a near-term locking that bridges us to CIP-0104.

The attached draft reflects that - a high per-party CC lock in the immediate term - combined with allowing already-locked CC to be used to back a Featured App. This approach would allow for good access to locking capital while tightening quality of apps in the FA pool. I believe this might strike the right balance right now.

All feedback welcome

Featured App Locking CIP v0.5

Summary

This proposal introduces per-party CC locking requirements for Featured App (FA) designation. The objective is to:

● Shift FA governance towards a market-based process

● Allow for the temporary use of SV-locked CC to bootstrap this process The proposal is implemented in three stages:

1. Immediate

2. Post CIP-0104

3. Within 120 days of CIP-0104 go-live

Motivation

Featured App designation currently relies heavily on Foundation governance. This proposal introduces objective, on-chain criteria to:

● Reduce reliance on Foundation support

● Allow all CC holders to participate in FA designation process

Pre CIP-0104 conditions require immediate higher locking amounts due to FA Marker mechanics. Following CIP-0104, FA Markers are removed and all FA reward attribution is managed at the protocol level, allowing a transition to lower thresholds and increased reliance on market signal.

Specification

1. Featured App Requirements

To qualify for and maintain Featured App status, an application must:

1. Maintain good standing with the Foundation

2. Satisfy the applicable minimum CC locking requirement per PartyId Failure to meet either condition results in loss of Featured App status. Locking is required per PartyId.

2. Stage 1 — Immediate upon CIP passing 2.1 Locking Requirement

● Minimum: 25,000,000 CC per PartyId

2.2 Locking Mechanics

● Locking follows the same rules as Super Validator (SV) locking

● CC must be held in a segregated, auditable PartyId and reported to the Foundation ● Only actively locked CC counts toward FA eligibility

2.3 SV Lock Reuse

● CC used for SV locking may also be used to satisfy FA locking requirements ● SV must report to the Foundation

2.4 Duration

● This stage remains in effect until activation of CIP-0104

3. Stage 2 — Post CIP-0104

Upon activation of CIP-0104, FA locking transitions to a lower-threshold model. 3.1 Locking Tiers

● Tier 1

○ FA Rewards capped at 80c

○ Minimum: 1,000,000 CC

○ Lock duration: 30 days

● Tier 2

○ FA Rewards capped at $1.50

○ Minimum: 5,000,000 CC

○ Lock duration: 365 days

3.2 SV Lock Reuse

● SV lock reuse remains permitted in this stage

4. Stage 3 — Within 120 Days of CIP-0104 Go-Live

Within 120 days of CIP-0104 activation, the FA locking model is updated with a CIP amendment refining and enacting the following:

4.1 Removal of SV Lock Reuse

● CC used for SV locking may no longer be used to satisfy FA locking requirements 4.2 Economic Adjustments

● Locking thresholds and/or durations may be adjusted to reflect:

○ Removal of SV lock reuse

○ Evolving network conditions

● Updated parameters will be:

○ Publicly communicated

○ Defined with a clear effective date

○ Enforced after reasonable notice

5. SV Lock Reuse Revocation

If a Super Validator uses SV-locked CC to support a Featured App, and that application loses Featured App status:

● The Super Validator loses the ability to use SV-locked CC to satisfy FA locking requirements going forward

● Any Featured Apps relying on that SV’s reused CC lose Featured App status unless they independently satisfy locking requirements

● The Super Validator may continue to support Featured Apps using non-SV-locked CC

6. Enforcement

● Locking requirements must be continuously satisfied

● If locking falls below required thresholds Featured App status is removed ● Super Validator operators are required to implement and maintain a rapid-response unfeaturing process

This process must:

● Allow any Super Validator to initiate an unfeature action via a standard proposal mechanism

● SV Operators must respond within 30 minutes or less from initiation of an unfeature vote proposal

7. Governance

The Tokenomics Working Group and Super Validators may propose updates to:

● Locking thresholds

● Lock durations

● Lock reuse policies

All updates must:

● Be publicly communicated

● Include an effective date

● Provide reasonable notice prior to enforcement

On Mon, Apr 6, 2026 at 10:20 AM luca.burlando via lists.sync.global <luca.burlando=republic.co@...> wrote:

Eric, thanks for the reworked proposal. understand the intent to keep Featured App quality high, but I think this version risks backfiring in practice

Small companies: Locking up or borrowing ~$375k in the first 60 days of FA operations is a massive ask. If these teams are VC-backed, those obligations hit balance sheets and complicate future raises. If the only path to building on Canton as a new company is taking out loans just to operate your app, with no certainty of profit, the risk calculus falls apart for most teams. Canton's app ecosystem is still early. It should be pulling builders in, not raising the barrier

Large companies: Decisions to build on a blockchain already take months or years internally. Telling a large company they also need to lock ~$3.75M in CC within six months just to operate on Canton, will make many question whether it's worth starting at all, or whether another chain is a better bet

SVs operating FAs: SVs already lock 70% of lifetime rewards. Funding FA locking requirements out of the remaining 30%, on top of covering operations, makes running both an SV and FA borderline uneconomical extremely tight

Ecosystem involvement from players like CNTN is welcome and needed. But no new company without the cash on hand for FA locking outright will feel comfortable building long-term knowing a third party can recall a loan and shut down their app. Our concern is this proposal risks stalling the momentum Canton has built over the last few months, with both early-stage teams and large players

There could be a way where apps can earn the required stake over time, instead of having a large lock from the beginning. This would lower the barrier to entry, while ensuring long-term alignment. It also aligns locking threshold with the SV locking quotes. A proposal could be something like this:

Minimum CC Lock

Day 0–30: 1,000,000 CC or 50% of rewards earned from the FA, whichever lower

Day 31–60: 2,500,000 CC or 55% of rewards earned from the FA, whichever lower

Day 61–90: 5,000,000 CC or 60% of rewards earned from the FA, whichever lower

Day 91–180: 10,000,000 CC or 65% of rewards earned from the FA, whichever lower

Day 181+: 25,000,000 CC or 70% of rewards earned from the FA, whichever lower

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Chris Zuehlke

May 5, 2026

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:
1. What can initiate a vote?
2. What are the consequences of initiating a vote in bad faith?
3. How would signing work in an automated construct?
We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:
1. The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
2. A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
3. The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
4. Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?
Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

Edmund Rhudy

May 5, 2026

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:
1. What can initiate a vote?
2. What are the consequences of initiating a vote in bad faith?
3. How would signing work in an automated construct?
We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:
1. The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
2. A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
3. The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
4. Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?
Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

Eric Saraniecki

May 5, 2026

I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

Show quoted message

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

Eric Saraniecki

May 6, 2026

Ok - here is my latest draft based on feedback

Show quoted message

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Eric Saraniecki

May 6, 2026

just saw a typo in there - here is the minor edit

Show quoted message

On Tue, May 5, 2026 at 8:51 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

Ok - here is my latest draft based on feedback

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Chris Matturri

May 6, 2026

Thank you Eric, we support moving this latest version to a vote

Chris Matturri

chris@...

ProofGroup.xyz

toggle quoted message Show quoted text

Show quoted message

On Tue, May 5, 2026 at 7:56 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

just saw a typo in there - here is the minor edit

On Tue, May 5, 2026 at 8:51 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Ok - here is my latest draft based on feedback

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Yiannis Varelas

May 6, 2026

5North supportive as well.

toggle quoted message Show quoted text

Show quoted message

On Tue, May 5, 2026 at 21:30 Chris Matturri via lists.sync.global <chris=proofgroup.xyz@...> wrote:

Thank you Eric, we support moving this latest version to a vote

Chris Matturri

chris@...
ProofGroup.xyz

On Tue, May 5, 2026 at 7:56 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
just saw a typo in there - here is the minor edit

On Tue, May 5, 2026 at 8:51 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Ok - here is my latest draft based on feedback

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Irpan

May 6, 2026

I'm sorry to share a few thoughts.
I hope everyone here doesn't mind my sharing a bit, and once again, I apologize for interrupting this discussion.

When I first started wanting to be part of this ecosystem, the system I created was a perfect fit for me.
The system rewards and recognizes application development or excellent contributions. And last but not least, the support team is extraordinary; they've been very helpful when I needed help.

Askardex is a small startup. I created it with enthusiasm, even registering Askardex and establishing a legal entity. The process involved significant capital investment.

However, I realize that Askardex entered this ecosystem quite late. During the process, many changes occurred, and I'm still trying to understand all the policies.

If CIP-0116 is approved, I personally will have to put in extra effort to build Askardex even better. Based on this discussion, I really hope they reconsider things related to new startups.

I truly appreciate and respect everyone who is part of the system, but I hope you'll consider smaller startups, like Askardex, which are still just starting out.

Thank you again, and I apologize for interrupting this discussion.

Sincerely, Asakrdex Founder

Regards

Eric Saraniecki

May 8, 2026

Thank you 5N and PG for sponsoring the previous proposal to a vote. That action prompted some very strong feedback that I found compelling.

In summary - the feedback was compelling to me that the staging, changes in locking amount, tiers, reuse, and penalties were not worth the complexity and we should just chart a glide path to the end state given it's not far in front of us.

Accordingly, here is a simplified proposal for consideration

As always, thanks for the feedback

Show quoted message

On Tue, May 5, 2026 at 10:07 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:

5North supportive as well.

On Tue, May 5, 2026 at 21:30 Chris Matturri via lists.sync.global <chris=proofgroup.xyz@...> wrote:
Thank you Eric, we support moving this latest version to a vote

Chris Matturri

chris@...
ProofGroup.xyz

On Tue, May 5, 2026 at 7:56 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
just saw a typo in there - here is the minor edit

On Tue, May 5, 2026 at 8:51 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Ok - here is my latest draft based on feedback

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Yaron

May 12, 2026

Hi Eric and all,

I’ve been following the v0.7 draft and the broader discussion regarding the balance between the Foundation’s "quality moat" and the builders' concerns over capital, specifically the 5M CC locking requirement and the operational burden of the 30-minute SV response window.

A little background: I'm Yaron, co-founder of Polli.co. We are building an allocation intelligence layer initially designed for staking optimization; however, we see a clear role for Polli to act as the discovery and "Market Signal" layer for CIP-0116.

I believe there is a significant opportunity to solve the "Capital Gap" for emerging teams by leaning into the market-based process this draft proposes. By showcasing app metrics, value propositions, and performance data, Polli can help high-quality teams, who may not have 5M CC on their own balance sheet, attract that stake from the broader community of CC holders.

This effectively turns the locking requirement from a "barrier to entry" into a "market signal" of community trust and app utility. If the goal is to shift FA designation toward a market-driven model, we believe providing the tools for CC holders to intelligently discover and back these apps is a vital piece of the puzzle.

Looking forward to seeing how the criteria for "market-based signals" evolve in the next iteration.

Best,

Yaron Polli.co

Yaron

May 13, 2026

Hi Eric and all,

Looking forward to seeing how the criteria for "market-based signals" evolve in the next iteration.

Best,

Yaron Polli.co

Eric Saraniecki

May 13, 2026

Hi all

v0.8 attached

On the Tokenomics weekly call today, we discussed the idea of having higher locking threshold for Asset Issuers.

Show quoted message

On Fri, May 8, 2026 at 1:03 PM W. Eric Saraniecki <eric@...> wrote:

Thank you 5N and PG for sponsoring the previous proposal to a vote. That action prompted some very strong feedback that I found compelling.

In summary - the feedback was compelling to me that the staging, changes in locking amount, tiers, reuse, and penalties were not worth the complexity and we should just chart a glide path to the end state given it's not far in front of us.

Accordingly, here is a simplified proposal for consideration

As always, thanks for the feedback

On Tue, May 5, 2026 at 10:07 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:
5North supportive as well.

On Tue, May 5, 2026 at 21:30 Chris Matturri via lists.sync.global <chris=proofgroup.xyz@...> wrote:
Thank you Eric, we support moving this latest version to a vote

Chris Matturri

chris@...
ProofGroup.xyz

On Tue, May 5, 2026 at 7:56 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
just saw a typo in there - here is the minor edit

On Tue, May 5, 2026 at 8:51 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Ok - here is my latest draft based on feedback

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Yiannis Varelas

May 13, 2026

Eric, this is a much improved proposal IMO.

The different requirements for Asset Issuers versus Non-Asset Issuers make a lot of sense given
that Asset Issuers don't burn traffic. The lockup / unlock period is also reasonable and
requires those who actually support the apps to exercise reasonable due diligence and not
blindly lend out CC.

And given the volume of FA requests we get (and how this increases), prioritizing
review based on locking time, also makes it clear.

Realistically, meeting a 30-minute action item from SVs is very difficult, but
with some automation can be managed. But I'd like this to be extended
until we get to the automation.

Y.

toggle quoted message Show quoted text

Show quoted message

On Wed, May 13, 2026 at 11:58 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:

Hi all

v0.8 attached

On the Tokenomics weekly call today, we discussed the idea of having higher locking threshold for Asset Issuers.

On Fri, May 8, 2026 at 1:03 PM W. Eric Saraniecki <eric@...> wrote:
Thank you 5N and PG for sponsoring the previous proposal to a vote. That action prompted some very strong feedback that I found compelling.

In summary - the feedback was compelling to me that the staging, changes in locking amount, tiers, reuse, and penalties were not worth the complexity and we should just chart a glide path to the end state given it's not far in front of us.

Accordingly, here is a simplified proposal for consideration

As always, thanks for the feedback

On Tue, May 5, 2026 at 10:07 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:
5North supportive as well.

On Tue, May 5, 2026 at 21:30 Chris Matturri via lists.sync.global <chris=proofgroup.xyz@...> wrote:
Thank you Eric, we support moving this latest version to a vote

Chris Matturri

chris@...
ProofGroup.xyz

On Tue, May 5, 2026 at 7:56 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
just saw a typo in there - here is the minor edit

On Tue, May 5, 2026 at 8:51 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Ok - here is my latest draft based on feedback

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Yiannis Varelas

May 14, 2026

Forgot to add that 5North is ready to sponsor/endorse this CIP as is.

The 30 mins response time is minimal friction and we can establish a path forward
on how we improve our response times in operator meetings.

Y.

toggle quoted message Show quoted text

Show quoted message

On Wed, May 13, 2026 at 1:35 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:

Eric, this is a much improved proposal IMO.

The different requirements for Asset Issuers versus Non-Asset Issuers make a lot of sense given
that Asset Issuers don't burn traffic. The lockup / unlock period is also reasonable and
requires those who actually support the apps to exercise reasonable due diligence and not
blindly lend out CC.

And given the volume of FA requests we get (and how this increases), prioritizing
review based on locking time, also makes it clear.

Realistically, meeting a 30-minute action item from SVs is very difficult, but
with some automation can be managed. But I'd like this to be extended
until we get to the automation.

Y.

On Wed, May 13, 2026 at 11:58 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Hi all

v0.8 attached

On the Tokenomics weekly call today, we discussed the idea of having higher locking threshold for Asset Issuers.

On Fri, May 8, 2026 at 1:03 PM W. Eric Saraniecki <eric@...> wrote:
Thank you 5N and PG for sponsoring the previous proposal to a vote. That action prompted some very strong feedback that I found compelling.

In summary - the feedback was compelling to me that the staging, changes in locking amount, tiers, reuse, and penalties were not worth the complexity and we should just chart a glide path to the end state given it's not far in front of us.

Accordingly, here is a simplified proposal for consideration

As always, thanks for the feedback

On Tue, May 5, 2026 at 10:07 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:
5North supportive as well.

On Tue, May 5, 2026 at 21:30 Chris Matturri via lists.sync.global <chris=proofgroup.xyz@...> wrote:
Thank you Eric, we support moving this latest version to a vote

Chris Matturri

chris@...
ProofGroup.xyz

On Tue, May 5, 2026 at 7:56 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
just saw a typo in there - here is the minor edit

On Tue, May 5, 2026 at 8:51 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Ok - here is my latest draft based on feedback

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Chris Matturri

May 15, 2026

Proof Group would like to formally endorse this as well to a vote

Chris Matturri

chris@...

ProofGroup.xyz

toggle quoted message Show quoted text

Show quoted message

On Thu, May 14, 2026 at 7:00 AM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:

Forgot to add that 5North is ready to sponsor/endorse this CIP as is.

The 30 mins response time is minimal friction and we can establish a path forward
on how we improve our response times in operator meetings.

Y.

On Wed, May 13, 2026 at 1:35 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:
Eric, this is a much improved proposal IMO.

The different requirements for Asset Issuers versus Non-Asset Issuers make a lot of sense given
that Asset Issuers don't burn traffic. The lockup / unlock period is also reasonable and
requires those who actually support the apps to exercise reasonable due diligence and not
blindly lend out CC.

And given the volume of FA requests we get (and how this increases), prioritizing
review based on locking time, also makes it clear.

Realistically, meeting a 30-minute action item from SVs is very difficult, but
with some automation can be managed. But I'd like this to be extended
until we get to the automation.

Y.

On Wed, May 13, 2026 at 11:58 AM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Hi all

v0.8 attached

On the Tokenomics weekly call today, we discussed the idea of having higher locking threshold for Asset Issuers.

On Fri, May 8, 2026 at 1:03 PM W. Eric Saraniecki <eric@...> wrote:
Thank you 5N and PG for sponsoring the previous proposal to a vote. That action prompted some very strong feedback that I found compelling.

In summary - the feedback was compelling to me that the staging, changes in locking amount, tiers, reuse, and penalties were not worth the complexity and we should just chart a glide path to the end state given it's not far in front of us.

Accordingly, here is a simplified proposal for consideration

As always, thanks for the feedback

On Tue, May 5, 2026 at 10:07 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:
5North supportive as well.

On Tue, May 5, 2026 at 21:30 Chris Matturri via lists.sync.global <chris=proofgroup.xyz@...> wrote:
Thank you Eric, we support moving this latest version to a vote

Chris Matturri

chris@...
ProofGroup.xyz

On Tue, May 5, 2026 at 7:56 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
just saw a typo in there - here is the minor edit

On Tue, May 5, 2026 at 8:51 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
Ok - here is my latest draft based on feedback

On Tue, May 5, 2026 at 2:43 PM Eric Saraniecki via lists.sync.global <eric=digitalasset.com@...> wrote:
I am aware the 30m response times will be something the SVs would need to invest in - I’m happy to have conversations with SVs on reasonable approach to this topic

However, I don’t think we should let the implementation details of that response time interfere with advancing this CIP should it have broad support

ill revert with some other modifications shortly

thanks for the feedback

On Tue, May 5, 2026 at 6:29 AM Edmund Rhudy via lists.sync.global <edmund.rhudy=tradeweb.com@...> wrote:

Since this just came up in the US SV ops meeting - I don't think a 30 minute vote window is practical. Our internal approval processes do not permit that level of responsiveness even during normal business hours, and nobody is going to wake up at 3 AM to call our CRO to urgently report that we need to get on Zoom and vote to unfeature an app on MainNet because somebody might be earning slightly too much Canton Coin from their featured app. If I'm calling somebody in the C-suite out of hours, it's for a potential company-ending event, not this. I would prefer at a minimum end of NBD, preferably longer.

From: cip-discuss@... <cip-discuss@...> on behalf of Chris Zuehlke via lists.sync.global <czuehlke=drwholdings.com@...>
Date: Tuesday, May 5, 2026 at 00:13
To: cip-discuss@... <cip-discuss@...>
Subject: Re: [cip-discuss] CIP-TBD: Featured App Staking - Eric Saraniecki

CAUTION:This email originated from outside of Tradeweb. Do not open attachments or click on links if you do not recognize the sender or if the content appears unsafe/you cannot verify the content is safe.

Thanks for putting the new draft together, Eric. I agree there is a need for an intermediate solution between now and 104 go-live and recognize that given the short timeline any potential approach needs low complexity/tech lift. This seems to meet that requirement. Given more time we would likely suggest a different, more complex approach, but in the interest of working through your proposal, we wanted to share some initial feedback:

We believe the 30 minute vote window would be impractical if the votes we're all manual. Automation could make it more feasible, but that introduces additional questions:

What can initiate a vote?
What are the consequences of initiating a vote in bad faith?
How would signing work in an automated construct?

We're open to the idea of reusing SV locking, but note that a single FA revocation could poison the well so to speak, preventing a SV from reusing lock going forward. Some thoughts on that dynamic:

The risk of this (coupled with other locking dynamics) may limit SV's willingness to lock for FA. Not a strong opinion on this, just recognizing the dynamic.
A single FA revocation could trigger a cascade of other FA becoming unfeatured if they had a lock from that SV.
The continued evolution towards bright line tests for guidelines and Accountability's efforts to ensure adherence has all been very positive. In this structure that will need to continue--with no subjectivity in the decision making process.
Maybe a 3 strikes policy is in order for SV locking reuse? May want to consider an off-ramp timeline too so unassociated FAs from (2) have fair notice to source a new lock?

Phase 2 and 3 merit some additional clarity, Chris M raised some points. Also suggest making the wind-down timelines for reuse of SV locking clearly defined in phase 3.
Separate lock per party ID may disincentivize apps from using separate party IDs for multiple use cases as is the current guidance. Is there any way to discount subsequent party IDs for the same app?

Chris

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.digitalasset.com/emaildisclaimer.html. If you are not the intended recipient, please delete this message.

Alex Chen

May 15, 2026

Thanks, Eric, for all the work and for the community's feedback!

Prior to voting, we'd like to suggest a few small changes in the ordering of the lock to:

FA identifies assets that will be locked. If it meets the threshold, Foundation will order reviews based on the time at which assets were identified
- Long-term mechanism is TBD and will be proposed with technical proposal for automation
If FA is approved, they must lock ahead of a vote to feature their party ID; proposal of this vote will be gated on FA proving they have locked sufficient token

Another small but critical change - I think we need to specify that if "locking falls below required thresholds or if apps introduce activity necessitating a move into a higher tier" they can be removed, just to avoid having to clarify in the future.

King regards,

Alex

Cumberland

Eric Saraniecki

May 15, 2026

Made a couple edits - let me know if this addresses your concerns

Show quoted message

On Fri, May 15, 2026 at 10:01 AM Alex Chen via lists.sync.global <alechen=cumberland.io@...> wrote:

Thanks, Eric, for all the work and for the community's feedback!

Prior to voting, we'd like to suggest a few small changes in the ordering of the lock to:

FA identifies assets that will be locked. If it meets the threshold, Foundation will order reviews based on the time at which assets were identified

Long-term mechanism is TBD and will be proposed with technical proposal for automation

If FA is approved, they must lock ahead of a vote to feature their party ID; proposal of this vote will be gated on FA proving they have locked sufficient token

Another small but critical change - I think we need to specify that if "locking falls below required thresholds or if apps introduce activity necessitating a move into a higher tier" they can be removed, just to avoid having to clarify in the future.

King regards,

Alex

--

Cumberland

Alex Chen

May 15, 2026

Thanks, Eric - we're aligned with those changes.

Yiannis Varelas

May 15, 2026

5N wants to sponsor/endorse V0.9 of this CIP.

toggle quoted message Show quoted text

Show quoted message

On Fri, May 15, 2026 at 10:56 Alex Chen via lists.sync.global <alechen=cumberland.io@...> wrote:

Thanks, Eric - we're aligned with those changes.

Chris Matturri

May 15, 2026

We endorse the new version as well

Chris Matturri

chris@...

ProofGroup.xyz

toggle quoted message Show quoted text

Show quoted message

On Fri, May 15, 2026 at 12:35 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:

5N wants to sponsor/endorse V0.9 of this CIP.

On Fri, May 15, 2026 at 10:56 Alex Chen via lists.sync.global <alechen=cumberland.io@...> wrote:
Thanks, Eric - we're aligned with those changes.

Eric Saraniecki

May 17, 2026

minor tweak for clarity in section 4 - don’t think it changes anything but being more explicit that changes require full governance process and sv vote

Show quoted message

On Fri, May 15, 2026 at 12:53 PM Chris Matturri via lists.sync.global <chris=proofgroup.xyz@...> wrote:

We endorse the new version as well

Chris Matturri

chris@...
ProofGroup.xyz

On Fri, May 15, 2026 at 12:35 PM Yiannis Varelas via lists.sync.global <y=fivenorth.io@...> wrote:
5N wants to sponsor/endorse V0.9 of this CIP.

On Fri, May 15, 2026 at 10:56 Alex Chen via lists.sync.global <alechen=cumberland.io@...> wrote:
Thanks, Eric - we're aligned with those changes.

Irpan

May 17, 2026

I would like to ask, if this is approved, for the CC lock mechanism, is it mandatory to use the application owner's party ID, or can we collaborate with a liquidity provider to provide a party ID that locks the CV in the name of my application, for example?

Luke Farrell

May 17, 2026

Cashen is an Canton Foundation member application that provides a marketplace for bilateral third party delegated locks for SV and FA locked CC needs.
Please reach out if you are in need of delegation, or if you’d like to sign up to supply CC to these type of deals.
We are actively involved in designing the Splice on-chain enforcement for Phase2 , and have liquidity for off chain deals possible before that goes live. We support initial deals that fulfill the locking requirements with CIP vesting schedules, as well as early substitution for suppliers who want compliant flexibility to close deals early.
-Luke

luke@...

Featured App Staking

Summary

Motivation

Specification

1. Featured App Qualification Requirements

1.1 Foundation Good Standing

1.2 Minimum CC Stake Requirement

2. Phased Implementation

Phase 1: Transitional Enforcement (Manual)

Phase 2: On-Chain Locking (Automated App Staking)

3. Third-Party App Backing

4. Ongoing Parameter Review

Backwards Compatibility

Copyright

Changelog

Proposal: Bonded Incentives for Featured Apps

Summary

Motivation

Proposal Overview

Incentive Reallocation

Bonding Mechanics

Featured App–Specific Requirements

Benefits

Downsides and Risks

Implementation Schedule

Initial Rollout

Progressive Increases

Ongoing Adjustments

Lockups and Unlocking

Closing Note

Featured App Bonding and Rewards Reallocation

Summary

Motivation

Specification

1. Featured App Bonding and Rewards Reallocation

1.1 Featured App Bonding

1.2 Featured App Rewards Reallocation

2. Phased Implementation

Phase 1: Transitional Bonding Growth (Manual)

Phase 2: Steady State (Automated Bond Monitoring)

3. Third-Party App Backing

4. Ongoing Parameter Review

5. Pro Rata Bonding Pool Rewards Calculations

Backwards Compatibility

Flexible bonding path (sponsor or earn-in)

Rationale: barrier to entry and capital allocation

Reduced unbonding period to improve capital efficiency

Leave a reply