Mailing Lists/Follow-up (Canton issuer validation request)Source on lists.sync.global ↗

Follow-up (Canton issuer validation request)

grants-discuss16 messagesstarted 24-04-2026
Also mentions:CIP-0056CIP-0103
  1. #1maranda@compliledger.com24-04-2026source ↗

    Based on review feedback, I’m looking to validate this specifically with token issuers building on Canton, given the network’s privacy-first and multi-party execution model.

    For teams working with CIP-0056 tokens, stablecoin issuance, or DvP / settlement workflows on Canton:

    Would enforcing compliance directly inside the transaction layer (rather than as an off-ledger pre-check) be valuable in your workflows, particularly for:

    • preventing non-compliant minting / transfers

    • eliminating race conditions between compliance evaluation and settlement

    • improving auditability of what compliance state was enforced at execution

    The approach is designed to align with Canton’s privacy model (party-scoped visibility) while ensuring compliance is enforced atomically within the same transaction.

    Even a short perspective or confirmation would be extremely helpful as part of the evaluation.

  2. #2Scott Long24-04-2026source ↗
    Maranda — from LongView Crew (retail Canton dApp with a multi-tenant NFT issuer platform — not stablecoin, but issuer-adjacent): yes, this would be valuable. Quick perspective on each:

    Preventing non-compliant mints/transfers: Very valuable. We currently run off-ledger compliance review (admin approval + content policy) but the Daml choice for minting doesn't enforce those conditions at execution. On-ledger enforcement at the controller level would close the "compromised issuer credentials" gap cleanly.

    Race conditions: Less acute for single-mint NFTs, but real for high-frequency issuance or DvP. Architecturally cleaner — eliminates the off-ledger cache-consistency problem entirely.

    Auditability at execution: Biggest win for us. We maintain an off-ledger audit log; ground truth lives on-chain. Having compliance state stamped INTO the transaction makes the audit inherent to the ledger — no separate system to reconcile. Valuable for us, for regulators, for any future auditor or acquirer.

    Three open questions from our seat:
    - Cost: compliance-per-transaction has to stay sub-cent in CC terms for retail-scale issuance to pencil
    - Upgrades: how do compliance rule changes propagate to active token templates without breaking existing holdings?
    - Privacy: how does enforcement remain consistent with Canton's party-scoped visibility — does compliance state leak info that shouldn't be leaked to counterparties?

    Happy to share more about our multi-tenant issuer platform design if useful for your evaluation — we've thought hard about where off-ledger compliance hits its limits.

    — Scott Long
    LongView Compute LLC (grant PR #195)
    LongView Crew — retail Canton dApp + multi-tenant NFT issuer platform
    longviewcompute.com
    toggle quoted message Show quoted text


    On Fri, Apr 24, 2026 at 9:30 AM maranda via lists.sync.global <maranda=compliledger.com@...> wrote:

    Based on review feedback, I’m looking to validate this specifically with token issuers building on Canton, given the network’s privacy-first and multi-party execution model.

    For teams working with CIP-0056 tokens, stablecoin issuance, or DvP / settlement workflows on Canton:

    Would enforcing compliance directly inside the transaction layer (rather than as an off-ledger pre-check) be valuable in your workflows, particularly for:

    • preventing non-compliant minting / transfers

    • eliminating race conditions between compliance evaluation and settlement

    • improving auditability of what compliance state was enforced at execution

    The approach is designed to align with Canton’s privacy model (party-scoped visibility) while ensuring compliance is enforced atomically within the same transaction.

    Even a short perspective or confirmation would be extremely helpful as part of the evaluation.

  3. #3maranda@compliledger.com24-04-2026source ↗

    Scott — this is incredibly helpful, thank you. The points around controller-level enforcement and auditability at execution are exactly the gaps we’re targeting.

    On your questions:

    • Cost — design goal is to keep enforcement lightweight (single proof check within the transaction). We’re targeting sub-cent equivalent overhead, but I’ll share more concrete numbers as we benchmark.
    • Upgrades — current model uses versioned policy packs + new proof issuance (rather than mutating existing state), so existing holdings aren’t broken. Happy to walk through the lifecycle.
    • Privacy — enforcement is aligned with Canton’s party-scoped model (proof visibility restricted to signatories/observers; no global leakage). This is a core design constraint.

    Would definitely welcome a deeper dive on your multi-tenant issuer model—feels very aligned.

    Appreciate you taking the time to share this.

  4. #4Scott Long25-04-2026source ↗

    Maranda — thanks for the thoughtful response. The versioned-policy-pack + proof-check model addresses my three open questions cleanly; that puts you ahead of where most "compliance on chain" pitches I've seen actually are.

    Here's the deeper dive on LVC's multi-tenant issuer model, with the off-ledger compliance gaps surfaced. It's been running on localnet and just connected to DevNet today.

    The platform shape

    LVC operates a multi-tenant issuer platform on Canton. Each tenant ("Issuer") is an organization that registers to mint a credential collection — currently scoped to soulbound NFTs (membership badges, milestone achievements, artistic works), with a roadmap toward broader credential types. Issuers go through:

    1. Application — public form collects organization name, jurisdiction, content categories (multi-select against a published policy), contact email, policy-accepted checkbox.
    2. Admin review — platform admin approves, rejects, or requests changes.
    3. Activation — approved issuer gets per-issuer minting credentials, a branding profile, and a daily mint quota.
    4. Lifecycle — admin can suspend, reinstate, revoke, or update limits at any time. Audit log captures every state transition.

    Where compliance currently lives

    • Off-ledger: application review, content category enforcement, suspension, daily mint quota, branding, audit trail.
    • On-ledger (Daml): signature requirement on the mint choice. That's it.

    The gaps your design appears to close

    • Suspension bypass. If an issuer's API credentials leak before the suspension propagates to the participant's authorization layer, the Daml choice still executes. There's no on-ledger "is this issuer in good standing" check.
    • Quota race. Daily quota is a counter persisted off-ledger. We've prevented bypass practically with synchronized consumption, but the architecture itself permits the gap.
    • Audit reconciliation. We run IssuerAuditService as an append-only off-ledger log. Ground truth, however, lives on-chain. Today there's no formal proof the off-ledger audit reflects what the chain actually saw. A versioned-policy-pack with on-chain proof check makes the audit inherent.
    • Policy versioning. When we update the User Content Policy, prior mints are grandfathered by convention. There's no on-chain stamp of which policy version applied to which mint. Solvable with metadata, but purely descriptive — not enforced.

    What would change in our architecture if we adopted CompLiLedger

    We'd retain the off-ledger application/review flow (humans should make content-judgment calls). What moves on-chain: issuer-good-standing check, jurisdiction attestation, content-category allowlist for the tier being minted, and rule-version stamp at execution. The off-ledger audit log becomes a derivative, not ground truth.

    Questions to make this concrete

    1. Proof primitive: is the proof ZK-style (issuer asserts compliance without revealing underlying attributes), or a direct query against on-chain compliance state? Privacy implications differ a lot between these.
    2. Rule authoring DX: how does an issuer author a rule pack — Daml-native predicates, a separate DSL, a UI builder?
    3. Verifier identity: who's the on-chain verifier party — issuer, a trusted compliance oracle (CompLiLedger as a service), the DSO?
    4. Choice integration: do consumers integrate via a Daml choice precondition, an interface implementation, or a separate compose-step at submission?
    5. Cost benchmark: I'd love your concrete numbers when you have them. Sub-cent CC overhead is my threshold; my retail use case (artistic NFTs at 5 CC) can't have compliance overhead dominate the fee.

    Next step

    Async works well for me here. Share whatever spec, prototype, or draft you're comfortable showing and I'll give you concrete reactions from a working issuer's seat.

    — Scott LongView Compute LLC (grant PR #195) longviewcompute.com


    toggle quoted message Show quoted text

    On Fri, Apr 24, 2026 at 10:08 AM maranda via lists.sync.global <maranda=compliledger.com@...> wrote:

    Scott — this is incredibly helpful, thank you. The points around controller-level enforcement and auditability at execution are exactly the gaps we’re targeting.

    On your questions:

    • Cost — design goal is to keep enforcement lightweight (single proof check within the transaction). We’re targeting sub-cent equivalent overhead, but I’ll share more concrete numbers as we benchmark.
    • Upgrades — current model uses versioned policy packs + new proof issuance (rather than mutating existing state), so existing holdings aren’t broken. Happy to walk through the lifecycle.
    • Privacy — enforcement is aligned with Canton’s party-scoped model (proof visibility restricted to signatories/observers; no global leakage). This is a core design constraint.

    Would definitely welcome a deeper dive on your multi-tenant issuer model—feels very aligned.

    Appreciate you taking the time to share this.

  5. #5maranda@compliledger.com25-04-2026source ↗

    Scott — this is incredibly helpful. The way you mapped the gaps (especially suspension bypass, quota race, and audit reconciliation) is exactly the class of issues we’re targeting.

    Your multi-tenant issuer model is very aligned with how we’re thinking about real adoption.

    On next steps, I think the most valuable path is to make this concrete against your flow rather than keep it abstract:

    Proposed next step

    I can put together a focused prototype flow mapped to LVC, specifically:

    • Issuer good-standing enforcement
      → on-ledger check at mint execution (no reliance on API-layer propagation)
    • Quota enforcement pattern
      → modeled as an on-ledger counter / constraint rather than off-ledger state
    • Policy version stamping
      → each mint tied to a specific rule version at execution
    • Audit as ground truth
      → compliance state embedded directly in the transaction

    This would essentially be:

    your current architecture, but with enforcement moved into the transaction layer

     

    On your questions (quick confirmations)

    • Proof primitive
      Deterministic proof + on-ledger contract (recomputable). ZK is on the roadmap, but not required for enforcement.
    • Rule authoring
      Versioned policy packs (structured definitions → evaluated off-ledger → enforced on-ledger). Likely evolves into a DSL/UI over time.
    • Verifier identity
      Co-signed model (issuer + evaluator), with flexibility for a service-based evaluator.
    • Integration pattern
      Precondition inside the Daml choice / interface-based enforcement (atomic).
    • Cost
      Target is minimal overhead (contract fetch + assertion). I’ll share benchmarks once we run them.

     

    If you’re open to it

    Would be great to:

    • walk through your mint flow step-by-step
    • map exactly where enforcement hooks in
    • and sanity check the quota + issuer lifecycle constraints together

    Async is fine, or happy to jump on a quick call.

    Feels like there’s a very natural fit here.

  6. #6maranda@compliledger.com29-04-2026source ↗

    Scott — just wanted to follow up here in case my last message got buried.

    I’m working on mapping a concrete TokenProof flow directly to your issuer model (good-standing checks, quota constraints, and policy versioning at execution) and will share a structured version shortly.

    In the meantime, I’d be happy to walk through your mint flow step-by-step and map where enforcement would hook in.

    I hope to hear from you soon

  7. #7Scott Long29-04-2026source ↗

    Maranda — apologies for the gap. The thread got buried during a heavy deploy week (LVC just went public-internet at https://app.longviewcompute.com on closed-alpha Sunday). The TokenProof prototype mapped to LVC sounds like exactly the right next step — yes, let's move on it.

    One thing upfront so we're calibrated for the design work you're about to do: LVC is a solo build (me + an AI pair-programmer), build-in-public, just connected to Canton DevNet this week. The architecture I'll describe is accurate to what's actually running — but my deliverable cadence will be slower than a team's, and I'll calibrate depth to what I can speak to honestly. Wanted you to have the right picture before we go deeper.

    On your proposed enforcement matrix — the four points you listed (issuer good-standing, on-ledger quota, policy version stamping, embedded audit) are exactly the off-ledger gaps I'd prioritize, in the same order. If you can produce the TokenProof prototype mapped to those four, here's what I'll deliver from my side:

    1. Mint flow trace — end-to-end sequence from /issuer/mint form submission through the Daml choice exercise on the participant, with every off-ledger gating point (issuer good-standing, content category, quota consumption, audit log write) labeled in line at its current location.
    2. Issuer lifecycle state diagram — applied → approved → active → suspended → reinstated → revoked, with the authoritative source for each transition (admin endpoint, daily counter, policy violation).
    3. Code references — pointers into NFTController.java, the relevant Daml templates, IssuerService, and IssuerAuditService so you can see the actual surface you'd be hooking into. Repo is currently private; I can share specific file excerpts via redacted gist or a guided async walkthrough — whichever helps your mapping more.

    Roughly a week to deliver all three. Items 1 and 2 are documentation work and should land sooner.

    Async is the right format here — written exchanges produce sharper artifacts than calls for architecture work like this, and we both retain receipts. If we hit something genuinely call-shaped during the prototype mapping, happy to flip to one then.

    Looking forward to your TokenProof flow. If there's a specific input from my side you'd want first to shape your mapping, let me know — otherwise I'll start on the mint flow trace this week.

    — Scott LongView Compute LLC (grant PR #195) LongView Crew — retail Canton dApp + multi-tenant NFT issuer platform longviewcompute.com


  8. #8maranda@compliledger.com01-05-2026source ↗
    Scott —congrats!
     
    I pulled the LongView pieces together as one operating model:
     
    Issuer Directory = control plane
    Wallets = signing / authorization layer
    DeFi Toolkit = transaction composition layer
    Canton = execution and finality layer
    TokenProof would sit between the Issuer Directory and Canton execution layer by turning approved issuer state, quota, content category, and policy version into enforceable transaction conditions.

    So the integration flow would be:
    Issuer Directory → TokenProof Evaluation → ComplianceProof → DeFi Toolkit transaction composition → Wallet signing → Daml mint choice enforcement → ledger-derived audit.
    This keeps your existing off-ledger review process intact, but moves the enforcement of the result into the Canton transaction itself.
     
    I’ll map this next against the mint flow trace once you send it, but wanted to share this initial model to make sure I’m understanding the LongView architecture correctly.
  9. #9Scott Long01-05-2026source ↗

    Maranda — that's a clean operating model and the framing is helpful. One layer needs a correction before the prototype goes deeper:

    DeFi Toolkit isn't in the issuer mint path. It's the retail consumer compose-sign-submit surface (transfer, preapproval, traffic top-up). The issuer mint flow is a separate path: Issuer Dashboard (UI) → NFTController → IssuerController.tryConsumeMintQuota → Daml MembershipNFT create → ledger.

    The other three layers map as you described. One important caveat on wallets: today, issuer mints authenticate via API token (X-Issuer-Token header), not CIP-0103 wallet signing. We treat that as a v0.0.2 expedient with wallet-based issuer auth on the roadmap. Retail flows are already wallet-signed; issuer flows are still API-token.

    I've put together the mint flow trace artifact early — attached as COMPLILEDGER_MINT_FLOW_TRACE.md. It includes:

    • Component map with file:line references for every relevant surface
    • Sequence diagram with real method names
    • Step-by-step trace through IssuerDashboardView → NFTController.gift → IssuerController.tryConsumeMintQuota → mintInternal, with code excerpts inline so you don't need the repo
    • The four off-ledger gates (Gates A–D) called out individually, each with: where the check happens, source of truth today, failure mode, and [TokenProof candidate: ...] callouts
    • Daml deep-dive on MembershipNFT and IssuerRegistration templates, with a sketch of what the new IssuerRegistration_Mint choice would look like with all four gates as preconditions
    • Issuer lifecycle state machine with authoritative source for each transition
    • Section 8: a one-page summary table mapping each gate to today's enforcement site → TokenProof target

    Two honest gaps the trace surfaces that are worth your attention regardless of TokenProof timing:

    • Gate B (content category) — the field is collected on the Application but isn't propagated to the runtime Issuer record at approval, so it's not actually enforced anywhere today. Schema gap upstream of the enforcement gap.
    • Gate D (audit on mint) — IssuerAuditService.append fires on every lifecycle event but not on mint. We'll add an audit row for parity in the next iteration; happy to defer if you'd rather have the ledger transaction itself be the audit from day one (which is the right end-state).

    Lifecycle state diagram is in Section 7 of the same artifact. I'll skip the separate code-references doc since the line numbers are inline throughout.

    Looking forward to your TokenProof prototype mapped to this. If anything in the trace doesn't match what you'd assumed about LVC's architecture, easier to surface now than after the prototype is drafted.

    Also including a beta code and login instructions so you can feel the flow of the app as opposed to just reading script.

    Welcome to LongView Crew beta!
      Sign in: https://app.longviewcompute.com/login
      Username: tester16
      Beta code: LVC-C-16-e71f3044

      On first sign-in, you'll be asked to set your own password and
      update your profile (real email, display name). After that, the
      beta code is no longer valid — your real password takes over.

      Have fun, kick the tires, send feedback via the link in the footer.

    — Scott LongView Compute LLC (grant PR #195) LongView Crew — retail Canton dApp + multi-tenant NFT issuer platform longviewcompute.com


  10. #10maranda@compliledger.com04-05-2026source ↗
    Scott — this trace is exactly what I needed. I’ve re-anchored the TokenProof prototype to the actual issuer mint path:
    Issuer Dashboard → NFTController.gift() → authenticate() → IssuerController.tryConsumeMintQuota() → mintInternal() → MembershipNFT create.
    Key correction understood: DeFi Toolkit is not in the issuer mint path, and issuer mints currently use X-Issuer-Token rather than CIP-0103 wallet signing. I’ll keep that separated from the retail flow.
    Based on your trace, I’m mapping TokenProof around the four gates as follows:
    Gate A — Issuer good-standing:
    Move the Active/Suspended/Revoked check from tryConsumeMintQuota() into a Daml precondition on IssuerRegistration_Mint.
    Gate B — Content category:
    Treat this as both a schema propagation gap and an enforcement gap. Application.contentCategories needs to flow into IssuerRegistration.approvedCategories, then mint asserts requested category is approved.
    Gate C — Quota:
    Replace the JVM-local mintedToday counter with an on-ledger IssuerMintQuota contract consumed atomically in the same mint transaction.
    Gate D — Audit:
    Use the mint transaction itself as the audit record, with proof hash, policy version, issuer status, and quota state embedded in the execution context.
    The clean target shape appears to be:
    NFTController submits an IssuerRegistration_Mint choice carrying proofCid + quotaCid, and Canton enforces all four gates before MembershipNFT is created.
    I’ll now turn this into a more formal prototype mapping using your method names and gate labels.
  11. #11maranda@compliledger.com07-05-2026source ↗
    Scott —
     
    I revised the TokenProof mapping based directly on your mint flow trace and architecture corrections.
     
    The key adjustment was re-anchoring the prototype to the actual issuer mint path:
    Issuer Dashboard
    → NFTController.gift()
    → authenticate()
    → IssuerController.tryConsumeMintQuota()
    → mintInternal()
    → MembershipNFT create
    → Canton ledger
     
    (understood now that the DeFi Toolkit is not part of the issuer mint path, and issuer auth is currently API-token based rather than wallet-signed).
     
    The revised model treats TokenProof as an enforcement layer at the controller + Daml execution boundary rather than a transaction composition layer.
    Current mapping by gate:
     
    Gate A — Issuer Good-Standing
     
    Current:
    Issuer active/suspended state enforced in Java inside tryConsumeMintQuota() against JVM-local issuer state.
     
    Risk:
    Execution depends on backend state propagation and API-token validity rather than Canton-enforced transaction conditions.
     
    Target:
    Move issuer status enforcement into the Daml execution path itself.
     
    Proposed shape:
    IssuerRegistration_Mint choice asserts issuer status == Active before MembershipNFT creation proceeds.
     
    Result:
    Suspended/revoked issuers fail atomically inside the Canton transaction itself.
     
    Gate B — Content Category Permission
     
    Current:
    Content category collected at application time but not propagated into runtime issuer state or enforced during mint execution.
     
    Risk:
    Approved issuer categories are informational rather than enforceable.
     
    Target:
    Propagate approvedCategories from onboarding → IssuerRegistration runtime state → Daml precondition.
     
    Proposed shape:
    Mint asserts requestedCategory ∈ approvedCategories.
     
    Result:
    Category authorization becomes enforceable at execution time rather than dependent on off-ledger convention.
     
    Also agree with your observation that this is both:
    1. a schema propagation gap
    2. an enforcement gap
     
    Gate C — Daily Quota
    Current:
    Quota enforced off-ledger in tryConsumeMintQuota() using JVM-local counters + persistAll().
     
    Risk:
    Race conditions under scaling, crash windows between quota consumption and mint, UTC rollover edge cases, multi-instance synchronization problems.
     
    Target:
    Move quota into an on-ledger consumable state object.
     
    Proposed shape:
    IssuerMintQuota contract fetched + consumed atomically inside IssuerRegistration_Mint.
     
    Result:
    Quota check + quota consumption + mint occur in the same Canton transaction with no reconciliation window.
     
    Gate D — Audit on Mint
    Current:
    IssuerAuditService captures lifecycle events but mint execution itself is not currently part of the audit trail.
     
    Risk:
    Audit remains a sidecar system requiring reconciliation against ledger truth.
     
    Target:
    Use the ledger transaction itself as the compliance audit artifact.
    Proposed shape:
    Mint transaction embeds:
    - issuer
    - category
    - policyVersion
    - proofHash
    - quota state
    - timestamp
    - decisionStatus
     
    Result:
    Ledger becomes the authoritative audit source rather than an external append-only mirror.
     
    The clean architectural target now appears to be:
     
    NFTController submits an IssuerRegistration_Mint choice carrying:
    - proofCid
    - quotaCid
    - requestedCategory
    - requestedPolicyVersion
     
    Then Canton enforces all four gates atomically before MembershipNFT creation.
    I’m refining the prototype mapping + updated architecture diagram now using your method names and flow structure so it maps directly to what’s actually running rather than an abstract model.
     
    This trace was extremely useful — especially the explicit gate breakdown and lifecycle ownership mapping.
     
    Best,
    Maranda
  12. #12Scott Long07-05-2026source ↗

    Maranda — this is a clean, faithful translation of the trace into TokenProof terms. The four-gate mapping reads exactly as I'd want it: enforcement at the choice precondition layer, IssuerMintQuota as on-ledger consumable, ledger transaction as the audit artifact, no off-ledger reconciliation. That's the right end-state.

    A few refinements that came up reading through, mostly to make the spec more buildable against the actual platform shape:

    1. Per-issuer quota scope. IssuerMintQuota needs to be keyed per-issuer (and per-day, given UTC-rollover). Two issuers minting concurrently shouldn't contend on the same quota contract. Cleanest pattern is probably a (issuerParty, day) composite key with one quota contract per issuer per active day — does that match what you had in mind?
    2. IssuerRegistration lifecycle as Daml choices. Today, admin status changes mutate JPA state. For Gate A to be ledger-truth, those transitions need to be Daml choices on IssuerRegistration controlled by the platform party. The mint precondition checks status; the question is what authority writes status. Worth being explicit in the spec that the platform-admin party is a controller on those lifecycle choices.
    3. Migration / backfill. Existing issuers currently live in JPA state and would need to be hydrated into IssuerRegistration contracts on the ledger as part of rollout. Worth getting into the spec early so it's not discovered at integration time.
    4. policyVersion authority chain. Platform admin publishes policy packs; issuers accept a specific version at onboarding; mints assert the version that applied at submission. Open question: is the on-ledger publisher a platform-party-signed UserContentPolicy contract, with that contract's contractId serving as the policyVersion the mint asserts against?
    5. Cost benchmark. Still very interested in concrete numbers when you have them — per-mint overhead of (proof fetch + assertion + quota consume) vs. a vanilla mint on Canton DevNet. That's the threshold that decides whether retail-scale issuance can absorb the compliance layer at our 5-CC artistic-NFT price point.

    Glad to be building alongside the TokenProof work in public — Canton's retail layer needs more of this kind of cross-team architecture exchange, and grants-discuss is the right venue for it. Looking forward to your updated diagram and where the prototype lands next.

    Best, Scott


  13. #13maranda@compliledger.com11-05-2026source ↗
    Scott —
    At this point we’ve gotten deep enough into the architecture/design side that it may make sense to move the TokenProof × LVC work out of the grants-discuss thread and coordinate directly as well.
    The async exchange has actually been extremely productive, but I think having direct email / occasional working sessions would make it easier to iterate on:
    - the Daml choice structure
    - quota model
    - lifecycle authority chain
    - migration/backfill approach
    - benchmark testing
    especially as the prototype becomes more concrete.
    Happy to keep major updates public in grants-discuss for ecosystem visibility, but figured direct coordination may make the actual design/build loop smoother.
    If you’re open to it, feel free to email me directly at maranda@..., and I’d also be happy to jump on a working session sometime this week or next.
    Really appreciate the depth of engagement here — this has evolved into a very strong architecture collaboration.
    Best,
    Maranda
  14. #14Scott Long11-05-2026source ↗

    Maranda — agreed the design conversation has gotten deep enough that direct coordination would tighten the iteration loop. Before we move off-list, I want to be explicit about what's working: the async exchange has produced public artifacts (your TokenProof gate mapping; my mint flow trace) that have value for both sides and for the ecosystem. I'd like to preserve that.

    Two things I'd want to lock in as we shift channels:

    1. Design partner status formalized. Happy to keep contributing architecture input to TokenProof if LVC is named CompLiLedger's first design partner — on your site, in your grant deliverables, and in the eventual public release. That's the value capture that makes the time investment work for a solo team.
    2. Public artifact cadence. Major design milestones (next prototype iteration, benchmark results, integration spec finalization) get a public summary on grants-discuss. Working details live in direct email.

    If both of those are workable, my email is below. I'd suggest one async round next week — your updated mapping responding to the five refinements I sent on May 7, against which I can pre-write reactions before any call. Async-first is still where we get the sharpest output; we flip to call only if a topic is genuinely call-shaped.

    Best, Scott longsw1984@...


  15. #15maranda@compliledger.com12-05-2026source ↗
    Scott —
    Completely aligned on preserving the public artifact side of this. I agree the async exchange has become valuable not just for the TokenProof proposal itself, but as a broader ecosystem discussion around how execution-level enforcement could evolve on Canton.
     
    Formalizing LongView Compute as CompLiLedger’s first design partner is absolutely workable from my side. Given how much the architecture has evolved through the LVC collaboration, I think that accurately reflects the role your platform is playing in shaping the prototype against a real issuer workflow.
     
    I also agree the relationship should remain mutually referenceable as the work progresses:
    - LVC recognized publicly as the first TokenProof design partner
    - CompLiLedger able to reference the collaboration and integration work
    - continued public technical discussion where ecosystem-relevant
     
    The public artifact cadence makes complete sense to me as well:
    - detailed iteration / working design via direct email
    - milestone summaries and ecosystem-relevant outputs shared publicly in grants-discuss
     
    I think that strikes the right balance between focused collaboration and preserving the ecosystem value of the work.
     
    I’ll send over the updated prototype iteration responding to the five refinements next week so you have space to review async first before we determine whether anything is genuinely call-shaped.
     
    Really appreciate the level of engagement here — this has evolved into a genuinely strong architecture collaboration.
     
    Best,
    Maranda
  16. #16Scott Long12-05-2026source ↗
    Maranda,

    This works for me across the board. Glad we landed in the same place — the async exchange has been productive precisely because it's been substantive, and keeping the ecosystem-relevant pieces public preserves that value.

    Formalizing LongView Compute as CompLiLedger's first TokenProof design partner, with mutual referenceability and the public/private cadence you described, is exactly the right structure.

    I'll look out for the updated prototype next week. Async review first makes sense — I'll come back with written feedback before we decide if anything warrants a call.

    Appreciate the partnership on this. The architecture is in a genuinely strong place.

    Best,
    Scott