Reward Assignment API (CIP-0104)
As part of implementing CIP-0104 the following Daml API was introduced:
The API is meant for apps whose ultimate beneficiaries of rewards are different from the app provider party (e.g., decentralized apps). The API allows them to assign the rewards they receive for their app to their ultimate beneficiaries.
The API is based on a Daml interface, so that apps can use it from their Daml
code without incurring a static dependency on splice-amulet and the
corresponding upgrading challenges. The reward assignment choice can also
be called directly from the Ledger API for apps that don’t use custom Daml code.
Note that the coupons always specify the original app provider party for whose activity the reward coupon was created.
Featured App Activity Markers API (CIP-0047)
Important
On networks where traffic-based app rewards as described in CIP-0104 are enabled, the Featured App Activity Markers API will become irrelevant. On such networks, the API is still supported, but no rewards can be earned using it. We recommend apps to stop creating featured app activity markers once CIP-0104 is enabled.
The documentation here is provided for apps that need to integrate with app rewards prior to CIP-0104 being enabled to avoid unnecessary traffic costs.
See the text of the CIP-0047 for its background on its design and its specification.
See the reference docs below for the Daml interfaces that are part of the Featured App Activity Markers API; or read the source code.
The utility package below provides templates that allow to delegate the usage of featured app rights to other parties for the purpose of executing token standard actions. Use these templates to earn app rewards on token standard operations, and to potentially share some of them with your users.
Additional Splice Daml APIs
The app provider of an asset registry is not necessarily the same as the party controlling the minting and burning of tokens. A typical example are tokens that are bridged from another network. The following API targets that use-case; and thus enables to decouple the upgrade cycles of an asset registry from the ones of the bridging app.
The API is built in a similar style as the token standard APIs, but is not part of the token standard. In particular, implementors of the token standard are not required to implement this API.
Nevertheless the API definition is guaranteed to be stable, and can be used by for the purpose explained above. If there were changes to the API, then they would be published as a new version of the API using a fresh package name, so that both the old and the new version can be used in parallel.
Comments