Add Cancore reinstatement request

[mikeshukshin]

Featured App Reinstatement Request

Summary

• Featured App name: Cancore

• Organization: CoreOps Digital Corporation (dba Cancore)

• Date of pause, UTC: 2026-07-02

• Link to pause announcement: https://lists.sync.global/g/tokenomics-announce/message/356

• 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:

We do not dispute the pause. A separate structural item (venue/HTLC-escrow/fee/executor sharing one venue party on mainnet) is disclosed in the request file but is not a basis of the pause.

---

Reinstatement Request File

This Pull Request adds the completed reinstatement request at:

reinstatement/cancore-2026-07-03.md

Prepared using:

reinstatement/featured-app-reinstatement-request.md

---

Key On-Chain Identifiers

• Featured App PartyId(s): Cancore-mainnet-1::1220076a94e0a7f0256a32ffab227db7788d8075677d8afcdaa8386df8f2fa659906
• Party receiving app rewards: Cancore-mainnet-1::…659906 (same party; sole beneficiary)
• Validator node PartyId(s): Cancore-mainnet-1::…659906 (single node; MARKERS_PROVIDER_PARTY_ID = TRAFFIC_MEMBER_PARTY_ID)
• Other transaction-submitting PartyId(s): venue cancore::…659906; 18 company market-making bot parties (§2); ~4,600 hosted end-user wallet parties; 38 external partner-integration accounts (counted as third-party usage).

---

Applicant Position

• What caused the issue: our marker pipeline claimed reward weight on the on-chain fees generated by our own automated market-making (liquidity bootstrapping for a new cross-chain venue) without excluding related-party swaps. ~96% of submitted markers (by fee basis) came from internal bot-vs-bot volume, driving the cumulative ratio to ≈1.59 against the 1.15 limit.

• What has been corrected: marker claiming stopped (2026-07-02 16:28 UTC); all internal market-making strategies disabled (2026-07-02 16:33 UTC); reward-sweep stopped (2026-07-03). A fail-closed, in-pipeline exclusion of own-account swaps is being implemented before any re-enablement.

• Date or round corrective measures took effect: 2026-07-02 (markers + market-making off); 2026-07-03 (reward sweep off).

• Whether the applicant disputes the pause figures:

  • Yes
  • No

---

Excess and Burn Status

• Excess amount identified: ≈ $88,588 of nominal reward weight above the 1.15 limit (320,905 − 1.15 × 202,015).
• Excess amount burned: None.
• Burn transaction hash: N/A.
• If not yet burned, explain status: the reward proceeds were not retained — they were spent operating the venue (member-traffic purchases $202,015, validator/node infrastructure, cross-chain liquidity). Current CC across all company wallets is only ~53,336 CC (≈ $7,400 at the current ~$0.139/CC), so a treasury burn of the nominal figure is not feasible. The cause has been permanently corrected (own-account swaps will never again carry reward weight; claiming fail-closed and capped ≤ fees per 24h window) and we operate within the 1.15 ratio going forward, verifiable on-chain with an automatic halt at the 1.15 limit. We ask the committee to accept permanent correction + prospective compliance as the remedy; if a concrete step is required we are open to a bounded, one-time measure proportionate to the excess — not the full nominal weight and not an open-ended suspension of claiming, which would remove the venue's principal revenue source and threaten its viability. See §5.

---

Shared Participant Node / Party Structure

• Does the application share a participant node with other Featured Apps?

  • Yes
  • No

• Does the application perform multiple major functions?

  • Yes
  • No

• Does each major function operate under a separate PartyId? Partly. The rewards/validator party, the venue party, and each of the 18 market-making bots are already distinct PartyIds. The exception: swap-venue, HTLC-escrow, fee and settlement-executor functions currently share the single venue party cancore::…659906 on mainnet (separate parties are defined in configuration and live on testnet).

• Separation complete:

  • Yes
  • No
  • Not applicable

  Separation plan: provision distinct mainnet parties for escrow/fee/executor as a reinstatement deliverable — in progress, targeted for mainnet during July 2026 (see §8).

---

Locking Status

• Required lock amount:

  • 5,000,000 CC for Featured App
  • 25,000,000 CC for Issuer

• Amount segregated: 5,000,000 CC (verified on-chain, Lighthouse, last update 2026-06-19).

• Lock holder:

  • Applicant
  • Third party

• If third party, name: Canton Strategic Holdings, Inc. (CSH), holding the 5,000,000 CC as sole owner in a dedicated segregated account at custodian Copper Markets (Switzerland) AG. Signed Token Locking Agreement with CoreOps Digital Corporation (dba Cancore) dated 8 June 2026, deposit Start Date 19 June 2026; CSH has notified the Canton Foundation. Executed agreement available on request.

• Lock status:

  • Complete
  • Signed, pending completion
  • Pending signature
  • Not yet complete

• Party or address for verification: 23d169c2-0909-4c70-81d1-1922de6febaa::1220e6f35080b9d64553d4d34d6a3cc8b03d2a6936c84d02667cf39f262c55a86f46

---

Exception Request

• Is an exception requested?

  • Yes
  • No

Our remedy is permanent process correction plus prospective compliance, not an exception. If the committee prefers to record a formal remedy election, the proposed remedy is Other: permanent correction of the marker pipeline and ongoing operation within the 1.15 ratio (rather than burning markers or redistributing value); if a concrete step is required we are open to a bounded, one-time measure proportionate to the excess.

---

Reviewer Notes

• We concede the over-issuance — unlike a pure data/classification case, ~96% of the submitted marker fee-basis was our own market-making. The request file gives the liquidity rationale but does not dispute eligibility.
• No burn executed. The reward proceeds were spent operating the venue (traffic, node, liquidity); current CC holdings are only ~$7,400, so a treasury burn of the nominal $88,588 is not feasible. Our proposed remedy is permanent correction + prospective compliance (the approach other applicants have taken); we are open to a bounded, one-time measure if the committee requires one — but not the nominal burn or an open-ended forbearance, which would threaten the venue's viability. §5.
• The committee numerator also includes cc_transfers by the provider party (DSO Scan); we will reconcile that figure into the agreed excess.
• Disclosed structural item (not the basis of the pause): venue/HTLC-escrow/fee/executor share one venue party on mainnet; separation is a reinstatement deliverable.
• Lock complete and in force via Canton Strategic Holdings, Inc. (CSH): 5,000,000 CC held in a segregated account at custodian Copper Markets (Switzerland) AG under a signed Token Locking Agreement (Start Date 2026-06-19), with CSH notice to the Canton Foundation. CSH retains title, so this is not an on-ledger amulet lock on a Cancore party — total_locked_coin = 0 on our provider party is expected.
• Real third-party usage is growing: 5,268 completed external swaps, 441 distinct external counterparties, ≈$466K external volume (partner integrations $374K June / $88K first two days of July); ~4,600 hosted user wallets; Loop wallet + HECTO listing.

---

Checklist

• 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
• Data discrepancies are explained, if applicable (N/A — not disputed)
• Shared participant node details are included, if applicable
• Party/function separation is addressed
• CIP-0116 locking status is included
• Any exception request is clearly identified (none requested)
• 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: Mikhail Shukshin
• Title: CTO
• Organization: CoreOps Digital Corporation (dba Cancore)
• Date: 2026-07-03