Skip to main content
Activity rewards are the public Canton featured-app program. Holdings activity on your instrument is recorded as activity markers, except activity submitted by participants (“venues”) you exclude. The network pays the beneficiaries named on the markers you post. This is separate from minting the instrument. You can launch and operate an instrument with rewards turned off. Turn them on by running Token App’s fa_markers module and holding a featured-app right.
On a private synchronizer the instrument still issues and transfers. Markers pay out when the featured-app right lives on a network that runs this program. A private synchronizer does not, by itself, pay them.

​
What you hold

The ledger user needs CanActAs for the featured-app party, because that party signs every marker batch.

​
How a marker is produced

Token App watches the ledger as your admin and looks for holdings activity on your instruments: transfers, pre-approved transfers, and settlements. Each of those creates or archives a holding, so the watch is on holdings rather than on one transfer API.
Holder activity → Price the traffic → Skip excluded venues → Queue the weight → Post a marker batch → Network pays beneficiaries.
Holder activity → Price the traffic → Skip excluded venues → Queue the weight → Post a marker batch → Network pays beneficiaries.
Weight for one transaction is capped before it enters a batch, so a single large transaction cannot dominate a batch. Weight that does not fit in this batch waits for the next one. If a submission’s outcome is unknown, Token App keeps those transactions reserved and reconciles them from the command result. It does not release them and post the same weight again.

​
Who is paid

beneficiaries.default is the party credited when no finer split applies. You may also map an application name to a party:
When a qualifying transaction carries a recognised application name, that instrument’s share is credited to the mapped party. Several recognised applications split that instrument’s share equally. An unrecognised name falls through to default. A transaction that touches two of your instruments splits its weight in half, then applies each instrument’s own map. The same beneficiary is combined into one credit.
Set default whenever fa_markers is enabled. A missing default fails attribution for that instrument.

​
What you can track

All of these require the Token App bearer token, except the Prometheus metrics. Use the v2 data routes. The unversioned routes are the previous shape and advertise v2 as their successor. The figures you reconcile against are the weight Token App posted and the beneficiary on each transaction. The network payment to that party is the confirmation that a posted marker was paid. Track both: posted weight in Token App, received rewards on the beneficiary’s own account.

​
Operating notes

  • Run one Token App process. Two processes will both move the cursor and can both post.
  • Catch-up after downtime walks the ledger from the stored cursor. The memory request in the chart exists for that walk. Leave it in place.
  • List your own participant in excludedVenues when markers should leave out activity submitted there, including your own mints and burns. With an empty list, that activity is included.
  • The featured-app party and the admin may be the same party. Exclusion is about which participant submitted the transaction, not about which party holds the featured-app right.
  • A Scan outage delays pricing. Transactions stay queued and are priced when Scan answers. They are not dropped on the first failure.