Identity infrastructure for AI agents on Canton Network

Know
Your Agent

Banks are deploying AI agents to move money, settle trades, and manage collateral on Canton. KYA is the identity layer: verify who sent an agent, what it can do, whether it's performed reliably, and whether compliance checks pass — all before a transaction goes through.

Status Draft Proposal
Type Open Standard + Application
Network Canton
New infra needed None
Request a Demo See the product
Scroll to explore

AI agents are doing deals.
Nobody checks their ID.

Right now, an AI agent on Canton can connect to your application and request a transfer, a settlement, or a collateral move. There's no standard way to answer six basic questions before that transaction goes through:

01Which company sent this agent?
02Is that company verified?
03What is this agent allowed to do?
04Has this agent performed reliably?
05Does this transaction pass compliance checks?
06Can the company revoke it instantly?

Think of it as a
digital employee badge

01

A bank is already verified on Canton

An identity issuer has confirmed their legal entity. This is existing infrastructure — it's how Canton works today.

02

The bank issues a badge to its AI agent

The badge says: this agent works for us, it can do transfers and settlements, its limit is $10M per transaction. Both the bank and the agent sign.

03

The agent shows its badge when transacting

When the agent wants to settle a trade with another company, it presents its badge along with the request. The badge travels securely using Canton's built-in disclosure system.

04

The other company verifies automatically

Their app checks the badge, runs compliance hooks, reviews performance history. Valid signature, authorized capabilities, within limits, not expired, not revoked. Done.

Real scenarios.
Real institutions.

Canton processes $280B in daily repos

Collateral Management Agent

A margin call hits at 3am Tokyo time. An AI agent automatically moves collateral between counterparties. The receiving side needs to verify the agent's authority, check its track record from prior settlements, and confirm exposure limits aren't breached.

KYA verifies the credential, shares performance attestations from other counterparties via Explicit Disclosure, and runs an exposure limit hook — all before the collateral moves.

DTCC tokenizing US Treasuries on Canton — H1 2026

Treasury Settlement Agent

A dealer's agent settles a tokenized Treasury trade. Both sides need to know: is this agent authorized by the dealer, can it settle UST-10Y specifically, and is this $50M trade within limits?

KYA checks the delegation chain, instrument restrictions, per-transaction value cap, and sanctions screening — then issues a cryptographic proof the settlement workflow consumes.

USD1 stablecoin deploying on Canton

Stablecoin Operations Agent

A fund runs an agent that manages stablecoin liquidity — processing redemptions, funding settlement accounts, moving USD1 between apps. The stablecoin issuer needs to verify the agent before processing.

KYA confirms which fund authorized this agent, that it can do transfers (but not mints or burns), its daily volume cap, and discloses the agent's published profile showing its capabilities.

Canton's core differentiator: atomic cross-app settlement

Cross-App Atomic Agent

One transaction settles a bond trade across three apps: tokenized bond, stablecoin payment, and collateral adjustment. The agent needs valid credentials verified by all three apps atomically.

One KYA badge, verified by multiple counterparties in the same transaction tree. One verification proof consumed by all parties. No other network has this problem.

Two layers. Seven deliverables.
Nothing new to install.

Layer 1 is free and open source — it drives adoption and becomes a Canton standard via CIP governance vote. Layer 2 is the active Canton application that earns Featured App rewards shared with integrating apps.

Layer 1

Open Standard

Free forever. Drives adoption.

01

Badge Format

Defined naming conventions for agent credentials: who authorized it, what it can do, spending limits, code fingerprint. Uses Canton's existing Credential Utility.

Open standard

02

Verifier Library

Open-source Daml code any Canton app can import. Two functions: check a badge, trace the delegation chain from agent to company to identity verifier.

Open source

03

CIP Proposal

Formal standards proposal to Canton governance. If adopted by Super Validator vote, every participant speaks the same agent-identity language.

CIP proposal

Layer 2

Application

Active service. Earns rewards.

04

Verification Service

Active Canton application that handles verification and creates on-ledger proof contracts. Integrating apps earn Featured App rewards shared with KYA.

Application

05

Agent Profiles

Institutions publish agent capabilities privately and selectively disclose them to authorized counterparties. Permissioned discovery — not a public registry.

Application

06

Performance Attestations

Bilateral, private records of agent transaction outcomes. Shared with new counterparties via Canton's Explicit Disclosure — cryptographically unforgeable.

Application

07

Validation Hooks

Pluggable compliance checks that run before a verification proof is issued. Sanctions screening, exposure limits, jurisdiction rules. Institution-specific.

Application

See it in action

