diff --git a/reinstatement/cancore-2026-07-03.md b/reinstatement/cancore-2026-07-03.md new file mode 100644 index 0000000..b633b40 --- /dev/null +++ b/reinstatement/cancore-2026-07-03.md @@ -0,0 +1,223 @@ +# Featured App Reinstatement Request — Cancore + +## 1. Applicant details + +- Organisation name: **CoreOps Digital Corporation (dba Cancore)** +- Link to the tokenomics-list email announcing the pause: https://lists.sync.global/g/tokenomics-announce/message/356 +- Date of pause (UTC): **2026-07-02** +- Does your application share a participant node with other Featured Apps? **No.** Our participant node hosts only Cancore parties (venue, operations, and hosted end-user wallet parties). Section 8 completed for the multi-function aspects. + +## 2. On-chain identifiers + +- Party identifier(s) of the Featured App: + - `Cancore-mainnet-1::1220076a94e0a7f0256a32ffab227db7788d8075677d8afcdaa8386df8f2fa659906` +- Party receiving app rewards: + - `Cancore-mainnet-1::1220076a94e0a7f0256a32ffab227db7788d8075677d8afcdaa8386df8f2fa659906` (sole beneficiary of submitted activity markers and app-reward coupons) +- Party (or parties) of the validator node: + - `Cancore-mainnet-1::1220076a94e0a7f0256a32ffab227db7788d8075677d8afcdaa8386df8f2fa659906` — the same party as the Featured App / rewards party (single validator node; confirmed from deployment config `MARKERS_PROVIDER_PARTY_ID = TRAFFIC_MEMBER_PARTY_ID`). +- Any further parties used to submit transactions (all hosted on the same participant, namespace `…659906`): + - `cancore::1220076a94e0…659906` — trading venue party (order matching, HTLC escrow, fee and settlement-executor operations — see structural note below). + - **18 company-operated market-making bot parties** (role `bot`): `alice_morgan_118aee2a`, `bob_chen_49eae9c4`, `carol_smith_78b90172`, `david_kim_9427f53f`, `eva_martinez_db2bf4d3`, `frank_weber_acef7ea4`, `grace_hall_ab8392c0`, `henry_ford_29c628e7`, `iris_wong_0e03a993`, `jack_reed_fe8bbf23`, `karen_bell_6fca0f0c`, `liam_cross_c37d2f1f`, `mia_stone_8ef0d682`, `noah_pike_b83a6434`, `olivia_frost_b8c571d3`, `peter_vance_dfa63b13`, `quinn_adler_f9e8ea09`, `rachel_cole_bee66d7f` — each `…::…659906`. + - **38 external partner-integration accounts** (independent partners running automated flow through Cancore): e.g. `abena_bridge_a4d1c18b`, `base_swap_eb476cfb`, `airdrop_hypergpt_20b9b474`, `atlas_725db92b`, `orion_9070e0fa` (full list available). These are third parties, counted as external usage in §3. + - Hosted end-user wallet parties (~4,600 individual `_<8hex>::…659906` parties), each acting only for the corresponding end user. + +Functions performed and the party each operates under: + +| Function | Party | +|---|---| +| DEX / swap venue, HTLC escrow, fee & executor | `cancore::…659906` (single party today — see note) | +| Featured App rewards + validator operations | `Cancore-mainnet-1::…659906` | +| Company liquidity provisioning (market-making bots) | 18 dedicated `bot` parties listed above | +| End-user wallets | individual per-user parties | + +- Confirmation of separation: the Featured App/rewards/validator party (`Cancore-mainnet-1::…`) is separate from the venue party (`cancore::…`), and each market-making bot runs under its own party. Cancore is not an asset issuer. **Disclosed gap:** on mainnet the swap-venue, HTLC-escrow, fee and settlement-executor functions currently all run under the **single** venue party `cancore::…659906` (the separate escrow/fee/executor parties defined in our configuration are provisioned on testnet but not yet on mainnet). We commit to provisioning distinct mainnet parties for these functions as part of reinstatement; target structure and timeline in §8. + +## 3. Basis of the pause + +Our understanding of the basis: our marker pipeline claimed featured-app reward weight against the on-chain fees generated by Cancore's own automated market-making — the liquidity engine we run so that users on a new cross-chain venue have depth and a counterparty to trade against. Because market-making necessarily operates at high volume, its fees came to dominate our submitted reward weight, outweighing genuine third-party usage. We accept that fees from our own market-making should not carry featured-app reward weight; that attribution is the defect, and we do not dispute the pause. + +- Reward weight submitted over the period, in USD: **320,905** (320,905 activity markers submitted, each 1 unit of reward weight = $1; from our marker-submission ledger, to be cross-checked against DSO Scan `FeaturedAppActivityMarker` creates for the provider party). Monthly: Apr 7,593 · May 72,589 · Jun 212,019 · Jul (1–2) 28,704. +- Reward weight we contend is eligible over the period, in USD: **≈$11,800** — the markers backed by third-party activity (external partner integrations plus unaffiliated users). Basis: of the $305,460 of recorded swap fees underlying submitted markers, **$293,650 (96.1%) came from Cancore's own market-making liquidity (both legs internal)** and should not carry reward weight (included in the §5 burn); $11,210 (3.7%) involved external partner-integration accounts and $600 (0.2%) unaffiliated users — together the eligible portion. Applying the 96.1% internal-market-making share to the 320,905 markers, **≈308,400 markers were backed by our own market-making rather than third-party activity.** (This characterises the cause; the quantity actually to be burned is set by the overage above the ratio limit — see §5 — not by this activity share.) +- Fees paid over the same period, in USD (traffic purchased): **≈$202,015** (1,355,808 CC of `AmuletRules_BuyMemberTraffic` by the validator party over 2026-04-08 → 2026-07-02, at $0.149/CC; from Lighthouse, cross-checkable on DSO Scan `MemberTraffic`). Monthly: Apr $11.9K · May $41.8K · Jun $126.7K · Jul $21.8K. (Our recorded *swap* fees were higher (~$1.12M) but those are not the `usd_spent` denominator.) We verified across every Cancore party that **all** member-traffic purchases originate from this single validator/provider party — the venue party, the 18 bots and the treasury/vault parties purchase none — so the denominator is complete and not understated by unattributed traffic (a single-participant-node setup, in contrast to multi-node venues). The overage is therefore genuinely ≈1.59; we are not seeking to lower it through re-attribution. +- Period covered (start and end, UTC): **2026-04-08 06:00 UTC (first submitted batch) — 2026-07-02 16:28 UTC (last submitted batch).** + +Per-party breakdown: only `Cancore-mainnet-1::…659906` has ever submitted activity markers; no other Cancore party claims reward weight. + +- Per party: `Cancore-mainnet-1::…659906` — reward weight submitted **$320,905**, fees paid **≈$202,015**, resulting ratio **≈1.59** (markers-only; higher once CC transfers are included). We do not dispute that this exceeds the 1.15 limit. + +We do not contest the pause-notice figures. + +## 4. Cause + +Our pause has two related bases under the guidance: reward weight exceeded paid fees, and that excess came from marking our own (related-party) market-making activity. We address both branches, then the structural branch. + +**Paused for claimed rewards exceeding paid fees.** + +- The process or automation that generated the excess markers, and its rule: swap-fee events from settled HTLC swaps were recorded as marker entries; an automated batch job submitted markers every 5 minutes (and after each traffic purchase), claiming reward weight up to recorded swap fees, capped only by a ratio check against traffic purchased in a rolling 30-minute window. The weekly-ratio, external-counterparty-share and minimum-activity checks existed only as dashboard advisories and did not block submission. +- Why it produced more reward weight than paid fees supported: the attribution rule treated a fee-paying market-making swap identically to a genuine user swap, and the pipeline had no rule to exclude our own accounts. As market-making volume scaled to keep the order book liquid, marker weight scaled with it, while third-party usage and traffic purchases did not keep pace — driving the cumulative ratio to **≈1.59** against the 1.15 limit. + +**Paused for marking own or related-party activity.** + +- The activity marked, its approximate volume and period: Cancore runs 18 automated market-making accounts (role `bot`, enumerated in §2) that continuously quote and fill on our order book. Their purpose is liquidity — a new cross-chain venue has no organic depth on day one, so without a market maker the first users arrive to an empty book with nothing to trade against; this is standard venue bootstrapping. The by-product is that these accounts trade largely with one another: over 2026-05-20 → 2026-06-24, 21,336 completed swaps ≈ $2.89M were internal market-making, against 246 swaps ≈ $63.8K with external partner integrations and 94 ≈ $20 with unaffiliated users. Across full history internal market-making was ~93% of completed volume ($5.93M of $6.40M), with external usage the remaining ~7% (≈$466K, detailed in §7). Every settled swap pays an on-chain fee, and those fees drove **~96% of submitted markers** (by fee basis). The market-making itself was legitimate liquidity provision; the defect was letting its fees flow into featured-app reward weight. +- How own activity is now distinguished from genuine third-party use: every order records its initiating and accepting account and every account carries an explicit role, so our market-making accounts are fully identifiable — this is how the §3 figures were derived. Marker claiming is currently disabled entirely (§5). Before it is re-enabled we are enforcing this exclusion **in the claiming path itself**, fail-closed: swaps where both legs are our own accounts generate no marker entry; swaps with one third-party leg are weighted only by that leg's fee; and if attribution is unavailable, nothing is claimed. Today this distinction exists as an analytical capability; the enforced in-pipeline version is the core remediation being built for reinstatement. + +**Paused on structural grounds (issuer combining functions on one party):** N/A — Cancore is not an asset issuer and does not combine an issuer function with the venue. A separate, disclosed structural item — the venue/HTLC-escrow/fee/executor functions currently sharing one venue party on mainnet — is not a basis of this pause but is addressed in §2 and §8. + +## 5. Corrective measures + +All measures verifiable on-chain against the identifiers in section 2: + +- **2026-07-02 16:28 UTC** — activity-marker claiming stopped. Last `BatchedMarkersProxy_CreateMarkersV2` submission by `Cancore-mainnet-1::…` was 16:28:37 UTC; the marker kill switch (`MARKERS_ENABLED=false`) was subsequently applied at redeploy. Markers remain off until reinstatement. +- **2026-07-02 16:33 UTC** — all internal market-making strategies disabled (all six `volume` strategies set inactive at 16:33–16:34 UTC); the last internal market-making swap settled at 16:32:43 UTC. Partner flow ceased by 22:33 UTC. No internal market-making swaps since. +- **2026-07-03** — app-reward coupon collection stopped (reward-sweep disabled). No further reward claiming while the review is open. +- **COMMITTED — prior to any re-enablement of marker claiming** — market-making exclusion enforced in the marker pipeline (see §4): markers only for swaps with ≥1 third-party leg, weighted by that leg's fee only; submitted weight in any 24h window ≤ fees paid in that window; all gates blocking and fail-closed. +- **COMMITTED — prior to any re-enablement of marker claiming** — real-time compliance monitoring deployed (§7) with automatic halt of claiming at the 1.15 ratio limit. + +Treatment of the excess: + +- Excess quantity, with calculation: the pause was triggered by our overage ratio exceeding the 1.15 limit. On a markers-only basis we submitted **$320,905** of reward weight against **$202,015** of traffic purchased (`usd_spent`), an overage of **≈1.59**; restoring the cumulative ratio to the 1.15 hard limit corresponds to the reward weight above the line: 320,905 − (1.15 × 202,015) = **≈$88,588** of nominal reward weight (≈88,600 markers). Including the provider `cc_transfers` term in the numerator per the committee formula raises this to an overage of **≈1.68** and an excess of **≈$105,000**; the committee's own DSO Scan run of the attached query (`committee-overage-query-cancore-2026-07-07.sql`) is authoritative, and the full reconstruction is set out in §12 (our responses to the committee's follow-up questions). +- Disposition of the proceeds: the CC received from app rewards was not retained as a distributable surplus. It was applied in the ordinary course of operating the venue — principally the purchase of member traffic (itself CC returned to the network, $202,015 over the period), the running of our validator/node infrastructure, and the funding of the cross-chain liquidity that keeps the venue usable. Our current on-chain CC on the featured-app / rewards party (`Cancore-mainnet-1::…659906`) is only **~16,457 CC (≈ $2,110 at the current ~$0.128/CC, as of 2026-07-08)**; the reward proceeds have been consumed in operating the application, not banked. +- On the remedy: we want to be straightforward. We acknowledge what happened — our marker pipeline claimed reward weight on internal, related-party activity that should not have qualified — we take full responsibility, and we sincerely apologise, to the committee and to the network. It will not happen again: marker claiming is off, market-making between our own accounts will never again carry reward weight, and the structural changes in §4 and §8 are designed so that it cannot recur. We are **not** asking for a waiver, and we are committed to making this right. We are also honest about one constraint: a single lump-sum return of the nominal excess (≈$105,000, on the order of 820,000 CC and nearly fifty times the current balance of our featured-app rewards party, ~16,457 CC ≈ $2,110) is not something the venue can absorb in its current state without putting the project itself at risk — which cuts against the committee's own concern about not reinstating a venue that then fails. We would ask the committee to weigh one thing in shaping the remedy: Cancore is one of the few genuinely active projects in the Canton ecosystem, with a live mainnet product and a real, engaged community. We ask you to take that into account and to work with us on a practical and proportionate remedy — one that lets us make things right without putting the future of the project at risk. Concretely, we ask that the remedy be weighed as a whole — the structural rework in §4 and §8 (new testnet-validated separated-party contracts, a fail-closed marker pipeline, and the external-keyed-wallet migration) together with a burn of the excess, not the burn in isolation — and we propose that burn as a fully on-chain, verifiable measure: **sized to the CC actually received** (nominal marker weight materially overstates it at the prevailing reward rate, evidenced by our coupon / reward-collection records), with an **immediate good-faith first tranche from current holdings** (tx hashes provided) and the **remainder on a defined schedule from realized swap-fee revenue**, reinstatement tracking the schedule rather than requiring the full amount upfront (full detail in §12). We are available to work the exact figure and schedule with the committee directly. (The committee numerator also includes provider `cc_transfers` from DSO Scan; we will reconcile that figure into the agreed measure.) Supporting data — per-day marker counts, per-swap counterparty classification, the traffic-purchase ledger, and wallet balances — is attached. + +## 6. Data discrepancies + +N/A — we rely on the public explorers listed in section 9 and do not dispute the committee's figures. + +## 7. Basis for continued compliance + +- The function the application serves: Cancore is a non-custodial cross-chain atomic-swap venue between Canton Network and EVM-compatible chains (HTLC-based, trust-minimised). It gives Canton users a direct on-ramp/off-ramp for external assets (USDC and others) without leaving self-custody, and brings external users and assets onto Canton. Our own market-making provides the liquidity that makes the venue usable while third-party demand builds — and that demand is real and growing: **5,268 completed external swaps from 441 distinct external counterparties** (38 partner integrations + 403 unaffiliated users), with external volume of **≈$466K** to date. It is concentrated in the partner integrations, which ramped sharply through June–July (**$374K in June, $88K in the first two days of July**), alongside ~4,600 hosted user wallet parties and integrations including Loop wallet and the HECTO token listing. The reinstatement plan keeps the market-making (it is what lets users trade at all) but ties reward-bearing activity strictly to third-party flow, not to our own liquidity provision. + +- The compliance rule the application now operates under, stated as a commitment: **Cancore will submit activity markers only for swaps with at least one third-party leg, weighted only by the fees actually paid by that leg; our own market-making activity will never generate reward weight; and total submitted reward weight in any 24-hour window will not exceed the fees paid by the application in that window.** + +- Monitoring being put in place before re-enablement: a real-time monitor computes our ratio of submitted weight to paid fees per 30-minute window and per 24-hour bucket directly from on-chain data; alerting fires as the ratio approaches the 1.15 limit and claiming halts automatically (fail-closed) at 1.15; counterparty-attribution failures halt claiming rather than defaulting to eligible; the kill switch requires two-person signoff to re-enable. (We disclose that during the affected period our ratio checks were advisory-only and one gate was fail-open; converting these to blocking, fail-closed controls is part of the remediation.) We are prepared to share this monitor or periodic reports with the committee. + +- Prior committee guidance relied upon: the published Featured App activity-marker guidelines and the tokenomics-list enforcement notice of 2026-04-18 (formal, via the tokenomics mailing list). No informal guidance is relied upon. + +- Consent to follow-up review: **Yes** — we consent to a follow-up review at any interval the committee prefers (we suggest 30 and 90 days after reinstatement) and to providing our claiming data for it. + +## 8. Shared participant node + +- All Featured App parties on the participant: `Cancore-mainnet-1::1220076a…659906` is the only Featured App party on our participant; no other Featured Apps are co-located. Reward weight and fees for it are given in section 3. +- Functions sharing a single party, and the separation being adopted: the rewards/validator party, the venue party, and each liquidity bot are already distinct PartyIds (§2). The disclosed exception is that the swap-venue, HTLC-escrow, fee and settlement-executor functions currently share the single venue party `cancore::…659906` on mainnet. Separate parties for these are already defined in our configuration (live on testnet) and we will provision them on mainnet as a reinstatement deliverable. This work is in progress, targeted for mainnet during July 2026. +- Asset issuance: N/A — Cancore does not issue assets. + +## 9. Sources and explorers + +The figures in sections 3 and 5 can be verified on the public explorers the committee references. Where sources diverge we state which we relied on and why; a discrepancy between explorers is a data issue, not in itself evidence of an overage. + +- **CC View** — the FA Marker Guidance ratio and marker accrual (primary source for the pause figures). +- **Cantonloop Lighthouse** (5N Lighthouse Explorer) — https://lighthouse.cantonloop.com/ — traffic purchases (`/burns`) and party balances. +- **Transparent Scan** (Canton Network dRPC) and **DSO Scan** — marker creates and the `cc_transfers` / `third_party_submitted` terms. +- **RIZEScore by T-RIZE** (beta) — independent cross-check. + +These are reconciled against our internal marker-submission and swap records. The ledger is the source of truth; we invite the committee and data providers (CC View, Noves) to verify our figures per-transaction. + +## 10. Locking + +The CIP-0116 Featured App lock (5,000,000 CC) is **complete and in force** through a third-party token-lock service. + +- Required lock amount: **5,000,000 CC** (Featured App requirement; Cancore is not an asset issuer, so the 25,000,000 CC issuer figure does not apply). +- Amount segregated: **5,000,000 CC**, verified on-chain — the holding party shows 5,000,000.00 CC (Lighthouse, last update 2026-06-19, matching the deposit Start Date below). +- Lock provider and arrangement: the lock is provided by **Canton Strategic Holdings, Inc. ("CSH")** under a signed Token Locking Agreement with Cancore's operating entity, **CoreOps Digital Corporation (dba Cancore)**, dated 8 June 2026 (Start Date 19 June 2026). CSH holds the 5,000,000 CC as sole owner in a **dedicated Segregated Account at the custodian Copper Markets (Switzerland) AG**, used solely for this hold. Under the agreement, CSH has notified the **Canton Foundation** that the amount is segregated for Cancore's benefit and will remain so until Cancore makes alternative lock arrangements or a defined wind-down procedure runs. +- Term: an initial two-month hold from the Start Date, automatically extending for successive two-month terms unless terminated on 30 days' notice — maintained for the duration of the Featured App requirement. +- Nature of the instrument: a third-party segregated hold. CSH retains title and holds the tokens in Copper custody, so the lock is **not** an on-ledger amulet lock on a Cancore party — accordingly `total_locked_coin = 0` on our provider party is expected and correct. The executed agreement can be provided to the committee on request. +- Party / address for verification: `23d169c2-0909-4c70-81d1-1922de6febaa::1220e6f35080b9d64553d4d34d6a3cc8b03d2a6936c84d02667cf39f262c55a86f46` (the CSH/Copper segregated-hold party; verifiable on Lighthouse / DSO Scan). +- Confirmation the lock will be maintained as a condition of reinstatement: **Confirmed.** + +## 11. Exception request (asset issuers only) + +N/A — Cancore is not an asset issuer. + +--- + +## 12. Responses to the committee's follow-up questions (2026-07-08) + +The committee raised five follow-up questions after reviewing this request. Our responses are below, numbered Q1–Q5 to match them (this numbering is local to this section and independent of sections 1–11 above). The overage reconstruction in Q3 can be reproduced with the attached committee query (`committee-overage-query-cancore-2026-07-07.sql`). We are treating this as a compliance failure to correct, not a position to defend. + +### Q1 — Excess remedy + +We want to be straightforward about this. We acknowledge what happened: our marker pipeline claimed rewards on internal, related-party activity that should not have qualified. We take full responsibility, and we sincerely apologize — to the committee and to the network. It will not happen again. We disabled the marker pipeline and halted the internal market-making that caused it on 2026-07-02. + +We accept the ~$105K nominal excess (provider `cc_transfers` included, ratio ~1.68) and will work from it; the committee's `mainnet_da2_scan` run is authoritative and we do not dispute it. + +We ask that the remedy be weighed as a whole, not as the burn alone. Alongside any burn, we are already delivering the structural changes that make this failure non-recurring — and these are the substance of making it right, not just the cash: + +- **Party separation (see Q4).** The single-party structure that caused this was baked into our original contract. We have already implemented and testnet-validated (since 2026-06-19) new contracts that separate venue / HTLC-escrow / fee / executor and split the featured-app rewards party from the operator party, so marker attribution is architecturally isolated from venue operations and a repeat is not structurally possible. We are willing to complete the mainnet cutover **before** reinstatement. +- **Marker pipeline (see Q2).** The submission pipeline has been off since 2026-07-02 (verifiable on-chain), internal market-making is halted, and the rebuilt pipeline is fail-closed: related-party legs generate no marker weight, and submitted weight cannot exceed fees paid in any 24-hour window. +- **External-keyed wallets (see Q3).** We begin migrating users off co-hosting to their own keys in July 2026 — ending the `third_party_submitted = 0` condition and making genuine third-party demand visible to the committee rather than hidden under our fingerprint. + +On the burn itself, we are equally straightforward about what we can and cannot fund. A one-time on-chain burn of ~$105K (~820,000 CC) before reinstatement is beyond what the venue can fund: current on-chain holdings on our featured-app rewards party (`Cancore-mainnet-1::…659906`) are ~16,457 CC (~$2,110), the CIP-0116 lock is a third-party segregated hold we cannot draw from, and the reward proceeds were spent operationally (principally the ~$202K of member-traffic purchases, themselves CC returned to the network). What we can commit to is a concrete, fully on-chain, verifiable measure: + +1. **Sizing.** The $105K is nominal marker weight; the CC actually received at the prevailing reward rate (well below $1/marker over the period) was materially smaller — and that is the returnable amount. We ask the burn be sized to value actually received, and will provide the coupon / reward-collection records to establish it. +2. **Good-faith first tranche, now.** We will burn our current returnable holdings (~16,457 CC) on-chain immediately, with tx hashes, as a signal of intent. +3. **Scheduled remainder.** The balance of the agreed figure burned on a defined schedule from realized swap-fee revenue, each tranche on-chain and reported to the committee — reinstatement tracking the schedule rather than requiring the full amount upfront. + +Taken together — the structural rework above plus a burn sized to what we actually received, executed on a verifiable schedule — this is a real and proportionate remedy. Cancore is one of the few genuinely active projects in the Canton ecosystem, with a live mainnet product and a real, engaged community, and we are asking to work with the committee on a path that lets us make this right without putting the project at risk. We are available to work the exact figure and schedule with the committee directly. If the committee's position is that only a full ~$105K upfront burn is acceptable, we would rather say plainly that we cannot meet it than commit and default — in which case we would understand FA reinstatement not proceeding, and would continue operating the venue on swap fees. + +### Q2 — April 18 enforcement notice + +Fair question, and we'll answer it directly rather than defensively. + +The automated trading you flagged existed to make a market for our users. A new venue with an empty book has nothing for a real user to trade against, so our bots provided two-sided quotes, price continuity, and enough on-venue depth that early users arrived to a liquid, tradeable market. Bootstrapping venue liquidity this way is an ordinary early-exchange function, and it is why the bots ran — the intent was a usable market, not an empty one. + +Where we went wrong was not in running market-making, but in **extending marker attribution to the related-party legs of it** — bot-vs-bot fills that carry no external counterparty. Under Rule 6 those legs are circular activity and belong outside the marker numerator; we should have marked only the legs facing real users. We did not, our controls never isolated the related-party legs, and ~96% of our marker volume ended up resting on internal fills. We are not going to characterise those internal fills as organic user demand — they were not — and that is precisely the error we are correcting. + +On the notice specifically, to answer directly: the April 18 notice did **not** name a related-party exclusion as such. What it stated explicitly was (a) the 115% Marker Ratio pause threshold effective April 20; (b) that **CC transfers and the creation of markers are NOT qualifying activities**; and (c) a requirement to comply with *all aspects* of the March 20 Marker Guidance — which includes the organic-demand / no-circular-activity rule — with the committee reserving faster enforcement for circumvention or network harm. So "related party" was not the wording, but the notice was explicit that CC transfers are non-qualifying, and our marker activity was built on featured CC transfers. We will therefore not claim we believed those transfers were qualifying — the notice stated the opposite in plain terms. Our failure is that we did not bring our marker behaviour into line with a warning we had already received; the outcome breached 1.15, and we are correcting it, not defending it. + +The market-making itself is a genuine product, not a marker scheme: it has supported 5,268 completed external swaps across 441 distinct counterparties (~$466K). These are external by our own records — real third-party users — though on-chain they remain co-hosted under our fingerprint (see Q3), which is exactly why the external-key migration matters: it makes that demand visible to the committee, not just to us. This is the organic, user-facing demand markers are meant to reflect. Going forward the market-making stays for the users; marker attribution on related-party legs is permanently excluded, computed per the committee formula, under a dedicated rewards party. + +**Corrective action is live and verifiable on-chain:** + +- The marker **submission pipeline** was disabled 2026-07-02 16:28 UTC. On-chain, our batched marker choices (`BatchedMarkersProxy_CreateMarkersV2`, `FeaturedAppRight_CreateActivityMarker`) have not fired since — 0 occurrences across recent transaction history. +- We also stopped attaching our `FeaturedAppRight` to our own transfers, so our `AmuletRules_Transfer` activity no longer self-attributes markers. +- Residual markers naming our party still appear at ~1–17 per round (vs. a farming-era peak of ~13,800/day) and are decaying. These are protocol-level attributions where a *third party* names our party as beneficiary in its own featured transfer (e.g. we observed one with provider `mexc-mainNet-01`) — activity we neither initiate nor can prevent, since they are other parties' transactions. We flag them rather than claim an absolute zero: our own marker pipeline is fully off, these are outside our control, and they remain ~3 orders of magnitude below the farming rate and declining. + +Net effect since 2026-07-02: with the marker pipeline off, our overage sits at ~0.70 — within the 1.0 App-guidance target and below the 1.15 pause threshold — i.e. the venue operates inside the limits without the farming pipeline. + +### Q3 — cc_transfers denominator + +First, on how we arrived at 1.59: that is the number our operational tooling showed us. Both ccview and our own real-time safety dashboard reported an overage of ~1.5–1.6, because neither carries provider `cc_transfers` in the numerator — ccview reports on a different metric, and our own monitor pulls tx-mix from a public explorer (Lighthouse) whose feed did not let us count provider `AmuletRules_Transfer` reliably, so we carried cc_transfers at ~0 and `third_party_submitted = 0`. Those were measurement gaps on our side; the exact committee overage is only computable on DSO Scan, which operators cannot run in real time. + +To answer your question directly, we recomputed the full committee formula from on-chain data, including the provider `cc_transfers` we had omitted: + +- `marker_weight` ≈ **320,905** (matches our April–June aggregation). +- `cc_transfers` ≈ **~18,000** — counted from on-chain data, not assumed. Our provider-party `AmuletRules_Transfer` ran ~250–270/day (provider=us confirmed on every sampled transfer) across the farming window. Markers were created in batches (`BatchedMarkersProxy_CreateMarkersV2`), not one per transfer, so cc_transfers is a small fraction of marker_weight. The committee's own scan run gives the exact count. +- numerator = `marker_weight + cc_transfers` ≈ **~339,000**. +- denominator = `GREATEST(usd_spent, third_party_submitted)` = **202,015** (`usd_spent`; `third_party_submitted` ≈ 0 — see below). +- **overage ≈ 1.68** — above the 1.59 we reported, because the cc_transfers do belong in the numerator, but the correction is modest; the corresponding excess above 1.15 is ~105,000 rather than 88,588. + +We are not asking the committee to treat our reconstruction as authoritative — the attached query, run on DSO Scan, is. The point we concede is that the correct number is modestly higher than the 1.59 we reported — by the provider `cc_transfers` you flagged — and we're comfortable being measured on the committee's own run. + +The denominator does not move in our favour, and we want to be transparent about the structural reason rather than leave it implicit: **every one of our users — real users and internal bots alike — is currently co-hosted under our own participant/namespace fingerprint.** Their transactions are submitted by our participant, so `third_party_submitted` (which counts only non-our-participant submissions) is ~0, and on-chain a genuine user swap is today indistinguishable from an internal one — both appear on a single leg under our hash. This is an architectural artifact of co-hosting, not a chosen denominator, and it is also why we cannot presently *show* the committee which activity was user-facing. We are only now provisioning external, externally-keyed wallets for our users (see Q4); once users hold their own keys, their submissions become genuine third-party activity and begin to count. Until then `GREATEST` stays on `usd_spent` (~$202K) and we do not dispute that. + +We are attaching the committee's own query, parameterised with our party (`committee-overage-query-cancore-2026-07-07.sql`; we are un-split, so provider = validator = beneficiary = confirmer). If the committee runs it on `mainnet_da2_scan`, the number is authoritative and removes any dispute about what we counted. We are happy to be measured on that figure. + +### Q4 — Party separation + +To be clear on the root cause: the single-party structure was baked into our original smart-contract design, not operational sloppiness. We have already implemented a new contract that separates the functions (venue / HTLC-escrow / fee / executor) and validated it end-to-end on our testnet (since 2026-06-19); the remaining work is the mainnet deploy + cutover. + +We are ready to execute that cutover, and we are willing to complete it **before** reinstatement, as a precondition, if the committee prefers — our only ask is that the sequence and timing be agreed with the committee, after which we can proceed immediately. Target completion: within 14 days of the committee signing off on the sequence. We will split the featured-app rewards party from the operator party in the same cutover, so marker attribution is structurally isolated from venue operations and a repeat of this failure is not architecturally possible. + +Separately, addressing the root of Q3: we begin migrating users to external, externally-keyed wallets — their own namespace, not co-hosted under our fingerprint — **in July 2026**. This is what ends the `third_party_submitted = 0` condition: once users hold their own keys, their activity becomes verifiable third-party-submitted, and the committee can measure our qualifying activity directly rather than inferring it. + +### Q5 — Post-reinstatement revenue model + +Our business is swap fees on real cross-chain volume, not marker rewards. To date the venue has settled 5,268 completed external swaps across 441 distinct counterparties for ~$466K of volume — genuine third-party demand, independent of markers. Revenue going forward: + +- **Primary — swap fees** on that cross-chain flow (real USD, independent of the reward program). +- **Bridge inventory / instant-swap** yield on venue-held liquidity. +- **External user wallets, RFQ / pooled liquidity, and ANS-driven inbound** — all of which grow genuine third-party-submitted activity (structurally ~0 today because users are co-hosted under our fingerprint; see Q3/Q4). +- **Markers only as a formula-capped incidental** — recomputed per 30-min window on the committee formula, hard-capped below 1.0, with related-party volume excluded from the numerator and a dedicated rewards party. Not a line of the business model. + +The post-2026-07-02 data above (overage ~0.70 with the pipeline off, venue still transacting) is our evidence that the venue is sustainable inside the rules. We are asking to be reinstated on that basis, and are comfortable with reinstatement being conditional on the party separation in Q4 being live. + +--- + +## 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 (follow-up responses in §12 added 2026-07-08) diff --git a/reinstatement/committee-overage-query-cancore-2026-07-07.sql b/reinstatement/committee-overage-query-cancore-2026-07-07.sql new file mode 100644 index 0000000..d4ed7d6 --- /dev/null +++ b/reinstatement/committee-overage-query-cancore-2026-07-07.sql @@ -0,0 +1,195 @@ +-- ===================================================================== +-- Committee overage query — parameterised for Cancore's provider party. +-- Source: guidelines/featured_markers_guidelines.md (committee methodology, +-- BigQuery over the mainnet_da2_scan document-store dataset). +-- Purpose: reproduce the FULL committee formula for Q3 of the accountability +-- PR — i.e. include provider cc_transfers in the numerator and the +-- GREATEST(usd_spent, third_party_submitted) denominator, instead of +-- the marker-weight / traffic-only 1.59 we reported earlier. +-- +-- overage = (marker_weight + cc_transfers) / GREATEST(usd_spent, third_party_submitted) +-- +-- Cancore is a SINGLE, un-split party (provider = validator = beneficiary = +-- confirmer). That un-split state is exactly what Q4 commits to fixing; it also +-- means the simplest [fa_party] form of the query applies to us verbatim. +-- +-- Where to run: +-- * mainnet_da2_scan is the GSF/DA-managed Scan export the committee itself +-- queries. If we do not have BigQuery access to it, hand this exact query + +-- our party id to the committee and ask them to run it — that removes any +-- dispute about which numerator/denominator we used. +-- ===================================================================== + +-- Our provider party (operator + featured-app provider, un-split). +SET fa_party = "Cancore-mainnet-1::1220076a94e0a7f0256a32ffab227db7788d8075677d8afcdaa8386df8f2fa659906"; +SET provider_parties = [fa_party]; +SET beneficiary_parties = [fa_party]; +SET validator_parties = [fa_party]; +SET confirmer_parties = [fa_party]; + +-- Window / granularity. +-- Mode A (ramp picture, answers Q2): 24h buckets over the farming era. +-- Mode B (single lifetime number to compare with our 1.59): make ONE bucket +-- span the whole period by setting bucket_width wider than the range. +SET bucket_origin_timestamp = TIMESTAMP '2026-04-01 00:00:00.00'; +SET bucket_width = INTERVAL 24 HOUR; -- Mode A. For Mode B use INTERVAL 200 DAY. + +with + verdicts as ( + select + TIMESTAMP_BUCKET(timestamp_micros(record_time), bucket_width, bucket_origin_timestamp) as bucket, + row_id as verdict_row_id, + update_id, + verdict_result, + submitting_participant_uid, + from `mainnet_da2_scan.scan_sv_1_scan_verdict_store` + ), + views as ( + select + verdict_row_id, + ( SELECT ARRAY_AGG(distinct flat_confirmers) + FROM ( + SELECT ARRAY_CONCAT_AGG(ps) cs + FROM ( + select JSON_VALUE_ARRAY(confirmer_groups, '$.parties') ps + FROM UNNEST(JSON_QUERY_ARRAY(confirming_parties)) as confirmer_groups + ) + ), UNNEST(cs) as flat_confirmers + ) as confirmers + from `mainnet_da2_scan.scan_sv_1_scan_verdict_transaction_view_store` + ), + annotated_views as ( + select *, + ( select COUNT(*) from unnest(confirmers) as cs + where cs in unnest(confirmer_parties) + ) > 0 as confirmer_confirmed + from views + ), + annotated_verdicts as ( + select + bucket, + update_id, + submitting_participant_uid in unnest(validator_parties) as validator_submitted, + countif(confirmer_confirmed) > 0 as confirmer_confirmed, + from verdicts + left join annotated_views using(verdict_row_id) + where bucket >= bucket_origin_timestamp + and verdict_result = 1 + GROUP BY bucket, update_id, validator_submitted + ), + grouped_verdicts as ( + select + bucket, + countif (confirmer_confirmed) as confirmer_confirmed, + countif (validator_submitted) as validator_submitted, + countif (confirmer_confirmed and not validator_submitted) as third_party_submitted + from annotated_verdicts + group by bucket + ), + + burn as ( + select + update_id, + record_time, + TIMESTAMP_BUCKET(timestamp_micros(record_time), bucket_width, bucket_origin_timestamp) as bucket, + JSON_VALUE(create_arguments, '$.record.fields[0].value.party') as dso, + substring(JSON_VALUE(create_arguments, '$.record.fields[1].value.text'), 6) as member_id, + JSON_VALUE(create_arguments, '$.record.fields[2].value.text') as synchronizer_id, + JSON_VALUE(create_arguments, '$.record.fields[3].value.int64') as migration_id, + LAX_INT64(JSON_QUERY(create_arguments, '$.record.fields[4].value.int64')) as traffic, + LAX_INT64(JSON_QUERY(create_arguments, '$.record.fields[5].value.int64')) as num_purchases, + LAX_FLOAT64(JSON_QUERY(create_arguments, '$.record.fields[6].value.numeric')) as amulet_spent, + LAX_FLOAT64(JSON_QUERY(create_arguments, '$.record.fields[7].value.numeric')) as usd_spent + from `mainnet_da2_scan.scan_sv_1_update_history_creates` + where template_id_entity_name = 'MemberTraffic' + ), + filtered_burn as ( + select * from burn + where member_id in unnest(validator_parties) + and burn.num_purchases = 1 + and bucket >= bucket_origin_timestamp + ), + grouped_burn as ( + select bucket, sum(traffic) as traffic, sum(amulet_spent) as amulet_spent, sum(usd_spent) as usd_spent + from filtered_burn + group by bucket + ), + + markers as ( + select + update_id, + record_time, + TIMESTAMP_BUCKET(timestamp_micros(record_time), bucket_width, bucket_origin_timestamp) as bucket, + JSON_VALUE(create_arguments, '$.record.fields[0].value.party') as dso, + JSON_VALUE(create_arguments, '$.record.fields[1].value.party') as provider, + JSON_VALUE(create_arguments, '$.record.fields[2].value.party') as beneficiary, + LAX_FLOAT64(JSON_QUERY(create_arguments, '$.record.fields[3].value.numeric')) as weight, + from `mainnet_da2_scan.scan_sv_1_update_history_creates` + where template_id_entity_name = 'FeaturedAppActivityMarker' + ), + filtered_markers as ( + select * from markers + where (provider in unnest(provider_parties) or beneficiary in unnest(beneficiary_parties)) + and bucket >= bucket_origin_timestamp + ), + grouped_markers as ( + select bucket, sum(weight) as marker_weight + from filtered_markers + group by bucket + ), + + transfers AS ( + SELECT + TIMESTAMP_BUCKET(timestamp_micros(record_time), bucket_width, bucket_origin_timestamp) as bucket, + JSON_VALUE(argument, '$.record.fields[0].value.record.fields[1].value.party') AS provider + FROM `mainnet_da2_scan.scan_sv_1_update_history_exercises` + WHERE choice = 'AmuletRules_Transfer' + ), + filtered_transfers AS ( + SELECT * FROM transfers + WHERE bucket >= bucket_origin_timestamp + AND provider IN UNNEST(provider_parties) + ), + grouped_transfers AS ( + SELECT bucket, COUNT(*) as cc_transfers + FROM filtered_transfers + GROUP BY bucket + ) + +-- Put it all together. COALESCE guards against empty-bucket NULLs so the +-- excess sum is well-defined even on days with markers-but-no-transfers etc. +SELECT + bucket, + if (usd_spent > third_party_submitted, "App", "Asset") as guidance_type, + COALESCE(marker_weight, 0) as marker_weight, + COALESCE(cc_transfers, 0) as cc_transfers, + COALESCE(marker_weight, 0) + COALESCE(cc_transfers, 0) as total_app_weight, + COALESCE(usd_spent, 0) as usd_spent, + third_party_submitted, + GREATEST(COALESCE(usd_spent, 0), COALESCE(third_party_submitted, 0)) as denominator, + SAFE_DIVIDE( + COALESCE(marker_weight, 0) + COALESCE(cc_transfers, 0), + GREATEST(COALESCE(usd_spent, 0), COALESCE(third_party_submitted, 0)) + ) as overage, + -- Per-bucket excess weight above the 1.15 hard limit (0 when compliant). + GREATEST( + 0, + (COALESCE(marker_weight, 0) + COALESCE(cc_transfers, 0)) + - 1.15 * GREATEST(COALESCE(usd_spent, 0), COALESCE(third_party_submitted, 0)) + ) as excess_weight +FROM grouped_verdicts + left join grouped_burn using (bucket) + left join grouped_markers using (bucket) + left join grouped_transfers using (bucket) +ORDER BY grouped_verdicts.bucket desc; + +-- To get the two headline numbers for the PR, wrap the SELECT above as a CTE +-- `q` and aggregate: +-- SELECT +-- SUM(total_app_weight) AS total_numerator, +-- SUM(denominator) AS total_denominator, +-- SUM(total_app_weight) / SUM(denominator) AS lifetime_overage, -- compare vs our 1.59 +-- SUM(excess_weight) AS excess_above_1_15 -- compare vs $88,588 +-- FROM q; +-- lifetime_overage uses one pooled ratio; excess_above_1_15 is the committee's +-- per-bucket sum of overages beyond 1.15 (the stricter, enforcement number).