#853 Proposal: Veilio Governed Off-Ledger Data Exchange (RFP #12.1)

Noosphere-314commented02-10-2026 · 1mo agoGitHub ↗

@Slyraack, I read the proposal's status-only ELIGIBILITY example from the consuming application's side. The application would still need an agreed meaning for the eligibility status and a reliable link to the subject of the gated action.

The passport identifies the subject with an opaque handle, while the action is performed for a specific party or account. What is the intended trust mechanism for binding that subject handle to the party or account being authorized: a statement by the issuer/Owner, an agreed mapping in the integration, or another mechanism?

Slyraackcommented05-10-2026 · 1mo agoGitHub ↗

@Noosphere-314 Good catch, and thanks for the time spent on this, and for reading the status-only ELIGIBILITY path from the consuming application’s side.

The intended V1 trust model is that the binding between the opaque subject handle and the Canton party or account being authorized comes from a statement by the issuer/Owner. Passport metadata (or a CIP Credentials claim when that standard is available) carries the opaque subjectHandle together with an attested link to the Party or account id in scope for the gated action. A consuming application should not treat “any active ELIGIBILITY passport exists” as sufficient: it must check that the acting party of the transaction matches the party bound on that passport.

ELIGIBILITY itself is also not meant as a bare boolean. The agreed meaning comes from credentialType=ELIGIBILITY plus scoped metadata such as purpose and, where relevant, asset class or jurisdiction, so both sides share a workflow-specific definition of what “eligible” means.

