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 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/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 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