KYA ships two dashboards: the Console for institutions managing their agent fleet, and the Operator Dashboard for network administrators overseeing the verification infrastructure. Both are production-ready, role-authenticated, and designed for institutional workflows.

Agent Console — Institution View
KYA Agent Fleet showing registered agents with capabilities Console

Agent Registry

Register and manage your agent fleet

Every AI agent operating on Canton gets a registered identity. The Agent Fleet view shows each agent's principal organization, class (autonomous, operator, or observer), and declared capabilities.

Institutions register agents here before deploying them. The capability badges act as the machine-readable permissions that counterparties verify during transactions.

KYA Verify Agent form for checking capabilities and authorization Console

Verification

Verify an agent before transacting

Before accepting a trade, settlement, or collateral move from an agent, counterparties can verify its authorization. Specify the agent party, required capability, transaction value, and instrument.

KYA checks the delegation chain, validates limits, runs compliance hooks, and returns a cryptographic proof contract that the settlement workflow consumes.

KYA Verification Proofs table showing active and consumed proofs Console

Proof Ledger

Cryptographic proofs for every verification

Each successful verification creates an on-ledger proof contract with an expiration window. Proofs start as Active and transition to Consumed when used in a settlement, creating a tamper-proof audit trail.

Proofs link agent party, principal, class, and capability — providing a complete chain of accountability from the institution that deployed the agent to the specific transaction it executed.
KYA Agent Profiles with selective disclosure controls Console

Agent Discovery

Publish profiles, control who sees them

Agent Profiles are a permissioned directory. Institutions publish versioned profiles describing what their agents do, then selectively disclose them to specific counterparties — regulators, auditors, or trading partners.

Unlike a public registry, nothing is visible until explicitly shared. Canton's Explicit Disclosure ensures profiles are cryptographically verified and unforgeable.

Operator Dashboard — Network Administration
KYA System Overview dashboard with real-time metrics Operator

System Overview

Real-time metrics across the KYA network

The Operator Dashboard provides a live view of the verification infrastructure: total registered agents, active and consumed proofs, settlement hook activity, and credential revocation status.

System Health monitoring tracks API status, the revocation registry, and ledger connectivity — giving operators confidence the verification layer is functioning correctly.

KYA Integrations showing settlement hooks and activity markers Operator

Integrations

Settlement hooks and reward sharing

Settlement Hooks connect KYA providers with integrating applications, defining how Canton Featured App rewards are split. Each hook visualizes the provider-to-app route and the reward percentage split.

Activity Markers create an immutable log of every settlement that consumed a verification proof, tracking beneficiaries and their reward weights for transparent compensation.

KYA Validation Hooks for OFAC sanctions and exposure limits Operator

Compliance

Pluggable compliance checks at verification time

Validation Hooks run before any verification proof is issued. Configure sanctions screening against OFAC, EU, and PEP watchlists. Set counterparty exposure limits with aggregate thresholds and lookback windows.

Hooks are institution-specific and fully configurable. Each hook has a type (sanctions or exposure), a JSON configuration block, and runs in the verification pipeline before a proof is created. Blocked verifications never produce a proof.

Open standard.
Optional service.

A

Do it yourself

Import the library

Import the open-source verifier module into your Daml code. Call the functions directly. Handle credential bundles yourself. Free forever. KYA earns nothing.

This drives adoption of the standard, strengthens the CIP, and ensures no one is locked in.

your_app calls verifyAgentCredential()
your_app calls verifyDelegationChain()
your_app handles everything → zero cost
B

Route through KYA

Use the service

Route verification through the KYA application. Get an on-ledger proof contract your settlement can consume. Both you and KYA earn Canton Featured Application rewards.

You also get agent profiles, performance attestation sharing, and pluggable compliance hooks — without building any of it.

kya verifies + runs hooks → creates proof
your_app consumes proof in settlement
rewards split → you get the majority share

What a badge
actually looks like

Simple key—value pairs in Canton's existing credential system

A KYA credential is just a list of claims stored using Canton's Credential Utility. Each claim has a subject (the agent), a property (what's being stated), and a value.

No new smart contracts. No new tokens. No new protocol features. Just agreed-upon naming conventions on top of what already exists.

Example — Agent Badge
-- Who issued this badge and who holds it
issuer  = org::abc123
holder  = agent::def456

-- "I work for this company"
kya:principal    = "org::abc123"

-- "I'm an operator-class agent"
kya:agentClass   = "operator"

-- "I can do these three things"
kya:capabilities = "transfer,settle,collateral"

-- "Up to $10M per transaction"
kya:maxTransactionValue = "10000000"

-- "Only these instruments"
kya:allowedInstruments  = "UST-10Y,UST-2Y,USDC"

-- "Here's my code fingerprint"
kya:codeHash    = "sha256:a1b2c3d4..."
      

