Does This Problem Resonate with Others Building on Canton?
globalSyncForum4 messagesstarted 14-05-2026
- Over the past several months, I’ve been increasingly focused on a question that seems central to the future of programmable markets and institutional tokenization:
If settlement becomes atomic and programmable, can compliance continue to operate as a sequential, off-chain process built around legacy workflows?
Recent discussions around “atomic compliance” on Canton strongly resonate with me — particularly the idea that sanctions checks, Travel Rule obligations, and compliance outcomes should be resolved within the same coordinated transaction flow as settlement itself.
I believe regulation is increasingly pushing the industry in this direction, especially with the GENIUS Act, CLARITY Act, and broader global focus on real-time supervisory expectations for tokenized financial systems.
The area I’ve been exploring through CompliLedger / TokenProof is what comes next beyond transaction-level compliance:
- persistent governance state
- rule/version lineage
- reproducible compliance proofs
- lifecycle enforcement
- solvency and authorization validation
- deterministic audit replay across the lifecycle of an asset or transaction
In other words, not just “was this transaction compliant at execution time,” but:
- what rules were active,
- what proofs were relied upon,
- what governance state existed,
- and can the decision be reproduced deterministically later?
I’m currently looking to validate whether this broader infrastructure direction resonates with:
1. a major issuer, and
2. a financial institution or market participant
particularly within the context of Canton, tokenized markets, and institutional digital asset infrastructure.
Would genuinely appreciate perspectives from others building in this space:
- Does this problem resonate?
- Are institutions beginning to think about compliance and governance as part of the transaction architecture itself rather than an external process layer?
- Is there interest in deterministic, lifecycle-level proof infrastructure beyond atomic transaction compliance?
Happy to connect directly with anyone exploring similar architecture challenges.Maranda, Founder - Compliledger - Just to caveat: Im speaking as someone who knows little about compliance hence my request to see the demo for atomic compliance.toggle quoted message Show quoted text
A couple of points come to my mind:
(1) Any transaction can have a set of conditions or tests to pass or fail. Whether those are regulatory orientated or whatever.(2) Canton in particular allows parties to participate or not in a transaction through its privacy components.(3) Compliance covers a multitude of factors and is a relative test.
I dont see how the transaction layer itself should have anything to do with compliance. That’s a binary type situation. If you are able to transact, then you are compliant by definition with whatever ruleset is being applied.I can see multiple layers above to determine what that compliance might look like and that may be much more efficient than the current provider APIs. I can see specialist validators that run this type of software. I can see immutable state records of the transaction and conditions.I fail to see true “atomicity” in a legal or financial compliance sense since the external factors that drive this require external validation.
That said there’s plenty of ways to design systems that achieve any of this optimally using DAML and tools based on the general rules/ eligibility. That makes sense but I would say it needs to be built in conjunction with real demand and utility first - who wants this atomicity and why? I obviously dont know the answer but that would be my starting point.
Looking forward to learning more.
Daryn
On 14 May 2026, at 12:09, Maranda Harris via lists.sync.global <maranda=compliledger.com@...> wrote:
Over the past several months, I’ve been increasingly focused on a question that seems central to the future of programmable markets and institutional tokenization:
If settlement becomes atomic and programmable, can compliance continue to operate as a sequential, off-chain process built around legacy workflows?
Recent discussions around “atomic compliance” on Canton strongly resonate with me — particularly the idea that sanctions checks, Travel Rule obligations, and compliance outcomes should be resolved within the same coordinated transaction flow as settlement itself.
I believe regulation is increasingly pushing the industry in this direction, especially with the GENIUS Act, CLARITY Act, and broader global focus on real-time supervisory expectations for tokenized financial systems.
The area I’ve been exploring through CompliLedger / TokenProof is what comes next beyond transaction-level compliance:
- persistent governance state
- rule/version lineage
- reproducible compliance proofs
- lifecycle enforcement
- solvency and authorization validation
- deterministic audit replay across the lifecycle of an asset or transaction
In other words, not just “was this transaction compliant at execution time,” but:
- what rules were active,
- what proofs were relied upon,
- what governance state existed,
- and can the decision be reproduced deterministically later?
I’m currently looking to validate whether this broader infrastructure direction resonates with:
1. a major issuer, and
2. a financial institution or market participant
particularly within the context of Canton, tokenized markets, and institutional digital asset infrastructure.
Would genuinely appreciate perspectives from others building in this space:
- Does this problem resonate?
- Are institutions beginning to think about compliance and governance as part of the transaction architecture itself rather than an external process layer?
- Is there interest in deterministic, lifecycle-level proof infrastructure beyond atomic transaction compliance?
Happy to connect directly with anyone exploring similar architecture challenges.
Maranda, Founder - Compliledger
- Daryn — I agree with most of your framing, but I’d push back on one point:“If you are able to transact, then you are compliant by definition” is only true if the transaction logic actually includes the relevant compliance conditions.In many tokenized asset systems today, a transaction can be technically valid, properly signed, and accepted by the ledger — but still not be compliant from a regulatory, issuer-control, reserve, eligibility, or audibility standpoint.That’s the gap I’m focused on.The issue is not that every part of compliance should live inside the transaction layer. I agree that many determinations will still happen externally through validators, compliance services, legal review, risk systems, etc.The question is whether certain execution-critical compliance results should become transaction preconditions once they are determined.For example:
- issuer is still in good standing
- mint/issuance limits have not been exceeded
- the relevant policy version is the one being applied
- required reserve/eligibility proof is active
- the transaction creates an auditable record of which proof/state was relied onThose are not “all of compliance.”They are the conditions that determine whether execution should be allowed.So the thesis is not “compliance belongs entirely on-chain.”It is:External compliance determination may still happen off-chain, but execution-critical compliance state should be enforceable at the transaction layer.That’s especially important as GENIUS / CLARITY push the market toward stronger issuer accountability, clearer asset classification, and provable auditability.Really appreciate the pushback — it helps sharpen the framing. - Hi Maranda,toggle quoted message Show quoted textI think we are saying the same thing only you can express it better than myself. The ‘gap’ that needs the work is in the rules and conditions that need to be applied to the transaction - which varies by industry, jurisdiction, regulatory bodies, point in time and so on.The use of DAML is its unwavering insistence on enforcing the rules it is provided with.Look forward to seeing these products evolve.Daryn
On 14 May 2026, at 18:32, Maranda Harris via lists.sync.global <maranda=compliledger.com@...> wrote:
Daryn — I agree with most of your framing, but I’d push back on one point:“If you are able to transact, then you are compliant by definition” is only true if the transaction logic actually includes the relevant compliance conditions.In many tokenized asset systems today, a transaction can be technically valid, properly signed, and accepted by the ledger — but still not be compliant from a regulatory, issuer-control, reserve, eligibility, or audibility standpoint.That’s the gap I’m focused on.The issue is not that every part of compliance should live inside the transaction layer. I agree that many determinations will still happen externally through validators, compliance services, legal review, risk systems, etc.The question is whether certain execution-critical compliance results should become transaction preconditions once they are determined.For example:
- issuer is still in good standing
- mint/issuance limits have not been exceeded
- the relevant policy version is the one being applied
- required reserve/eligibility proof is active
- the transaction creates an auditable record of which proof/state was relied onThose are not “all of compliance.”They are the conditions that determine whether execution should be allowed.So the thesis is not “compliance belongs entirely on-chain.”It is:External compliance determination may still happen off-chain, but execution-critical compliance state should be enforceable at the transaction layer.That’s especially important as GENIUS / CLARITY push the market toward stronger issuer accountability, clearer asset classification, and provable auditability.Really appreciate the pushback — it helps sharpen the framing.