Bilateral integration mappings between handles and parties may still exist for operational convenience, but they are not the trust root. Issuer attestation of the handle-to-party binding is. This grant does not invent a global identity registry; we intend to align handles and claims with the draft Canton Network Credentials Standard (CIP #204) as it stabilizes, while Access Passport remains the access-governance layer on top of that binding.

From your experience in the Canton ecosystem and RWA / credentials workflows, does issuer-attested handle-to-party binding feel like the right default for V1, or would you recommend leaning more on CIP Credentials claims (or another pattern builders already use) as the primary binding mechanism?

Noosphere-314commented07-10-2026 · 1mo agoGitHub ↗

@Noosphere-314 Good catch, and thanks for the time spent on this, and for reading the status-only ELIGIBILITY path from the consuming application’s side.

The intended V1 trust model is that the binding between the opaque subject handle and the Canton party or account being authorized comes from a statement by the issuer/Owner. Passport metadata (or a CIP Credentials claim when that standard is available) carries the opaque subjectHandle together with an attested link to the Party or account id in scope for the gated action. A consuming application should not treat “any active ELIGIBILITY passport exists” as sufficient: it must check that the acting party of the transaction matches the party bound on that passport.

ELIGIBILITY itself is also not meant as a bare boolean. The agreed meaning comes from credentialType=ELIGIBILITY plus scoped metadata such as purpose and, where relevant, asset class or jurisdiction, so both sides share a workflow-specific definition of what “eligible” means.

Bilateral integration mappings between handles and parties may still exist for operational convenience, but they are not the trust root. Issuer attestation of the handle-to-party binding is. This grant does not invent a global identity registry; we intend to align handles and claims with the draft Canton Network Credentials Standard (CIP #204) as it stabilizes, while Access Passport remains the access-governance layer on top of that binding.

From your experience in the Canton ecosystem and RWA / credentials workflows, does issuer-attested handle-to-party binding feel like the right default for V1, or would you recommend leaning more on CIP Credentials claims (or another pattern builders already use) as the primary binding mechanism?

@Slyraack, thanks. For V1, an issuer-attested binding looks like a reasonable basis for the consumer check, with the application checking both the acting account and the scope of ELIGIBILITY. The trust boundary matters more to us than whether the attestation is initially carried in passport metadata or a CIP credential.

In our proposed Zenith reference application, the gated action is performed by an EVM address. Is a binding to that account type in scope for V1, or should the consumer combine your handle-to-party attestation with a separate party-to-address registration?

Slyraackcommented07-10-2026 · 1mo agoGitHub ↗

@Noosphere-314 Good catch, and thanks for the time spent on this, and for reading the status-only ELIGIBILITY path from the consuming application’s side. The intended V1 trust model is that the binding between the opaque subject handle and the Canton party or account being authorized comes from a statement by the issuer/Owner. Passport metadata (or a CIP Credentials claim when that standard is available) carries the opaque subjectHandle together with an attested link to the Party or account id in scope for the gated action. A consuming application should not treat “any active ELIGIBILITY passport exists” as sufficient: it must check that the acting party of the transaction matches the party bound on that passport. ELIGIBILITY itself is also not meant as a bare boolean. The agreed meaning comes from credentialType=ELIGIBILITY plus scoped metadata such as purpose and, where relevant, asset class or jurisdiction, so both sides share a workflow-specific definition of what “eligible” means. Bilateral integration mappings between handles and parties may still exist for operational convenience, but they are not the trust root. Issuer attestation of the handle-to-party binding is. This grant does not invent a global identity registry; we intend to align handles and claims with the draft Canton Network Credentials Standard (CIP #204) as it stabilizes, while Access Passport remains the access-governance layer on top of that binding. From your experience in the Canton ecosystem and RWA / credentials workflows, does issuer-attested handle-to-party binding feel like the right default for V1, or would you recommend leaning more on CIP Credentials claims (or another pattern builders already use) as the primary binding mechanism?

@Slyraack, thanks. For V1, an issuer-attested binding looks like a reasonable basis for the consumer check, with the application checking both the acting account and the scope of ELIGIBILITY. The trust boundary matters more to us than whether the attestation is initially carried in passport metadata or a CIP credential.

In our proposed Zenith reference application, the gated action is performed by an EVM address. Is a binding to that account type in scope for V1, or should the consumer combine your handle-to-party attestation with a separate party-to-address registration?

@Noosphere-314 Thanks, that framing helps, and the Zenith example is useful.

We agree that for V1 the trust boundary (issuer-attested binding) matters more than whether the attestation lives in passport metadata or a CIP Credentials claim.

On EVM accounts: rather than decide in the abstract, we’d like to understand how real the need is in practice. In Zenith (and similar apps), is the gated action typically authorized for an EVM address with only a loose/off-chain link to a Canton Party, or do you already have a reliable party-to-address registration that consuming apps can reuse?

If builders commonly need to authorize an EVM address directly from an eligibility/access check, we can treat first-class EVM account binding (or an explicit passport → EVM account attestation) as an adoption-driven extension and document the preferred composition pattern. If most flows already go through a Canton Party with a separate address mapping, we would keep the passport V1 binding Canton-native and show how to compose with that mapping.

Curious what you’ve seen works best in the ecosystem so far, happy to align the reference design with whatever pattern Zenith and Zenith-like apps actually need. We can amplify a bit our proposal and the tech we want to develop.

OsDevilcommented09-10-2026 · 1mo agoGitHub ↗

Hi @Slyraack, following this thread with interest from the training/compliance side.

Context: we run a quiz and training platform used by large corporates and schools, including regulated firms (insurance, financial services). A recurring pain point for us is proving that mandatory training was completed (e.g. annual insurance distribution training hours, AML awareness) to a party other than the employer: the insurer, an auditor, or a supervisor.

An Access Passport scoped to a training/certification attestation, with PII kept off-ledger and revocation the counterparty can check independently, maps closely to that need. I'd be interested in evaluating it as an issuer once the reference stack is on TestNet.

A few questions:

Credential types: is credentialType meant to be extensible beyond KYC/ELIGIBILITY (e.g. TRAINING_COMPLETION with expiry, hours, and the scope of the program)? Time-bound validity with periodic renewal is the norm in our case.
Issuer onboarding: can a SaaS issuer operate without running its own validator (hosted participant, or issuing through the gateway)? That cost largely decides whether smaller issuers adopt it.
Off-Canton consumers: can a verifier whose backend is not Canton-native check status and revocation through the TypeScript library/gateway alone?
GDPR: if the opaque subject handle stays stable across passports, it is likely still personal data under GDPR. What's the intended erasure path: off-ledger deletion only, or rotating handles?

Happy to share our use case in more detail if it helps shape the credential schema.

arthurnatationcommented12-10-2026 · 1mo agoGitHub ↗

@Slyraack ForSwim is a consumer swim-training product: we generate sessions for people who want to swim and don't know what to do in the water. We are looking at Canton for cross-person sharing of a personal training package where access rights are not only controlled inside our IAM, but can be verified by both sides.

One question from that consumer-app angle. Our users are not clubs or institutions, they are regular people. The athlete is the GDPR data subject and should decide who may see the plan, while ForSwim remains Owner of the package because we hold the data. The propose → accept → consent flow reads as recipient consent. How should subject consent work when the subject is a consumer, not a Canton party: an off-ledger “I agree to share with this person until date X” receipt referenced in passport metadata, a third signatory on the passport, or out of scope for V1 and left to our IAM? Our product stays Web2 but by integrating web3 things we can be compliant with current regulations, that's what we are looking for. The gap is sharing a personal training package (plan, completed sessions, load, sometimes health constraints) with a freelance coach, a physio, or a training partner. Today we are the only source of truth on access. When the swimmer stops sharing, the other person cannot independently verify that access ended, and a signed export of our logs still requires trusting us. That is the Bank A / Bank B gap, applied person-to-person rather than bank-to-bank KYC.

If I understand well, your Access Passport would map as Owner = ForSwim, Recipient = the person the swimmer picked (one passport, short expiry), on-ledger = purpose + expiry + status with no name, sessions, or health notes, off-ledger = the training package retrieved only while the passport is active, and a status-only path so the recipient can see that access is still valid without pulling the plan into their tools. If that subject-consent path is covered in the adoption guide, we would evaluate the TestNet stack as an issuer once everything is public. Let me know if you need some details regarding our use case.

Slyraackcommented12-10-2026 · 1mo agoGitHub ↗

Hi @Slyraack, following this thread with interest from the training/compliance side.

Context: we run a quiz and training platform used by large corporates and schools, including regulated firms (insurance, financial services). A recurring pain point for us is proving that mandatory training was completed (e.g. annual insurance distribution training hours, AML awareness) to a party other than the employer: the insurer, an auditor, or a supervisor.

An Access Passport scoped to a training/certification attestation, with PII kept off-ledger and revocation the counterparty can check independently, maps closely to that need. I'd be interested in evaluating it as an issuer once the reference stack is on TestNet.

A few questions:

Credential types: is credentialType meant to be extensible beyond KYC/ELIGIBILITY (e.g. TRAINING_COMPLETION with expiry, hours, and the scope of the program)? Time-bound validity with periodic renewal is the norm in our case.

Issuer onboarding: can a SaaS issuer operate without running its own validator (hosted participant, or issuing through the gateway)? That cost largely decides whether smaller issuers adopt it.

Off-Canton consumers: can a verifier whose backend is not Canton-native check status and revocation through the TypeScript library/gateway alone?

GDPR: if the opaque subject handle stays stable across passports, it is likely still personal data under GDPR. What's the intended erasure path: off-ledger deletion only, or rotating handles?

Happy to share our use case in more detail if it helps shape the credential schema.

@OsDevil Thanks for the corporate training / AML attestation angle, that maps cleanly to the same Access Passport primitive (purpose-bound, time-limited, revocable access with an optional Observer), and TRAINING_COMPLETION is a useful stress-test of the schema beyond bank KYC.

On credential types: the proposal leads with the six RFP #12.1 categories as first-class credentialType values, but the intent is not a closed world. V1 should treat that set as the interoperable core for RWA/credentials reuse, while allowing extension via additional typed values (for example TRAINING_COMPLETION) plus scoped metadata such as purpose, expiry, program scope, and hours. Heavy or sensitive detail stays off-ledger in the package; on-ledger keeps only what a verifier or auditor needs for status and revocation. We would rather document an extension convention in the adoption guide than force every training issuer into a KYC-shaped type.

On issuer onboarding without a self-operated validator: the grant delivers DAR + gateway interface + TypeScript library, not a hosted validator product. An issuer can still participate without running their own validator by using a hosted participant / party-hosting provider and talking to Canton through that participant plus the gateway against their existing Web2 storage. That is exactly the chain-abstraction model in the proposal. Validator cost as an adoption filter is real; we expect most SaaS issuers to start on hosted participation, while the public reference deployment (via Avicenne) remains available for evaluation on TestNet.

On off-Canton consumers: independent status and revocation checks require a Canton read path somewhere, otherwise you are back to trusting the issuer’s API alone. A verifier that is not Canton-native can still consume status through the TypeScript library (or an equivalent gateway read) against a participant they can query, including as Observer if they only need governance state and not the training payload. Pure “HTTP only, no Canton connectivity at all” cannot give multiparty ledger proof; the useful pattern for Web2 backends is a thin Canton read client, not a full app rewrite.

On GDPR and stable subject handles: agreed that a stable opaque handle can still be personal data if it is reasonably linkable. The intended V1 posture is: no PII on-ledger; prefer rotating or purpose-scoped handles where erasure is required; revoke/archive related passports; delete or crypto-shred the off-ledger package and any issuer-side mapping that re-identifies the handle. A forever-stable global handle across all passports is not the recommended erasure story. This is a design stance for the reference stack, not legal advice. Anyway, happy to refine the adoption-guide wording with your training/AML constraints if useful.

If that direction fits, we would welcome your TRAINING_COMPLETION metadata sketch for the schema appendix, and would be glad to have you evaluate the TestNet stack once the DAR and library are public.

Noosphere-314commented12-10-2026 · 1mo agoGitHub ↗

@Noosphere-314 Good catch, and thanks for the time spent on this, and for reading the status-only ELIGIBILITY path from the consuming application’s side. The intended V1 trust model is that the binding between the opaque subject handle and the Canton party or account being authorized comes from a statement by the issuer/Owner. Passport metadata (or a CIP Credentials claim when that standard is available) carries the opaque subjectHandle together with an attested link to the Party or account id in scope for the gated action. A consuming application should not treat “any active ELIGIBILITY passport exists” as sufficient: it must check that the acting party of the transaction matches the party bound on that passport. ELIGIBILITY itself is also not meant as a bare boolean. The agreed meaning comes from credentialType=ELIGIBILITY plus scoped metadata such as purpose and, where relevant, asset class or jurisdiction, so both sides share a workflow-specific definition of what “eligible” means. Bilateral integration mappings between handles and parties may still exist for operational convenience, but they are not the trust root. Issuer attestation of the handle-to-party binding is. This grant does not invent a global identity registry; we intend to align handles and claims with the draft Canton Network Credentials Standard (CIP #204) as it stabilizes, while Access Passport remains the access-governance layer on top of that binding. From your experience in the Canton ecosystem and RWA / credentials workflows, does issuer-attested handle-to-party binding feel like the right default for V1, or would you recommend leaning more on CIP Credentials claims (or another pattern builders already use) as the primary binding mechanism?

@Slyraack, thanks. For V1, an issuer-attested binding looks like a reasonable basis for the consumer check, with the application checking both the acting account and the scope of ELIGIBILITY. The trust boundary matters more to us than whether the attestation is initially carried in passport metadata or a CIP credential. In our proposed Zenith reference application, the gated action is performed by an EVM address. Is a binding to that account type in scope for V1, or should the consumer combine your handle-to-party attestation with a separate party-to-address registration?

@Noosphere-314 Thanks, that framing helps, and the Zenith example is useful.

We agree that for V1 the trust boundary (issuer-attested binding) matters more than whether the attestation lives in passport metadata or a CIP Credentials claim.

On EVM accounts: rather than decide in the abstract, we’d like to understand how real the need is in practice. In Zenith (and similar apps), is the gated action typically authorized for an EVM address with only a loose/off-chain link to a Canton Party, or do you already have a reliable party-to-address registration that consuming apps can reuse?

If builders commonly need to authorize an EVM address directly from an eligibility/access check, we can treat first-class EVM account binding (or an explicit passport → EVM account attestation) as an adoption-driven extension and document the preferred composition pattern. If most flows already go through a Canton Party with a separate address mapping, we would keep the passport V1 binding Canton-native and show how to compose with that mapping.

Curious what you’ve seen works best in the ecosystem so far, happy to align the reference design with whatever pattern Zenith and Zenith-like apps actually need. We can amplify a bit our proposal and the tech we want to develop.

@Slyraack, thanks. Our Zenith example is a proposed reference flow in which an EVM address performs the gated action. We haven't yet validated that this is a common pattern in deployed credential-gated Zenith applications.

There is a concrete address-link candidate in ChainSafe's #453 middleware: registration creates a FingerprintMapping, and a signed login token carries evm_address and canton_party_id. A separate service can use the user's authenticated session; on its own deployment, it can read the visible mappings for users registered there. The application still needs to trust that middleware deployment. This establishes the address link, not the issuer's eligibility decision. Zenith Gateway's inbox/mailbox links serve token routing.

For our proposed flow, Canton-native V1 plus documented composition with that registration is a reasonable starting point. The consumer checks the issuer-attested subject-to-party link, the acting wallet's registration and the current, scoped eligibility decision. Your clarification to OsDevil about a participant-backed read path for off-Canton consumers fits that approach.

An EVM-specific binding extension would be worth considering once a named issuer and consuming application require it.

Slyraackcommented12-10-2026 · 1mo agoGitHub ↗

@Slyraack ForSwim is a consumer swim-training product: we generate sessions for people who want to swim and don't know what to do in the water. We are looking at Canton for cross-person sharing of a personal training package where access rights are not only controlled inside our IAM, but can be verified by both sides.

One question from that consumer-app angle. Our users are not clubs or institutions, they are regular people. The athlete is the GDPR data subject and should decide who may see the plan, while ForSwim remains Owner of the package because we hold the data. The propose → accept → consent flow reads as recipient consent. How should subject consent work when the subject is a consumer, not a Canton party: an off-ledger “I agree to share with this person until date X” receipt referenced in passport metadata, a third signatory on the passport, or out of scope for V1 and left to our IAM? Our product stays Web2 but by integrating web3 things we can be compliant with current regulations, that's what we are looking for. The gap is sharing a personal training package (plan, completed sessions, load, sometimes health constraints) with a freelance coach, a physio, or a training partner. Today we are the only source of truth on access. When the swimmer stops sharing, the other person cannot independently verify that access ended, and a signed export of our logs still requires trusting us. That is the Bank A / Bank B gap, applied person-to-person rather than bank-to-bank KYC.

If I understand well, your Access Passport would map as Owner = ForSwim, Recipient = the person the swimmer picked (one passport, short expiry), on-ledger = purpose + expiry + status with no name, sessions, or health notes, off-ledger = the training package retrieved only while the passport is active, and a status-only path so the recipient can see that access is still valid without pulling the plan into their tools. If that subject-consent path is covered in the adoption guide, we would evaluate the TestNet stack as an issuer once everything is public. Let me know if you need some details regarding our use case.

@arthurnatation Thanks for the ForSwim write-up, the mapping you describe here (Owner = ForSwim, Recipient = coach/physio/partner, package off-ledger, purpose/expiry/status on-ledger, status-only path) is exactly how we intend Access Passport to be used outside bank KYC.

On subject consent vs recipient consent: in V1 they are different layers. The Daml propose → accept → consent lifecycle is recipient consent to the access right (the coach agrees to the passport terms and becomes authorized to retrieve while it is active). GDPR subject consent (the swimmer deciding who may see the plan) sits with the Owner’s product/IAM, because the consumer is usually not a Canton party and we do not require every end user to operate a Party for V1.

The intended V1 pattern is therefore: ForSwim captures the swimmer’s “share with this person until date X” decision off-ledger in the product UX, then issues the passport as Owner with that decision referenced in metadata (for example a consent receipt id / hash / timestamp, no name, no plan content). Revoke/expiry on Canton is what the recipient (and any Observer) can verify independently when sharing stops. That preserves the Bank A / Bank B gap fix without forcing consumers onto the ledger.

A third signatory for the data subject is possible later if the subject has (or is given) a Canton Party, but it is not the V1 default for consumer apps: it raises onboarding and key-management cost for every athlete. Leaving subject consent entirely opaque inside IAM with no metadata receipt is weaker for audit; referencing an off-ledger consent receipt on the passport is the better V1 compromise.

So for your three options: off-ledger subject-consent receipt referenced in passport metadata is the recommended V1 path; third signatory is optional/advanced; “IAM only with nothing on the passport” is possible but not what we would put first in the adoption guide... I will keep this in mind and when we move forward, I can contact you to go deeper in your use cases !

SaveTheAlescontributorcommented13-10-2026 · 1mo agoGitHub ↗

Hey, Ales from Noders

What we see on our side: builders working on RWA and compliance flows on Canton keep rebuilding the same piece. In this season's HackCanton submissions, several teams wrote their own eligibility, attestation or selective-disclosure checks from scratch. A shared, open primitive for governed evidence access would save that work

What makes the proposal fundable in its current form:

PII stays off-ledger. The ledger carries purpose, expiry, status and the full lifecycle, with transaction IDs a counterparty or supervisor can verify on their own.
It composes with the draft Credentials Standard (CIP #204) instead of forking it, and the handle-to-party binding question raised above has a clear V1 answer.
About half of the ask is paid only for independent external adoption, with Veilio's own products excluded, plus a bounded maintenance tranche.
Two teams in this thread, a training and compliance platform and a consumer data-sharing app, are already mapping their use cases onto it.

gabitu7contributorcommented15-10-2026 · 1mo agoGitHub ↗

Hey, Gabi from BitSafe. Access Passport could be useful for institutional workflows such as KYC and due diligence, where organizations need to share sensitive documents with clear access rights and verifiable revocation. Keeping the data off-ledger while governing access on Canton seems relevant to these kind of use cases. We also see a potential fit with asset issuers we’re planning to work with. A reusable, open-source implementation could help other ecosystem teams build similar workflows without developing the access-governance layer from scratch.

hythlodacontributorcommented16-10-2026 · 29d agoGitHub ↗

/vote

git-vote[bot]commented16-10-2026 · 29d agoGitHub ↗

Vote created

@hythloda has called for a vote on Proposal: Veilio Governed Off-Ledger Data Exchange (RFP #12.1) (#853).

The members of the following teams have binding votes:

Team
@canton-foundation/tech-ops-voting

Non-binding votes are also appreciated as a sign of support!

How to vote

You can cast your vote by reacting to this comment. The following reactions are supported:

In favor	Against	Abstain
👍	👎	👀

Please note that voting for multiple options is not allowed and those votes won't be counted.

The vote will be open for 21days. It will pass if at least 51% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.

hythlodacontributorcommented04-11-2026 · 10d agoGitHub ↗

Moving to needs revision until CIP is approved https://github.com/canton-foundation/cips/pull/204/changes

git-vote[bot]commented06-11-2026 · 8d agoGitHub ↗

Vote closed

The vote did not pass.

In favor: 0.00% · Against: 0.00% · Passing threshold: 51%

Summary

In favor	Against	Abstain	Not voted
0	0	0	5

User	Vote	Timestamp
@Roldy69	In favor	2026-10-17 6:30:29.0 +00:00:00
@TakaYuPP	In favor	2026-10-19 10:59:01.0 +00:00:00

Field	Value
Author	Quentin CLEMENT (CEO)
Org	Veilio
Implementation partner	Avicenne Studio (Canton validator : DevNet / TestNet / MainNet)
Status	Submitted
Created	2026-08-12
Updated	2026-09-21
Proposal type	RFP-aligned (not individual initiative)
Primary RFP	#12.1 Identity, Credentials and KYC Standards for RWA Workflows
Secondary RFPs	#12.2 Institutional RWA Workflow Standards · #27 Security Monitoring, Auditability and Evidence
Roadmap area	Financial Markets, Standards & Verification
Target PR path	`rfps/financial-markets-standards-verification/`
Champion (proposed)	Charles Desmonty / Kaiko (SIG Directory)
Primary SIGs	Financial Workflows & Composability · Regulatory Compliance · Token Standards / Asset Standards
Secondary SIGs	Security · Identity & Metadata · dApp Integration
Contact	q***@veilio.xyz

Layer	Question	IAM / API + signed logs (today)
Governance	Who may access, why, until when, provable revoke?	Owner's IAM; counterparty and supervisor trust owner
Authoritative state	Is there one shared truth both parties read?	No: unilateral; reconciliation is manual or disputed
Payload	Where is the file, how is it protected?	S3, vault, API: unchanged by this proposal
Evidence	Can a third party verify independently?	Owner's signed logs only; not multiparty-verifiable

Dimension	IAM / API + signed logs	Access Passport on Canton
Scope	Inside one org's boundary	Cross-org: owner ↔ recipient (+ Observer)
Source of truth	Owner's database / IAM	Shared Daml contract both parties read
Revocation	Owner disables key/rule	Ledger archives contract; tx ID is proof
Counterparty verification	Trust owner's system	Query same on-ledger passport state
Supervisor (Observer)	Reports from owner	Reads governance + logs; no payload
Access history	Owner's SIEM export	Multiparty log + Canton tx correlation
PII on-ledger	N/A (off-system)	None by design

Metric	Target
External repos importing the DAR or integrator library	≥ 3
Documented third-party adapter implementations (excl. Veilio)	≥ 1
Reference lifecycle running on public DevNet/TestNet	Live demo + documented tx IDs
External projects qualifying for M4 adoption incentive	≥ 1
Veilio production adapter (Veilio-funded, not grant deliverable)	1

Grant-funded (open)	Explicitly out of scope (Veilio commercial)
Access Passport Daml + signed DAR (incl. Observer role)	Veilio tokenization SDK / vault product
Off-ledger gateway interface + reference file adapter	Production SaaS dashboard / billing / SSO
Integrator npm library + worked examples	Automatic PII discovery / proprietary onboarding
Multiparty compliance log schema + export	Formal third-party security audit (recommended follow-on)
Adoption guide + KYC + regulator-observer templates	MainNet production SLA / multi-region ops
DevNet/TestNet public reference deployment	Veilio Exchange marketplace product

RFP #12.1 credential	Example Owner → Recipient	On-ledger (no PII)	Off-ledger package (adapter)
KYC / KYB status	Bank A → Bank B / RWA issuer	`credentialType=KYC`, status, expiry, parties	Identity docs / verification report
Accreditation / investor qualification	Issuer / transfer agent → subscription platform	`credentialType=ACCREDITATION`, scope, expiry	Qualification certificate / letters
Licensing / regulatory status	Regulated entity → counterparty / marketplace	`credentialType=LICENSE`, regulator ref (non-PII), expiry	License evidence pack
Jurisdiction / residency	KYC provider → RWA app enforcing geo rules	`credentialType=JURISDICTION`, region code, expiry	Residency evidence (served only if needed)
Authority to act (mandate / PoA)	Institution → agent / broker / custodian	`credentialType=AUTHORITY`, role, expiry	Board resolution / PoA documents
Eligibility to hold / transact an asset	Issuer → holder / transfer agent	`credentialType=ELIGIBILITY`, assetClass, expiry	Eligibility checklist / attestations

Layer	What is shared	What is not shared
On-ledger passport	`credentialType`, purpose, parties, status, expiry, Canton tx IDs	Names, IDs, addresses, document contents
Observer	Lifecycle + multiparty access logs	Payload bytes
Recipient retrieve	Package content only if passport active and purpose allows	N/A — fail closed otherwise

Lifecycle verb (RFP)	Access Passport behaviour
Issue	Owner deposits package via adapter; proposes passport with credential metadata
Verify	Recipient accepts + consents; optional Observer witnesses
Reuse	Other Canton apps import DAR and query/exercise against same passport standard
Update	Owner publishes a new package version (adapter) and supersedes the prior passport (archive old + issue new with lineage / `supersedesPassportId`); recipients re-consent if policy requires
Revoke	Owner (or expiry) archives governing contract; gateway denies retrieve; tx ID is multiparty proof

Layer	Canton Network Credentials Standard (CIP draft #204)	Access Passport (this grant)
Job	Store, retrieve, and use credential claims on Canton (issuer / holder / registry APIs, W3C-VC inspired)	Govern who may access an off-ledger evidence package (purpose, expiry, revoke, Observer)
On-ledger	Credential claims / registry records (status attributes)	Passport lifecycle + multiparty access audit tx IDs
Off-ledger	Out of CIP scope for heavy evidence files	Payload via storage-agnostic gateway (S3, vault, API)
Roles	Issuer, holder, registry admin, app provider	Owner, Recipient, Observer, Operator
Revocation	Archive credential / holder archive	Archive passport → gateway deny + shared proof
Does not	Replace IAM for package delivery; not an evidence locker	Issue KYC decisions; not a credential registry / IdP

RFP #12.1 requirement	How Access Passport delivers it
Issue / verify credentials & packages	Owner proposes passport over typed credential evidence package
Six credential categories	`credentialType` enum + worked examples for each class (lead: KYC)
Reuse across apps without re-verification	Shared DAR; App B queries active passport / status without re-KYC
Update	Versioned package + superseding passport with lineage
Revoke	Ledger archive + gateway deny + Canton tx ID proof
Prove requirement without exposing data	Status on-ledger; payload optional; Observer never gets payload
Provider-neutral open standard	Apache-2.0 DAR + gateway interface; Veilio commercial out of scope
Identity & Metadata SIG	Metadata alignment + documented boundary in adoption guide

Artifact	Status
Daml governance frameworks (consent, permission, revocation, audit)	Shipped in PoC
Multi-node lifecycle demonstration	Shipped
Reference API + dashboard (propose / accept / consent / revoke)	Shipped
One-command local Canton deployer	Shipped
SDK/protocol assessment and scope baseline	Pre-delivery

Artifact	Why it is ecosystem-critical
Hardened Access Passport with Observer role, `credentialType` metadata, and single authoritative on-ledger state	Maps to RFP #12.1 credential categories; no conflicting bilateral truths
Automated governance + multi-node + concurrency CI suite	Objective acceptance for adopters and reviewers
Versioned signed DAR + install docs + signing-key custody procedure	Trustworthy reuse across organizations
Storage-agnostic adapter interface + reference file adapter	Any builder, any backend, no Veilio dependency
Package update / supersede path (lineage between passport versions)	RFP #12.1 "update" without silent re-issuance
Multiparty write-ahead access log tied to Canton tx IDs	RFP #27 + CNIL / AML / DORA evidence pattern
npm integrator library + examples for all six #12.1 credential types (KYC lead) + regulator-observer	Hours-to-integration; cross-app reuse without re-KYC
Public DevNet/TestNet deployment + adoption guide + Identity/Metadata SIG alignment note	Visible common good; SIG/CIP boundary documented

Role	Actor examples	On-ledger	Payload access
Owner	Bank, exporter, data vendor	Propose, issue, revoke, expire	Full control via adapter
Recipient	KYC provider, financier, fund	Accept, consent, retrieve	Yes, bounded by purpose/scope/expiry
Observer	CNIL, ACPR, auditor, DPO, counsel	Read passport state + audit trail	No (governance visibility only)
Operator	Participant ops / gateway ops	Gateway authZ, not rights source	Policy-driven; not data owner

Vertical / builder type	Owner → Recipient → Observer	What the OSS brick enables
KYC inter-bank	Bank A → Bank B / KYC → Compliance	Reuse verification without email of identity docs
Trade finance	Exporter → Financier → Credit insurer	Invoice/collateral docs, deal-scoped access
Market data (Kaiko-adjacent)	Vendor → Institution → Risk/compliance	Off-ledger dataset behind on-ledger data product
DEX / market maker	Exchange → MM → Risk	Governed sharing of sensitive flow metadata
Oracle / indexer attachment	Publisher → Consumer → Auditor	File/report delivery gated by on-ledger signal
VC data room	Startup → Fund → Counsel	Deal-bound access, provable revocation post-close
Healthcare / clinical	Sponsor → CRO → Authority	Purpose-limited trial packages
Hackathon / greenfield	Any participant → Any → Any	"Hello world" governed file share in hours

Layer	Responsibility
Client	Reference app + templates. Never treats app DB as source of truth for rights.
Off-ledger gateway	AuthZ against active passport; store/retrieve/revoke via adapter; write-ahead multiparty log.
Adapter interface	Storage-agnostic; reference file impl; production vaults plug in later.
Canton / Daml	Authoritative Access Passport state + audit trail. No personal data on-ledger.

Field (illustrative)	Purpose
`passportId`	Which right was exercised
`callerParty`	Recipient attempting access
`purpose`	Stated business purpose
`decision`	`allow` or `deny`
`cantonTxId`	Correlation to ledger event
`timestamp`	Ordering for evidence export

Bucket	CC	Share	Notes
Development (M1–M3)	1,000,000	~42%	Hardened DAR, gateway, lib, public deploy
Maintenance (M5)	200,000	~8%	12-month post-M3 support window
Adoption (M4)	up to 1,200,000	50%	External integrators only; performance-based
Total	2,400,000	100%

Milestone	Content	Calendar (indicative)	Acceptance (summary)	Funding (CC)	≈ USD
M1 — Contracts + gateway	Hardened DAR (Observer, credentialType, supersede) + CI; adapter + authZ + multiparty write-ahead log	Weeks 1–5	WS1 + WS2 acceptance met; DAR published	500,000 CC	~50,000
M2 — Integrator + public deploy	npm library + #12.1 examples; CIP #204 boundary note; DevNet/TestNet; adoption guide	Weeks 6–8	WS3 + WS4 acceptance met	450,000 CC	~45,000
M3 — UAT / stabilisation	Multi-participant validation, concurrency tests, doc fixes, forum post	Week 9	Engagement-level acceptance table green	50,000 CC	~5,000
			Development total	1,000,000 CC	100,000

Parameter	Value
Per qualifying project	100,000 CC (~USD 10,000 at illustrative rate)
Cap	12 projects → up to 1,200,000 CC
Window	18 months from M3 acceptance
Exclusions	Veilio, Avicenne, affiliates; Veilio Exchange and any Featured App owned/controlled by grantee

Parameter	Value
Funding	200,000 CC
Window	12 months from M3 acceptance
Scope	Bugfixes for published DAR/lib/gateway interface; Canton/SDK version drift patches; security patches for grant artefacts; community support on GitHub/forum; metadata remapping if CIP Credentials Standard (#204) stabilizes

Requirement	Evidence
Lifecycle correctness	CI suite green every release; one audit record per action
Revocation / expiry	No new retrievals after revoke/expire (incl. concurrent volume)
Authorisation	No retrieval without active passport held by calling party
Observer / compliance	Observer reproduces audit trail without payload access
Storage neutrality	Adapter swap requires no contract change
Adoptability	External builder integrates from published artefacts alone
Public deployment	Lifecycle across ≥2 participants on DevNet/TestNet, docs-reproducible

Party	Role
Veilio	Proposer, product owner, first production adapter commitment, ecosystem GTM
Avicenne Studio	Delivery: Daml/Canton engineering, gateway, library, DevOps, docs; validator sponsorship

Risk	Mitigation
PoC differs from hardening estimate	Pre-delivery baseline complete; scope changes re-baselined in writing
Perceived as "IAM on Canton"	Lead with thesis: replaces unilateral truth, not IAM; signed logs ≠ shared state; chain abstraction diagram in §1
Adapter interface too narrow	Validate against ≥1 non-Veilio storage pattern before publish
SDK/protocol drift	Versions pinned in baseline; upgrade path in DAR manifest
No formal audit in scope	Governance + multi-node CI; audit optional before MainNet
Node access delays	Avicenne provides validator access / sponsorship directly
Low external adoption	M4 = 50% of ask, gated on independent builders; workshops + CIP #204 composition guide + forum

Development Fund Proposal Submission

Applicant

Proposal Classification

Funding & Timeline

Summary

Submission Checklist

Discussion13 comments, 0 reviews, 0 inline comments

Vote created

How to vote

Vote closed

Summary

Proposal file rfps/financial-markets-standards-verification/2026-09-Veilio-governed-offledger-data-exchange.md, 62 KB

Governed Off-Ledger Data Exchange: Open Reference Stack for Canton

Abstract

1. Objective and scope

Problem

Why Canton, not API + IAM + signed audit logs

What IAM already does well

What IAM cannot provide (even with signed logs)

What Canton adds: shared governance, not a new IAM

Chain abstraction: Canton governs rights, Web2 stores data

When the committee should fund this (and when not)

Intended outcome

Success looks like (12 months post M3)

2. Public-good framing

3. RFP and strategic roadmap alignment

Primary : RFP #12.1 Identity, Credentials and KYC Standards for RWA Workflows

Credential types covered by RFP #12.1 → passport purpose / metadata

Cross-application recognition (no repeated verification)

Prove a requirement without disclosing underlying data

Issue → verify → reuse → update → revoke

Identity and Metadata SIG / CIP coordination, including draft Credentials Standard

Requirement mapping

Secondary — RFP #12.2 Daml and Institutional RWA Workflow Standards

Secondary — RFP #27 Security Monitoring, Auditability and Evidence

Vision fit (Capital Markets on Canton)

SIGs

Relationship to Kaiko's Data Standard

4. What already exists vs. what is net-new

Already exists (Veilio Exchange PoC, not grant-funded)

Net-new (grant-funded)

5. Product definition, roles, and technical approach

5.1 Product definition

5.2 Functional roles

5.3 Worked example: CNIL-style tripartite supervision

5.4 Ecosystem use cases beyond Veilio Exchange

5.5 Layers

5.6 Access Passport lifecycle

5.7 Multiparty compliance logs

5.8 Off-ledger revocation semantics

5.9 Contention under bulk operations

5.10 Constraints

6. Workstreams and acceptance

WS1 : Daml contract hardening and publication

WS2 : Off-ledger governance gateway

WS3 : Integrator library

WS4 : Public deployment and adoption

7. Out of scope

8. Architectural alignment with Canton

9. Milestones, deliverables, funding

Development (M1–M3)

M4 — Ecosystem adoption incentive (~50% of ask, performance-based)

M5 — Maintenance (12 months post M3)

Engagement-level acceptance (objective)

10. Team and delivery

11. GTM and adoption strategy

12. Risks and mitigations

13. Security notes

14. Co-marketing

15. One-liner

Appendix A — Related materials

Journey on the board 5 moves, stepped back or reopened 1

Timeline 21 events

Credential types covered by RFP #12.1 → passport `purpose` / metadata