Ethereum built this
for public chains

ERC-8004 launched on Ethereum mainnet in January 2026, co-authored by engineers from MetaMask, Coinbase, Google, and the Ethereum Foundation. It defines agent identity, reputation, and validation registries for permissionless networks. The thesis is validated — the industry agrees agent identity standards matter. Canton needs the equivalent for institutional finance.

ERC-8004 (Ethereum) KYA (Canton)
Trust modelTrustless — build trust from zeroInstitutional — extend existing trust
IdentityPublic NFT registry, anyone can browsePrivate credentials, selective disclosure
ReputationPublic feedback signals, on-chain scoringPrivate bilateral attestations, unforgeable
ValidationPost-hoc — did the agent do the job?Pre-transaction — can the agent do the job?
DiscoveryPublic browse (8004scan.io)Permissioned directory by counterparty
AccessPermissionless — any wallet can registerVerified institutions only
PrivacyTransparent by defaultPrivate by default
Sybil defenseReputation scoring, stakingKYC'd institutions, delegation chains

Same problem, different trust models

ERC-8004 answers "should I trust this unknown agent?" with public reputation. KYA answers "is this known institution's agent authorized for this action?" with private credentials. Both are necessary. Neither replaces the other.

What KYA adapts from ERC-8004

Agent profiles with service endpoints. Structured performance data. Pluggable validation hooks. Each adapted for Canton's privacy-first architecture where nothing is public by default.

The network is real.
The moment is now.

Canton Network today

600+

Financial institutions

$6T

In tokenized assets

30+

Governance validators

Participants include Goldman Sachs, Deutsche Börse, BNP Paribas, Broadridge, Cboe, Paxos, and Moody's. DTCC is partnering to tokenize US Treasury securities.

Agent IDs are already happening

Mastercard launched Agent Pay in October 2025, requiring AI agents to carry verified credentials before making purchases.

Visa launched its Trusted Agent Protocol the same day, with Microsoft, Shopify, and Stripe as partners. ERC-8004 went live on Ethereum mainnet in January 2026 with 10,000+ agents registered.

The pattern is proven for consumer payments and public blockchains. Nobody has built the equivalent for institutional finance. That's the gap.

Built on what already works

Credentials

Credential Utility

Canton's existing credential issuance and verification. KYA badges are a new type of credential in this system.

Enforcement

Registry Utility

Lets asset issuers require credentials before transfers. KYA badges plug into these existing rules.

Sharing

Explicit Disclosure

Canton's built-in secure data sharing. How badges and performance attestations travel between parties — cryptographically verified.

Identity

Identity Issuers

Issuer-agnostic. Any trusted identity provider can anchor a delegation chain. The verifier decides who to trust.

Rewards

Featured App API

Canton's application reward system. The KYA service layer uses this to share rewards with integrating apps.

A living network.
Visible activity.

KYA is a stakeholder on every verification proof, attestation, and profile contract. That means it sees all network activity — without seeing who's behind it. An automated pulse feed publishes anonymized stats in real time.

What the network sees

A service reads from the Canton Ledger API where KYA is an observer or signatory. It counts contracts by type, aggregates outcomes, and posts anonymized summaries. No institution names. No agent names. No transaction values. Just proof the network is alive and growing.

This is how public chains show ecosystem health. Canton can't do it the same way because everything is private. KYA is uniquely positioned to bridge that gap — it's the one party that sees verification activity across all participants.

Canton Ledger API
  KyaVerificationProof → count, success rate
  KyaPerformanceAttestation → count, outcomes
  KyaAgentProfile → count, agent classes
  KyaValidationHookResult → count, pass/block

Aggregation service → anonymized stats → public feed

KYA Network

@kya_canton

2m ago

12 agent verifications completed today on Canton. 100% success rate. 0 expired proofs.

Source: KyaVerificationProof contracts

KYA Network

@kya_canton

1h ago

New agent profiled: autonomous-class, settlement + collateral capabilities. That’s 23 total agents on the network.

Source: KyaAgentProfile contracts

KYA Network

@kya_canton

3h ago

Weekly compliance: 41 validation hooks executed. 39 passed, 2 blocked. Most common hook: sanctions screening.

Source: KyaValidationHookResult contracts

KYA Network

@kya_canton

6h ago

Milestone: 500th performance attestation recorded. 6 institutions contributing bilateral attestations across 23 agents.

Source: KyaPerformanceAttestation contracts

This standard is
wide open

Ethereum's biggest names validated the thesis with ERC-8004. Canton needs the institutional equivalent. All the building blocks exist. KYA is the missing piece. We're building it in the open.

Request a Demo Read the spec View on GitHub