Reinstatement Request: Excellar Issuer

[amit-excellar]

Excellar FA reinstatement request

Featured App Reinstatement Request

Summary

• Featured App name:

• Organization:

• Current stage:

  • Freshly paused, seeking reinstatement
  • Mid-appeal, disputing the basis of the pause
  • Already reinstated, lock outstanding

Briefly summarize what this PR is requesting:

---

Reinstatement Request File

This PR adds a completed reinstatement request at:

reinstatement/<your-app-name>-<YYYY-MM-DD>.md

The request should be prepared using:

templates/featured-app-reinstatement-request.md

---

Submission Checklist

Before submitting, confirm:

• The completed reinstatement request file is included in the reinstatement/ directory
• The file follows the Featured App Reinstatement Request template
• All PartyIds are listed exactly as they appear on-chain
• Any fields that do not apply are marked N/A with a brief reason
• Supporting figures, sources, and transaction hashes are included where applicable
• CIP-0116 locking status is included
• Any exception request is clearly identified in the reinstatement file, if applicable

---

Reviewer Notes

Use this section for anything reviewers should pay special attention to, such as disputed figures, pending lock completion, a shared participant node, an exception request, or a pending burn transaction.

[juanlenoves]

Hey guys,

Juan from Noves here.

This is our analysis of the relevant data for the covered time period. Happy to discuss further and help the Excellar team adjust their calculations.

Review of Excellar Featured App activity - Noves Report

Review window: March 15, 2026 at 04:00 UTC through April 24, 2026 at 04:00 UTC

Prepared: July 26, 2026

API: api.canton.noves.fi

API docs: docs.noves.fi

Query inputs

Each time-bounded request used:

startTimestamp=1773547200
endTimestamp=1777003200

These values represent:

start: 2026-03-15T04:00:00Z
end:   2026-04-24T04:00:00Z

The requests used the canton chain and these parties:

provider:
excellar-issuer::12203d1e36930ee0e3fbb898add7e222a47ae9d2a5f0f6187e3a446ea32f871ce2ca

validator:
excellar-validator-2::12203d1e36930ee0e3fbb898add7e222a47ae9d2a5f0f6187e3a446ea32f871ce2ca

named third party:
fulcrum-point::1220b75e7270e4e28e72b1ae678a3cd64194d32593924d2f76daebd5bc7024249064

Noves endpoints used

The audit used the following endpoints and parameters. For
paginated routes, each request after page one supplied the preceding response's
nextCursor.

Noves API endpoint	Query parameters	Evidence used
GET /canton/featuredApps/{providerParty}/config	none	Featured App name and provider, beneficiary, validator, and confirmer parties
GET /canton/featuredApps/{providerParty}/activity/markers	startTimestamp=1773547200, endTimestamp=1777003200, bucketHours=720	Marker weight, featured transfer count, and app activity weight
GET /canton/featuredApps/{providerParty}/activity/verdicts	startTimestamp=1773547200, endTimestamp=1777003200, bucketHours=720	Verdict totals used in the compliance calculation
GET /canton/featuredApps/{providerParty}/activity/verdicts/submitters	startTimestamp=1773547200, endTimestamp=1777003200, bucketHours=720	Submitter attribution and validator ownership
GET /canton/featuredApps/{providerParty}/compliance/ratio	startTimestamp=1773547200, endTimestamp=1777003200, bucketHours=720	Compliance model, denominator, traffic spend, allowance, and ratio
GET /canton/featuredApps/{providerParty}/activity/rewards	startTimestamp=1773547200, endTimestamp=1777003200	App reward count, CC amount, and recorded USD value
GET /canton/featuredApps/{providerParty}/activity/burn	startTimestamp=1773547200, endTimestamp=1777003200, pageSize=500, sort=asc, then cursor=<nextCursor>	All traffic purchase rows and their CC, USD, and traffic-unit totals
GET /canton/burn/{validatorParty}	startTimestamp=1773547200, endTimestamp=1777003200, pageSize=500, sort=asc, includeTotals=true, then cursor=<nextCursor>	All quantified CC burns and source totals

In the table, {providerParty} is the full Excellar issuer party above and
{validatorParty} is the full Excellar validator party.

Reproduced results

Measurement	Noves API result
Featured App marker weight	4,051,193.00
Third-party-submitted verdicts	256,274
Validator-submitted verdicts	627,237
Total verdicts	883,511
Traffic spend attributed to the Featured App	$1,462,050.00
Free traffic allowance	$34,160.00
App rewards received	14,894,688.02 CC
Recorded USD value of those rewards	$2,203,135.33
Traffic purchases count	9,566
Traffic purchases total burn	9,885,929.51 CC
Total quantified burns by the validator	9,885,932.82 CC
App rewards less burn	5,008,758.52 CC
Asset issuer compliance ratio	15.81

Traffic purchases

Check	Result
Pages	20
Rows	9,566
Unique update IDs	9,566
Burn	9,885,929.51 CC
Traffic spend	$1,462,050.00
Traffic units	24,367,500,000
First purchase	2026-03-23T04:45:19.33Z
Last purchase	2026-04-23T14:28:19.55Z

Reward weight vs CC rewards (important distinction)

The reinstatement request describes 14,894,688.00 as reward weight. Note that reward weight means "marker weight" and that is not the same as the amount of Canton Coin received from app rewards. So that is a terminology error.

The correct marker weight measurement is 4,051,193.00 units of marker weight, which led to app rewards of 14,894,688.02 CC.

marker weight -> reward coupons -> redeemed CC

From that total of app rewards, we must subtract what was paid in traffic purchases.

The API returns 9,885,929.51 CC as the total burn by
excellar-validator-2. Subtracting that burn from app rewards gives us
5,008,758.52 CC.

Third-party activity

The official guidance (based on the SQL queries provided in the official guidance document) states that for an asset issuer, the way of determining "third party updates" that count toward valid marker weight are:

Any submissions that were submitted by a party that is not in the same namespace as the asset issuer's namespace, and were confirmed by the asset issuer.

Based on that definition, we see the following:

third-party-submitted verdicts: 256,274
validator-submitted verdicts:   627,237

The submitter endpoint attributed:

Submitting party	Verdicts	Validator owned
excellar-issuer	603,507	yes
excellar-validator-2	23,722	yes
fulcrum-point	465	no

Per this data, parties in Excellar's
validator submitted most of the verdicts in the results.

Overage under two policy interpretations

If there's an additional complexity of the app needing to be measured both as a "regular app" (compliance ratio based on burn) and as an "asset issuer app" (compliance ratio based on third-party updates), we can try to estimate the overage incurred in each case.

Regular app ratio

Treat one dollar of paid traffic as support for one unit of marker weight:

marker weight:                 4,051,193.00
paid traffic support:          1,462,050.00
unsupported marker weight:     2,589,143.00
unsupported share:                   63.91%

Include the $34,160.00 free traffic allowance:

supported marker weight:       1,496,210.00
excess marker weight:          2,554,983.00
excess share:                         63.07%
marker-to-supported-traffic ratio:     2.71x

Asset issuer rule

Treat one qualifying third-party-submitted verdict as support for one unit of
marker weight:

marker weight:                 4,051,193.00
third-party-submitted verdicts:     256,274
excess marker weight:          3,794,919.00
excess share:                         93.67%
marker-to-third-party ratio:           15.81x

[amit-excellar]

Updated at Aki's request to incorporate the corrected period figures (weight vs CC), the quantified excess computation now before the Committee, verified figures for the compliance submissions, and a more precise cause description.