From 87c6af31e454d8fc8a451660fc57f98b92ec89fc Mon Sep 17 00:00:00 2001 From: Amanda L Martin Date: Tue, 16 Jun 2026 17:37:41 -0400 Subject: [PATCH 1/4] Add CODEOWNERS --- .github/CODEOWNERS | 1 + 1 file changed, 1 insertion(+) create mode 100644 .github/CODEOWNERS diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS new file mode 100644 index 0000000..c084264 --- /dev/null +++ b/.github/CODEOWNERS @@ -0,0 +1 @@ +* @canton-foundation/admins From ed646b3c63fbd3152d04616891be4997a3e70985 Mon Sep 17 00:00:00 2001 From: pedrodneves Date: Thu, 25 Jun 2026 11:39:41 +0100 Subject: [PATCH 2/4] Create FA Reinstatement Request.md (#1) Signed-off-by: pedrodneves --- FA Reinstatement Request.md | 138 ++++++++++++++++++++++++++++++++++++ 1 file changed, 138 insertions(+) create mode 100644 FA Reinstatement Request.md diff --git a/FA Reinstatement Request.md b/FA Reinstatement Request.md new file mode 100644 index 0000000..9271797 --- /dev/null +++ b/FA Reinstatement Request.md @@ -0,0 +1,138 @@ +## Featured App Reinstatement Request + +### Summary + +This document sets out your request for reinstatement: what led to the pause, the corrective measures taken and the basis on which your application will operate in compliance going forward. Figures are requested at specific points, but the committee assesses the request as a whole. +Completing this document does not require technical expertise. The on-chain figures requested can be drawn from the public explorers listed in section 8, and the ecosystem partners referenced there can assist where help is needed to collect or interpret them. Where a field does not apply, state N/A with a brief reason. +Submit as a pull request adding `reinstatement/-.md`. + +## 1. Applicant details + +- Organisation name: +- Link to the tokenomics-list email announcing the pause: +- Date of pause (UTC): +- Your current stage (select one): + - Freshly paused, seeking reinstatement + - Mid-appeal, disputing the basis of the pause + - Already reinstated, lock outstanding (complete sections 2 and 10 only) +- Does your application share a participant node with other Featured Apps? If yes, complete section 8. + + +## 2. On-chain identifiers + +List exactly as they appear on-chain; any discrepancy prevents verification. + +- Party identifier(s) of the Featured App, one line per party where the application runs more than one: +- Party receiving app rewards: +- Party (or parties) of the validator node: +- Any further parties used to submit transactions: + +Separation of functions: where your application performs more than one major function (asset issuance, wallet, DEX, custody, lending, payment processing), confirm each function operates under a separate PartyId, as section 10 of the guidance requires. This applies to all multi-function applications, not only asset issuers. For asset issuers, separation of the issuer party is mandatory. +- Functions performed and the party each operates under: +- Confirmation of separation, or the structure being adopted to achieve it: + + +## 3. Basis of the pause + +State your understanding of the basis for the pause, then the underlying figures. + +Reward weight is requested in two forms. State both, and explain any difference: +- Reward weight submitted over the period, in USD (the activity markers actually submitted, each one dollar of reward weight): +- Reward weight you contend is eligible over the period, in USD, with the basis for any difference from the submitted figure: +- Fees paid over the same period, in USD (traffic purchased to support activity): +- Period covered (start and end, UTC): + +Per-party breakdown: where your application runs more than one Featured App party, give reward weight and fees paid for each party separately, since each party is measured against its own fees. +- Per party: party identifier, reward weight submitted, fees paid, resulting ratio: + +The principle is that claimed reward weight should not exceed paid fees. Where it did, that ratio forms the basis of the pause. + +If you consider the pause-notice figures incorrect, give your own calculation and identify where the original diverges. Corrective action after the pause does not affect its validity, so complete this only where raising a genuine calculation issue. + + +## 4. Cause + +Describe the specific mechanism behind the issue, meaning what your systems actually did. A soft launch or testing phase does not identify a cause. + +Complete the relevant part: + +If paused for claimed rewards exceeding paid fees: +- The process or automation that generated the excess markers, and its rule: +- Why it produced more reward weight than paid fees supported: + +If paused for marking own or related-party activity: +- The activity marked, its approximate volume and period: +- How own activity is now distinguished from genuine third-party use: + +If paused on structural grounds (multiple functions on one party): +- The functions that shared the party: +- The structure being adopted: + + +## 5. Corrective measures + +List each measure, its effect and the date or round it applied from. Each should be verifiable on-chain using the identifiers in section 2. For marker automation, state the rule the system now follows. + +Burning of excess: the excess reward weight that gave rise to the pause must be burned. State the quantity of excess to be burned, with the calculation and supporting data showing how it was derived, and provide the transaction hash in which the burn was carried out. +- Excess quantity burned, with calculation and supporting data: +- Transaction hash of the burn: + +## 6. Data discrepancies + +Complete only if your figures rely on, or are disputed by, a difference between explorers or data sources. A discrepancy between sources is a data issue and not in itself evidence of an overage. +- The explorer or source in question: +- What it misclassifies or reports differently: +- The corrected figure and how it was derived: +- The second source corroborating the corrected figure: + + +## 7. Basis for continued compliance + +This section carries the most weight. Set out: +- The function your application serves for the network and its users: +- The compliance rule the application now operates under, stated as a commitment: +- The monitoring in place to detect future deviation before it becomes an enforcement matter: +- Whether you rely on any prior committee guidance relevant to this request, from whom it came, and whether it was communicated formally (ruling, official channel) or informally: +- Whether you consent to a follow-up review a defined period after reinstatement (recommended): + +Evidence of genuine usage may be included (active wallet counts, third-party transaction volumes, integrations). + + +## 8. Shared participant node + +Separate parties on one participant: where co-located applications run under distinct PartyIds, coverage can be attributed to each party from the data. State each party's reward weight and attributable fees so each ratio can be read individually. +- All Featured App parties on the participant, with each party's reward weight and attributable fees: + +Multiple functions on one party: where more than one function runs under a single PartyId, neither the markers nor the traffic can be separated by function, so no per-function ratio exists. This requires separation into distinct parties, as section 10 of the guidance requires. Confirm separation, or state the structure being adopted to achieve it. +- Functions sharing a single party, and the separation being adopted: + +Asset issuers sharing a party with other functions must separate them. Confirm this is done, or state the exception relied upon. + + +## 9. Sources and explorers +The figures requested above can be collected from public block explorers. Where sources diverge, state which you have relied on and why in section 6. +- CCView: [https://ccview.io/](https://ccview.io/) +- Cantonloop Lighthouse: [https://lighthouse.cantonloop.com/](https://lighthouse.cantonloop.com/) +- Transparent Scan: [https://transparentscan.xyz/](https://transparentscan.xyz/) +- RIZEScore by T-RIZE (beta): [https://www.t-rize.io/](https://www.t-rize.io/) +- GSF monitoring query: available from the Foundation on request. +- Canton ecosystem directory, to find entities in the ecosystem that can assist with collecting data: [https://www.cantonecosystem.com/](https://www.cantonecosystem.com/) + +## 10. Locking + +Reinstatement is subject to the CIP-0116 lock: 5 million CC for featured apps, 25 million CC for issuers. Funds need not be locked at submission but must be segregated and available. Verification precedes reinstatement. + +- Amount segregated: +- Who holds the lock: the applicant, or a third party (name them): +- The executed lock instrument and its current status (for example signed, or pending signature). Reinstatement is not finalised until it shows complete: +- Location of the funds (party or address for verification): +- Confirmation the lock will be completed as a condition of reinstatement: + +## 11. Exception request (asset issuers only) + +Complete only if requesting an exception to the rule against marking use of your own asset within your own venue. Decided case by case; a complete submission is required. Include: +- The exact exception requested: +- The circumstances, stated factually: +- Why granting it would not undermine the purpose of the rule: +- Where the excess resulted from a software defect rather than a policy choice, the proposed remedy: burning the excess markers, or redistributing their value across the featured app pool at the relevant time. + From 9abfd5a7bc20a43edd73e935495a184f705b87f2 Mon Sep 17 00:00:00 2001 From: pedrodneves Date: Thu, 25 Jun 2026 13:15:02 +0100 Subject: [PATCH 3/4] Move FA Reinstatement Request.md to .github folder (#2) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit * Move FA Reinstatement Request.md to .github folder * split up files for workflow --------- Co-authored-by: “pedrodneves” <“pedro@canton.foundation”> Co-authored-by: Amanda L Martin --- .github/pull_request_template.md | 49 ++++ FA Reinstatement Request.md | 138 ----------- README.md | 218 +++++++++++++++++- .../featured-app-reinstatement-request.md | 194 ++++++++++++++++ 4 files changed, 459 insertions(+), 140 deletions(-) create mode 100644 .github/pull_request_template.md delete mode 100644 FA Reinstatement Request.md create mode 100644 reinstatement/featured-app-reinstatement-request.md diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md new file mode 100644 index 0000000..f316961 --- /dev/null +++ b/.github/pull_request_template.md @@ -0,0 +1,49 @@ +# 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: + +```text +reinstatement/-.md +``` + +The request should be prepared using: + +```text +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. diff --git a/FA Reinstatement Request.md b/FA Reinstatement Request.md deleted file mode 100644 index 9271797..0000000 --- a/FA Reinstatement Request.md +++ /dev/null @@ -1,138 +0,0 @@ -## Featured App Reinstatement Request - -### Summary - -This document sets out your request for reinstatement: what led to the pause, the corrective measures taken and the basis on which your application will operate in compliance going forward. Figures are requested at specific points, but the committee assesses the request as a whole. -Completing this document does not require technical expertise. The on-chain figures requested can be drawn from the public explorers listed in section 8, and the ecosystem partners referenced there can assist where help is needed to collect or interpret them. Where a field does not apply, state N/A with a brief reason. -Submit as a pull request adding `reinstatement/-.md`. - -## 1. Applicant details - -- Organisation name: -- Link to the tokenomics-list email announcing the pause: -- Date of pause (UTC): -- Your current stage (select one): - - Freshly paused, seeking reinstatement - - Mid-appeal, disputing the basis of the pause - - Already reinstated, lock outstanding (complete sections 2 and 10 only) -- Does your application share a participant node with other Featured Apps? If yes, complete section 8. - - -## 2. On-chain identifiers - -List exactly as they appear on-chain; any discrepancy prevents verification. - -- Party identifier(s) of the Featured App, one line per party where the application runs more than one: -- Party receiving app rewards: -- Party (or parties) of the validator node: -- Any further parties used to submit transactions: - -Separation of functions: where your application performs more than one major function (asset issuance, wallet, DEX, custody, lending, payment processing), confirm each function operates under a separate PartyId, as section 10 of the guidance requires. This applies to all multi-function applications, not only asset issuers. For asset issuers, separation of the issuer party is mandatory. -- Functions performed and the party each operates under: -- Confirmation of separation, or the structure being adopted to achieve it: - - -## 3. Basis of the pause - -State your understanding of the basis for the pause, then the underlying figures. - -Reward weight is requested in two forms. State both, and explain any difference: -- Reward weight submitted over the period, in USD (the activity markers actually submitted, each one dollar of reward weight): -- Reward weight you contend is eligible over the period, in USD, with the basis for any difference from the submitted figure: -- Fees paid over the same period, in USD (traffic purchased to support activity): -- Period covered (start and end, UTC): - -Per-party breakdown: where your application runs more than one Featured App party, give reward weight and fees paid for each party separately, since each party is measured against its own fees. -- Per party: party identifier, reward weight submitted, fees paid, resulting ratio: - -The principle is that claimed reward weight should not exceed paid fees. Where it did, that ratio forms the basis of the pause. - -If you consider the pause-notice figures incorrect, give your own calculation and identify where the original diverges. Corrective action after the pause does not affect its validity, so complete this only where raising a genuine calculation issue. - - -## 4. Cause - -Describe the specific mechanism behind the issue, meaning what your systems actually did. A soft launch or testing phase does not identify a cause. - -Complete the relevant part: - -If paused for claimed rewards exceeding paid fees: -- The process or automation that generated the excess markers, and its rule: -- Why it produced more reward weight than paid fees supported: - -If paused for marking own or related-party activity: -- The activity marked, its approximate volume and period: -- How own activity is now distinguished from genuine third-party use: - -If paused on structural grounds (multiple functions on one party): -- The functions that shared the party: -- The structure being adopted: - - -## 5. Corrective measures - -List each measure, its effect and the date or round it applied from. Each should be verifiable on-chain using the identifiers in section 2. For marker automation, state the rule the system now follows. - -Burning of excess: the excess reward weight that gave rise to the pause must be burned. State the quantity of excess to be burned, with the calculation and supporting data showing how it was derived, and provide the transaction hash in which the burn was carried out. -- Excess quantity burned, with calculation and supporting data: -- Transaction hash of the burn: - -## 6. Data discrepancies - -Complete only if your figures rely on, or are disputed by, a difference between explorers or data sources. A discrepancy between sources is a data issue and not in itself evidence of an overage. -- The explorer or source in question: -- What it misclassifies or reports differently: -- The corrected figure and how it was derived: -- The second source corroborating the corrected figure: - - -## 7. Basis for continued compliance - -This section carries the most weight. Set out: -- The function your application serves for the network and its users: -- The compliance rule the application now operates under, stated as a commitment: -- The monitoring in place to detect future deviation before it becomes an enforcement matter: -- Whether you rely on any prior committee guidance relevant to this request, from whom it came, and whether it was communicated formally (ruling, official channel) or informally: -- Whether you consent to a follow-up review a defined period after reinstatement (recommended): - -Evidence of genuine usage may be included (active wallet counts, third-party transaction volumes, integrations). - - -## 8. Shared participant node - -Separate parties on one participant: where co-located applications run under distinct PartyIds, coverage can be attributed to each party from the data. State each party's reward weight and attributable fees so each ratio can be read individually. -- All Featured App parties on the participant, with each party's reward weight and attributable fees: - -Multiple functions on one party: where more than one function runs under a single PartyId, neither the markers nor the traffic can be separated by function, so no per-function ratio exists. This requires separation into distinct parties, as section 10 of the guidance requires. Confirm separation, or state the structure being adopted to achieve it. -- Functions sharing a single party, and the separation being adopted: - -Asset issuers sharing a party with other functions must separate them. Confirm this is done, or state the exception relied upon. - - -## 9. Sources and explorers -The figures requested above can be collected from public block explorers. Where sources diverge, state which you have relied on and why in section 6. -- CCView: [https://ccview.io/](https://ccview.io/) -- Cantonloop Lighthouse: [https://lighthouse.cantonloop.com/](https://lighthouse.cantonloop.com/) -- Transparent Scan: [https://transparentscan.xyz/](https://transparentscan.xyz/) -- RIZEScore by T-RIZE (beta): [https://www.t-rize.io/](https://www.t-rize.io/) -- GSF monitoring query: available from the Foundation on request. -- Canton ecosystem directory, to find entities in the ecosystem that can assist with collecting data: [https://www.cantonecosystem.com/](https://www.cantonecosystem.com/) - -## 10. Locking - -Reinstatement is subject to the CIP-0116 lock: 5 million CC for featured apps, 25 million CC for issuers. Funds need not be locked at submission but must be segregated and available. Verification precedes reinstatement. - -- Amount segregated: -- Who holds the lock: the applicant, or a third party (name them): -- The executed lock instrument and its current status (for example signed, or pending signature). Reinstatement is not finalised until it shows complete: -- Location of the funds (party or address for verification): -- Confirmation the lock will be completed as a condition of reinstatement: - -## 11. Exception request (asset issuers only) - -Complete only if requesting an exception to the rule against marking use of your own asset within your own venue. Decided case by case; a complete submission is required. Include: -- The exact exception requested: -- The circumstances, stated factually: -- Why granting it would not undermine the purpose of the rule: -- Where the excess resulted from a software defect rather than a policy choice, the proposed remedy: burning the excess markers, or redistributing their value across the featured app pool at the relevant time. - diff --git a/README.md b/README.md index 2a5fa90..f193ef2 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,216 @@ -# accountability -Accountability +# Accountability + +The Canton Accountability process supports transparent review and resolution of Featured App compliance matters. + +This repository is used to submit **Featured App reinstatement requests** through GitHub Pull Requests. + +--- + +## Overview + +The Accountability process helps ensure that Featured Apps operate in line with Canton ecosystem rules, guidance, and governance expectations. + +This process may be used when a Featured App has been paused or otherwise subject to review and seeks reinstatement. + +The process is designed to: + +* Provide a clear path for reinstatement requests +* Collect the information needed for committee review +* Allow on-chain activity to be verified using public data +* Support consistent treatment across Featured Apps +* Maintain transparency for the ecosystem + +Completing a reinstatement request does not require technical expertise. The on-chain figures requested can be drawn from the public explorers listed below, and ecosystem partners may assist where help is needed to collect or interpret the data. + +--- + +## What This Repository Is For + +This repository is used for: + +* Featured App reinstatement requests +* Appeals or disputes regarding the basis of a pause +* Compliance follow-up where reinstatement has occurred but requirements remain outstanding +* Supporting documentation for accountability review + +Each request should explain: + +* What led to the pause +* What corrective measures were taken +* What has changed to prevent recurrence +* The basis on which the application will operate in compliance going forward + +The committee assesses the request as a whole. Figures are requested at specific points, but no single section replaces the full review. + +--- + +## Who Should Submit + +A request may be submitted by: + +* The Featured App operator +* The organization responsible for the Featured App +* An authorized representative of the applicant + +If another party is submitting on behalf of the applicant, that relationship should be stated clearly in the request. + +--- + +## How to Submit a Reinstatement Request + +All reinstatement requests are submitted by Pull Request. + +### Step 1: Review the PR Template + +Use the Featured App Reinstatement Request template located at: + +```text +.github/pull_request_template.md +``` + +The template requests: + +* Applicant details +* On-chain identifiers +* Basis of the pause +* Cause of the issue +* Corrective measures +* Any data discrepancies +* Basis for continued compliance +* Shared participant node information, if applicable +* Locking status +* Any asset issuer exception request, if applicable + +Where a field does not apply, state `N/A` with a brief reason. + +--- + +### Step 2: Create Your Request + +1. Fork this repository +2. Create a new branch +3. Add your completed reinstatement request as a Markdown file under: + +```text +reinstatement/-.md +``` + +Use the application name and submission date in the file name. + +Example: + +```text +reinstatement/example-app-2026-06-25.md +``` + +--- + +### Step 3: Open a Pull Request + +Use the following title format: + +```text +Reinstatement Request: +``` + +Once submitted, your request will enter the review process. + +--- + +## Review Process + +The review process generally includes: + +1. **Completeness review** + The submission is checked for required fields, identifiers, and supporting information. + +2. **Data verification** + On-chain identifiers, reward weight, fees, burns, locking status, and other figures are reviewed against available public sources. + +3. **Committee review** + The committee reviews the cause, corrective measures, and basis for continued compliance. + +4. **Follow-up questions** + The committee may request clarifications or additional data through the Pull Request. + +5. **Decision** + The committee determines whether reinstatement should proceed, whether conditions must be satisfied first, or whether further action is required. + +Reinstatement is not finalized until all applicable requirements, including locking requirements, have been verified. + +--- + +## What Makes a Strong Request + +Strong reinstatement requests typically include: + +* A clear explanation of the cause of the issue +* Correct on-chain PartyIds and identifiers +* Reward weight and fee figures that can be independently verified +* A clear calculation of any excess reward weight +* Evidence that excess amounts were burned, where required +* Specific corrective measures with effective dates +* A compliance rule the application now follows +* Monitoring designed to detect future issues early +* Clear separation of functions where required +* Complete locking information under CIP-0116 + +--- + +## Locking Requirement + +Reinstatement is subject to the CIP-0116 lock requirement: + +* **5,000,000 CC** for Featured Apps +* **25,000,000 CC** for Issuer applications + +Funds do not need to be locked at the time of initial submission, but they must be segregated and available. Verification must occur before reinstatement is finalized. + +The lock may be held by the applicant or by a third party, but the lock must be attributable to the Featured App being reinstated. + +--- + +## Public Sources and Explorers + +The figures requested in the reinstatement template can be collected from public block explorers and ecosystem tools. + +Common sources include: + +* CCView: https://ccview.io/ +* Cantonloop Lighthouse: https://lighthouse.cantonloop.com/ +* Transparent Scan: https://transparentscan.xyz/ +* RIZEScore by T-RIZE: https://www.t-rize.io/ +* Canton ecosystem directory: https://www.cantonecosystem.com/ + +Where sources diverge, explain which source you relied on and why in the reinstatement request. + +The Foundation may also provide monitoring query support on request. + +--- + +## Confidentiality + +Submissions through this repository are public unless otherwise stated. + +Do not include confidential, proprietary, or sensitive information in a public Pull Request unless it is necessary for review and appropriate to disclose publicly. + +If private coordination is needed, contact the Foundation before submitting. + +--- + +## Questions + +For private questions about a reinstatement request or the submission process: + +Email: **[accountability-ops@lists.sync.global](mailto:accountability-ops@lists.sync.global +)** + +For broader ecosystem discussion: + +Email: **[accountability@lists.sync.global](mailto:accountability@lists.sync.global + +--- + +## Goal + +The goal of this process is to support fair, transparent, and consistent accountability review while allowing applications that have corrected issues to return to good standing. diff --git a/reinstatement/featured-app-reinstatement-request.md b/reinstatement/featured-app-reinstatement-request.md new file mode 100644 index 0000000..5681191 --- /dev/null +++ b/reinstatement/featured-app-reinstatement-request.md @@ -0,0 +1,194 @@ +# Featured App Reinstatement Request + +## Summary + +* Featured App name: +* Organization: +* Date of pause, UTC: +* Link to pause announcement: +* Current stage: + + * [ ] Freshly paused, seeking reinstatement + * [ ] Mid-appeal, disputing the basis of the pause + * [ ] Already reinstated, lock outstanding +* Primary basis of pause: + + * [ ] Claimed rewards exceeded paid fees + * [ ] Own or related-party activity was marked + * [ ] Multiple functions operated under one PartyId + * [ ] CIP-0116 lock outstanding + * [ ] Other: + +--- + +## Reinstatement Request File + +This Pull Request adds the completed reinstatement request at: + +```text id="xu6m4z" +reinstatement/-.md +``` + +The request should be prepared using: + +```text id="ip2q1b" +reinstatement/featured-app-reinstatement-request.md +``` + +--- + +## Key On-Chain Identifiers + +List the primary identifiers needed for review. Full details should be included in the reinstatement request file. + +* Featured App PartyId(s): +* Party receiving app rewards: +* Validator node PartyId(s): +* Other transaction-submitting PartyId(s), if applicable: + +--- + +## Applicant Position + +Briefly summarize the applicant’s position. + +* What caused the issue: +* What has been corrected: +* Date or round corrective measures took effect: +* Whether the applicant disputes the pause figures: + + * [ ] Yes + * [ ] No + +If yes, summarize the disputed calculation or source discrepancy: + +--- + +## Excess and Burn Status + +Complete if the pause involved excess claimed reward weight. + +* Excess amount identified: +* Excess amount burned: +* Burn transaction hash: +* If not yet burned, explain status: + +--- + +## Shared Participant Node / Party Structure + +* Does the application share a participant node with other Featured Apps? + + * [ ] Yes + * [ ] No + +If yes, confirm the reinstatement request includes per-party reward weight and attributable fees. + +* Does the application perform multiple major functions? + + * [ ] Yes + * [ ] No + +If yes, confirm whether each major function operates under a separate PartyId. + +* Separation complete: + + * [ ] Yes + * [ ] No + * [ ] Not applicable + +If not complete, summarize the separation plan: + +--- + +## Locking Status + +Reinstatement is subject to the CIP-0116 lock requirement. + +* Required lock amount: + + * [ ] 5,000,000 CC for Featured App + * [ ] 25,000,000 CC for Issuer +* Amount segregated: +* Lock holder: + + * [ ] Applicant + * [ ] Third party +* If third party, name: +* Lock status: + + * [ ] Complete + * [ ] Signed, pending completion + * [ ] Pending signature + * [ ] Not yet complete +* Party or address for verification: + +--- + +## Exception Request + +Complete only if requesting an exception. + +* Is an exception requested? + + * [ ] Yes + * [ ] No + +If yes: + +* Type of exception: + + * [ ] Asset issuer own-asset / own-venue marking exception + * [ ] Party structure exception + * [ ] Timing or implementation exception + * [ ] Other: +* Brief summary of exception requested: +* Basis for why the exception would not undermine the applicable rule: +* Proposed remedy, if applicable: + + * [ ] Burn excess markers + * [ ] Redistribute value across the Featured App pool + * [ ] Other: + +--- + +## Reviewer Notes + +Use this section for anything reviewers should pay special attention to, including: + +* Disputed calculations +* Explorer or data-source discrepancies +* Pending burn transaction +* Pending lock completion +* Shared participant node issues +* Related-party activity +* Prior committee guidance +* Follow-up review period + +--- + +## Checklist + +Before submitting, confirm: + +* [ ] The completed reinstatement request file is included +* [ ] All PartyIds are listed exactly as they appear on-chain +* [ ] The basis of the pause is explained +* [ ] The cause of the issue is described +* [ ] Corrective measures are described with effective dates or rounds +* [ ] Excess reward weight and burn status are documented, if applicable +* [ ] Data discrepancies are explained, if applicable +* [ ] Shared participant node details are included, if applicable +* [ ] Party/function separation is addressed, if applicable +* [ ] CIP-0116 locking status is included +* [ ] Any exception request is clearly identified, if applicable +* [ ] Any fields that do not apply are marked `N/A` with a brief reason + +Applicant Confirmation + +By submitting this request, the applicant confirms that the information provided is accurate to the best of its knowledge and that the applicant will provide clarifications or supporting information if requested by the committee. + +* Name: +* Title: +* Organization: +* Date: \ No newline at end of file From df4d564a54e2dad143f4282c7cf0fdfd46745951 Mon Sep 17 00:00:00 2001 From: Kenneth_AH Date: Tue, 30 Jun 2026 23:24:12 +0900 Subject: [PATCH 4/4] Add Kairo reinstatement request (#6) Signed-off-by: Kenneth_AH --- reinstatement/kairo-2026-06-30_final.md | 151 ++++++++++++++++++++++++ 1 file changed, 151 insertions(+) create mode 100644 reinstatement/kairo-2026-06-30_final.md diff --git a/reinstatement/kairo-2026-06-30_final.md b/reinstatement/kairo-2026-06-30_final.md new file mode 100644 index 0000000..b284dd3 --- /dev/null +++ b/reinstatement/kairo-2026-06-30_final.md @@ -0,0 +1,151 @@ +# Kairo Featured App Reinstatement Request + +**Applicant:** Angelhack Pte Ltd | Operating Kairo + +--- + +## 1. Applicant details + +- **Organisation name:** Angelhack Pte Ltd (operating the Kairo RFQ DEX on Canton mainnet) +- **Link to the tokenomics-list email announcing the pause:** https://lists.sync.global/g/tokenomics/message/1189?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C%2Ckairo%2C20%2C2%2C0%2C119617380 +- **Date of pause (UTC):** 2026-06-03T15:24:13.141060Z +- **Does your application share a participant node with other Featured Apps?** No. Kairo operates on its own dedicated participant nodes; there is no Featured App co-location. Section 7 therefore does not apply. + +## 2. On-chain identifiers + +**Party identifier of the Featured App:** + +``` +kairo-mainnet::12205162445638c3f71c9942b74360134b4ebc953b5bea2c25adc99bff130bffd060 +``` + +**Party (or parties) of the validator node:** + +``` +angelhack-mainnet-1::12205162445638c3f71c9942b74360134b4ebc953b5bea2c25adc99bff130bffd060 +``` + +**Any further parties used to submit transactions and markers** (swap incurs burn on these nodes; these nodes do not submit any markers as they are the liquidity providers for Kairo RFQ DEX): + +``` +qcpTradingPteLtd-validator-1::1220b73de17e79b85c1ac1c07a1176b6fa6c06177ebc9d1e03d71fc9020b4672180d +qcpTradingME-validator-1::1220e60b65a78f0d23a2eadc6bc55b51c52bf148b988db559fbb880964ad102df85c +primroseCapital-walletHostingMainNet-1::1220f7ecd95d1f40ba91a3a8106348d280ad1250437fce34cafd4368246fae39c806 +qcp-wallet-hosting-mainnet-1::12200e37ac6b165ebd4b09c4d74476234791031a6a92e1afe5a38ef3dc2b667a4948 +``` + +**Asset issuers — confirmation:** N/A. Kairo is not an asset issuer. The DEX routes bilateral swaps between counterparties holding pre-existing on-chain assets ($CC, $CBTC, $USDCx). No issuer function is combined with the venue, wallet, market-making, lending or payment-processing functions. + +## 3. Basis of the pause + +- **Reward weight claimed over the period, in USD:** Reflected in the compliance report filed 9 June 2026. The numerator (marker activity) was within tolerance throughout the affected window. The pause was driven by a denominator-side data error, not a numerator-side over-issuance. +- **Fees paid over the same period, in USD:** As above — see the compliance report and CC.view for verifiable on-chain figures. Once the two typo'd LP validator Party IDs were corrected and their purchased synchronizer traffic re-included, the FA Marker Guidance ratio sits at approximately **1.10** across the affected window — within the 1.15 precision tolerance. +- **Period covered (start and end, UTC):** 19 May 2026 – 3 June 2026 + +**Kairo's understanding of the basis.** On 3 June 2026, Kairo's FA Marker Guidance ratio appeared to exceed the 1.15 precision tolerance for the trailing 30-day window. + +The on-paper ratio of approximately **1.4** was driven by a clerical data-entry error: two LP validator Party IDs that Kairo had submitted to CC.view on 19 May 2026 for traffic attribution contained a typo. The error caused those validators' purchased synchronizer traffic to be excluded from Kairo's attributed traffic — **understating the denominator** of the Marker Guidance ratio and inflating the ratio on paper. + +Once the Party IDs were corrected and the traffic re-included (verified by @alexei.dulub on 3 June against the IDs Kairo had shared in advance), the ratio sits at approximately **1.10** across the full period — within tolerance. The corrected data is verifiable on-chain. + +**This was a denominator-side data error, not a numerator-side over-issuance.** Kairo received no excess CC; network issuance per round was unaffected; no other Featured App was advantaged or disadvantaged. There is nothing to claw back and nothing to redistribute. + +## 4. Cause + +**Primary basis — apparent ratio above tolerance, driven by a denominator-side data error.** + +**The process or automation that generated the excess markers, and its rule:** No automation generated excess markers. Kairo's marker activity for the affected window was correct and within tolerance throughout. The apparent excess in the ratio was a function of the *denominator*: synchronizer traffic purchased by Kairo's nodes and its dedicated LP validator nodes, two of which were excluded from attribution by a clerical typo at submission to CC.view. + +**Why it produced more reward weight than paid fees supported:** Two LP validator Party IDs submitted to CC.view on 19 May 2026 for traffic attribution contained a typo: + +``` +qcpTradingPteLtd-validator-1::1220b73de17e79b85c1ac1c07a1176b6fa6c06177ebc9d1e03d71fc9020b4672180d +qcpTradingME-validator-1::1220e60b65a78f0d23a2eadc6bc55b51c52bf148b988db559fbb880964ad102df85c +``` + +The attribution system did not match the purchased synchronizer traffic of those validators to Kairo's denominator. The traffic was real and on-chain; only the registration that mapped it to Kairo's Featured App was misspelled. With the Party IDs corrected and the traffic re-included, the corrected ratio across the affected window is approximately **1.10** — within the 1.15 tolerance. + +**Five Whys — root cause** + +1. *Why was Kairo's ratio above the 1.15 tolerance?* LP validators' purchased traffic was missing from Kairo's attributed traffic, deflating the denominator. +2. *Why was that traffic missing?* The Party IDs had been submitted with a typo, so the attribution system did not match their traffic to Kairo. +3. *Why did a single typo silently exclude a validator's entire traffic contribution?* Attribution is currently submitted manually and self-reported, with no validation of submitted Party IDs against on-chain settlement at the point of entry. +4. *Why is attribution manual and self-reported?* There is no systematic channel or registry for FAs to declare and maintain validator relationships, and no automated reconciliation against the ledger. +5. *Why is there no such channel or registry?* The current participant model assumed simpler single-party FAs. There is no interim framework governing attribution for multi-party / external-validator venues (RFQ DEXs), and the native solution (CIP-0104) is not yet live. + +**Root cause:** the typo is the proximate cause but is itself a symptom. The root cause is the absence of a verified, systematic attribution mechanism for multi-party Featured Apps in the interim period before CIP-0104. The metric currently depends on error-prone, unverifiable self-attestation, which is fragile in both directions: it under-counted Kairo in this instance, and — as the committee has noted — it could be over-claimed by a bad actor elsewhere. + +## 5. Corrective measures + +- **Corrected validator registry submitted through a single channel of record** (effective 3 June 2026). The four dedicated LP validator nodes serving Kairo's RFQ DEX are listed in Section 2, each with the verified Party ID. Verifiable on-chain. +- **Pre-reporting Party ID validation against the ledger.** Kairo will re-confirm every submitted LP validator Party ID against the ledger before each reporting period to prevent any recurrence of a clerical mismatch. The validation step is deterministic and automated. +- **Per-transaction on-chain attribution verification.** Every Kairo-routed swap exercises Daml templates from the Kairo DAR (`kairo-dex-simple-escrow`) and discloses Kairo's `FeatureAppRight` in the commit. Attribution is mechanically determined by the disclosure stamped onto each transaction — not by self-report. Activity on these validators that exercises non-Kairo templates carries no Kairo `FeatureAppRight` and accrues no attribution to Kairo, so the boundary is self-enforcing. +- **Proposed interim attribution standard for multi-party Featured Apps** (bridge until CIP-0104): + - *Mapping* — validators that attribute to a given FA, declared through one channel/registry. + - *Verification* — validated against on-chain settlement and the beneficiary test (`FeatureAppRight` + DAR), not self-attestation. A validator's traffic counts for an FA only where the transaction discloses that FA's `FeatureAppRight` and exercises templates from that FA's DAR. + - *Maintenance* — timestamped, auditable updates so an error or relationship change is caught in days, not at audit time. + + Kairo asks to be held to the strict version of this standard and is happy to be the first venue tested against any draft. +- **Verification offer.** Kairo invites the committee and data providers (CC.view, Noves) to verify, per transaction, that the traffic attributed from these nodes settles through Kairo as the venue/counterparty. The ledger is the source of truth. +- **Supporting technical documentation.** A 6-slide architecture primer that describes the RFQ flow end-to-end and the FA marker attribution chain via `FeatureAppRight` + DAR, with a worked reference swap (0.1 CBTC → USDCx via QCP-LP) was shared with the Tokenomics and Accountability working groups: https://drive.google.com/drive/folders/1wW-NoR9dGc8eNYpqOVS8BIfm1GD-hKkB?usp=sharing + +## 6. Basis for continued compliance + +**The function the application serves for the network and its users:** Kairo is a request-for-quote (RFQ) decentralised exchange operating on Canton Network. A single Kairo-routed swap's value is produced by multiple independent parties acting together — Kairo's swap layer plus the liquidity-provider validators that quote into it. The LP validators are not an add-on or a workaround; they are how the venue functions. Without them, there is no liquidity and no transaction. Kairo provides Canton with a settlement-grade institutional venue — privacy-preserving, MEV-free, with atomic DVP settlement and deterministic execution (quote = settle). The architecture matches Canton's design philosophy of named parties + subtransaction privacy + atomic settlement. + +**The compliance rule the application now operates under, stated as a commitment:** Kairo commits that its FA Marker Guidance ratio will remain within the 1.15 precision tolerance over any trailing 30-day window. Attribution will be mechanically determined by on-chain disclosure (`FeatureAppRight` + DAR beneficiary test), not by self-attestation. Submitted LP validator Party IDs will be pre-validated against the ledger before every reporting period. Markers are never submitted for self-transactions, related-party transactions or test transactions on mainnet. + +**The monitoring in place to detect future deviation before it becomes an enforcement matter:** + +- Pre-reporting validation of every submitted LP validator Party ID against the ledger; mismatch alerts before any submission to CC.view. +- Per-transaction beneficiary-test verification offered to CC.view, Noves, and the committee — every Kairo-attributed transaction can be checked against `FeatureAppRight` + DAR disclosure on-chain. +- Automated alert on FA Marker Guidance ratio deviation greater than 5% within a rolling 7-day window, with operator review before any further submission. +- Public party identifiers (Section 2) allowing third-party verification via CC.view and Cantonloop Lighthouse at any time. + +**Whether you consent to a follow-up review a defined period after reinstatement:** Yes. Kairo consents to a follow-up review three months after reinstatement, covering the first full quarter post-reinstatement, with a summary submitted to Tokenomics & Accountability. + +**Kairo also agrees to Tokenomics' request of:** + +- Maker (0.5 bps) and Taker (10 bps) fees charged in full at time of order submission +- Maker rebate programs allowable UP TO cost reimbursement to maker +- Taker rebate programs allowable UP TO 10c of net cost for taker +- Rebates on a 30 day delay (minimum) + +Our plan is to shut down the wallet service temporarily until CIP-104 and migrate users onto live external wallets (e.g. Loop, Cantex, etc.) as we're CIP-103 and wallet-connect enabled and ready to deploy external wallet SDKs. + +Kairo is committed to keeping things as clean as possible so we don't run into future issues prior to CIP-104 and ensure that we're compliant with the FA framework and guidance. + +## 7. Shared participant node + +N/A. Kairo does not share a participant node with other Featured Apps. The validator parties listed in Section 2 are dedicated to Kairo's RFQ matching and settlement operation. + +## 8. Sources and explorers + +Kairo will reference **CC View** and **Cantonloop Lighthouse** as the primary sources for marker accrual and $CC burn figures. Where the two diverge on a specific transaction, Kairo will note the divergence in its reconciliation report and identify the source relied upon, treating any discrepancy as a data issue rather than evidence of an overage. + +## 9. Locking + +- **Amount segregated:** 5,000,000 $CC (Featured App lock requirement per CIP-0116). +- **Location of the funds (party or address for verification):** + + ``` + 12204a89b2fe76790eae7d8849e70dcda918f64fc5de82dfcd51de6d97135ee963dd::12207159611cf1666abe62b24f562221e928156daa2b41cd184b6d69920dcf8e5e1b + + https://lighthouse.cantonloop.com/party/12204a89b2fe76790eae7d8849e70dcda918f64fc5de82dfcd51de6d97135ee963dd%3A%3A12207159611cf1666abe62b24f562221e928156daa2b41cd184b6d69920dcf8e5e1b + ``` +- **Confirmation the lock will be completed as a condition of reinstatement:** Confirmed and locked as seen in the Party ID above. Angelhack has segregated and locked the 5,000,000 $CC at the verifiable on-chain location for the CIP-0116 lock. + +## 10. Exception request (asset issuers only) + +N/A. Kairo is not an asset issuer; the DEX does not issue any token. No exception to the issuer rule is required or requested. + +--- + +## Applicant Confirmation + +By submitting this request, the applicant confirms that the information provided is accurate to the best of its knowledge and that the applicant will provide clarifications or supporting information if requested by the committee. + +- **Name:** Kenneth Tay +- **Title:** Head of Special Projects +- **Organization:** Angelhack Pte Ltd +- **Date:** 30 June 2026