Featured App Activity Markers

Specification

Overview

Featured applications get the ability to create FeaturedAppActivityMarker contracts, which have a constant value determined by the newly introduced featuredAppActivityMarkerAmount parameter that is set through governance votes by the super validators (the default until changed is $1 USD). Tho governance process for changing this reuses the existing vote process to change AmuletConfig (also used for extraFeaturedAppRewardAmount) where one SV proposes a change and a 2/3 majority needs to accept. Similarly to SV rewards, it is possible to split the markers between different beneficiaries weighted by a split chosen by the provider. Rather than creating one marker with featuredAppActivityMarkerAmount, this allows creating multiple markers where each marker is weighted by some fraction of featuredAppActivityMarkerAmount with the requirements that the fractions add up to 1.0. The markers carry both the provider that was featured and produced the reward as well as the beneficiary party.

Automation run by the super validators converts these FeaturedAppActivityMarker contracts into the existing AppRewardCoupon contracts for the current open mining round with the US Dollar amount determined by featuredAppActivityMarkerAmount and converted to Canton Coin based on the Canton Coin conversion rate associated with that mining round.

These AppRewardCoupon contracts can then be minted in the same fashion as activity records originating from Canton Coin transfers with the slight extension that the beneficiary that mints the rewards can be different from the provider. In particular, they are minted from the existing minting pool/tranche for application rewards.

One transaction can contain multiple markers for different providers just as one transaction can contain multiple Canton Coin transfers. This can be useful for composed applications like an exchange where both an exchange and the asset registry applications should get rewards for successfully settling a trade in a single, atomic DvP transaction.

Featured application providers are expected to create featured application activity markers only for transactions that correspond to a transfer of an asset, or an equivalent transaction, which was enabled by the application provider. The detailed fair usage policy and enforcement thereof is left up to the Tokenomics Committee of the Global Synchronizer Foundation (GSF).

Details

A draft PR with all Daml changes is linked below in the Reference implementation section.

Core Daml Model

• A new template FeaturedAppActivityMarker is added that stores the provider party, beneficiary party and weight.
• Add a choice FeaturedAppRight_CreateActivityMarker on the existing FeaturedAppRight Daml template to create a FeaturedAppActivityMarker. This choice accepts a list of beneficiary parties and weights with the requirements that weights add up to 1.0.
• Add a choice AmuletRules_ConvertFeaturedAppActivityMarkers that allows the SVs to convert FeaturedAppActivityMarker contracts into AppRewardCoupon contracts.
• Extend the AppRewardCoupon template to track the beneficiary party.
• The beneficiary feature will also be made available to acitvity records generated from Canton Coin transfers.

External Daml API

To allow applications to decouple themselves from the internal amulet models and reduce the impact of upgrades to those, an API based on Daml interfaces is provided consisting of:

• An interface Splice.Api.FeaturedAppRightV1.FeaturedAppRight implemented by the existing FeaturedAppRight template.
• A choice FeaturedAppRight_CreateActivityMarker on that interface to create a marker contract. This choice accepts a list of beneficiary parties and weights with the requirements that weights add up to 1.0.
• An interface Splice.Api.FeaturedAppRightV1.FeaturedAppActivityMarker implemented by the newly introduced FeaturedAppActivityMarker template.

Rationale

Alternatives considered

Artificial Canton Coin transfers

Applications that do not use Canton Coin could still add artificial canton coin transfers to their application to generate application activity records. However, this has a few downsides over the marker contracts proposed in this CIP:

1. It adds additional complexity to applications to generate those transfers. Creating the marker contracts only depends on the FeaturedAppRight contract. A CC transfer requires a sender, receiver, some CC funds, access to an open mining round contract and access to amulet rules.
2. It increases traffic costs: A CC transfer is more complex, not just in terms of code needed to create it, but also in terms of transaction size: adding a dependency on Canton Coin transfers significantly increases the size of transactions.
3. Canton Coin transfers pin down the OpenMiningRound contract which is only active for ~20 minutes. This can limit their usage in combination with external signing as it does not allow for long delays between preparing a transaction and executing the signed transaction. While it is possible to circumvent this by splitting the transfer across two transactions where only the first one is externally signed, this would then require those two-step flows in all applications.

Traffic-Based Activity Markers

This CIP proposes attributing a constant value to each activity marker contract determined by featuredAppActivityMarkerAmount. Another attractive option would be to instead make it proportional to the traffic costs paid for a transaction. That is a viable long-term option.

However, this would be a significantly more complex change, which would delay this feature. We propose to implement the simpler option first.

Backwards compatiblity

The app reward activity markers are a new API and are purely additive. All existing APIs continue to function as is. In particular, Canton Coin transfers still also generate activity records that can be minted as rewards.

Reference implementation

A reference implementation of the Daml changes can be found in the decentralized-canton-sync repository.

Copyright

This CIP is licensed under CC-1.0.

Changelog

• 2025-03-24: - Approved by cip-vote
• 2025-03-13: - Added support for splitting the reward markers across different beneficiary parties.
• 2025-02-12: - Intial Draftof the proposal.
• 2025-03-24 Approval announced via mailing list thread