cardano-keri · identity core
Keep the identity
you already trust.
The first cardano-keri milestone delivers the identity core: an existing KERI identity gains a stable home on Cardano, so a team can manage records, update keys, and recover control without handing authority to a middleman.
wire contract ready and byte-tested
first milestone adds validator + safeguards
cardano-keri · standard KERI identities, usable on Cardano
one team · one identity · one journey
Composite pilot · Northstar
Meet Northstar: a team with an identity already in use.
Northstar wants its existing KERI identity to control Cardano records, so partners can recognize the same organization on both systems.
What they already use
A standard KERI identity
AID: E… · Blake3 · Veridian-compatible
Any two of three officers approve an action. Future keys stay separate, and KERI witnesses receipt accepted events.
What they want on Cardano
One record that follows the organization
Partners should always find Northstar’s current authorized keys through one stable identity reference.
identity → authority → data
What they should not have to do
Start over or trust a middleman
No replacement identity, no permanently fixed hot key, and no bridge custodian in the everyday authorization path.
needregisteruserotaterecovertrust
Northstar · day 0
Bring your existing identity—no conversion required.
Northstar registers the same E-prefix KERI identifier its partners already know. There is no Cardano-only version of the identity and no wallet-vendor lock-in.
1 · use what you have
Existing KERI identity
AID = E… · keys · approval rule · witnesses
→
2 · verify the link
Cardano checks the identity proof
blake3(icp bytes) == AID · ≤1024 B
→
3 · create the Cardano handle
Stable identity checkpoint
quantity 1 · asset name ← AID
WHAT IS VERIFIED Cardano proves that the inception-event bytes produce this AID, and the signed registration proves control of the event's keys. Translating KERI fields into the checkpoint is separately attested and can be challenged.
same identityNo re-issuance and no Cardano-specific AID.
stable handleOne quantity-one token is derived from the AID.
on-chain proofEvents up to 1024 bytes are bound to the AID in script.
needregisteruserotaterecovertrust
Northstar · the integration handle
Give apps one stable name for your organization.
A Cardano app can connect to Northstar once. The identity reference stays the same while the authorized keys and approval rules change over time.
Never changes
Stable identity token
policy_id
+
aid_asset_name
quantity = 1 · stays the same across rotations
What the checkpoint keeps current
current keys
The Ed25519 keys allowed to act today, with their approval rule.
k / kt
next keys
The public commitment that makes the next safe rotation possible.
n / nt
witnesses
The witnesses and receipt threshold that confirm the public history.
b / bt
position
Where this checkpoint sits in both Cardano and the KERI event log.
seq / s
one lookupApps resolve the checkpoint by policy and asset.
one formatThe versioned datum is frozen and byte-tested.
continuousThe handle is identical before and after rotation.
needregisteruserotaterecovertrust
Northstar · governance
Keep the approval rules your team already uses.
Northstar does not need to simplify its governance for Cardano. The checkpoint carries the same signing rule the team uses in its KERI identity.
Northstar’s everyday rule
Any two must signkt = 2
Weighted approvals
Give people halves, thirds, or other fractional voting weights.
More than one group
Require separate clauses and keep zero-weight reserve positions.
Solo builders included
1-of-1 uses the same checkpoint format.
KERI-faithfulThe rules match the reference implementation.
production-testedObserved GLEIF and QVI configurations round-trip.
efficientEveryday authorization uses raw keys and no hashing.
needregisteruserotaterecovertrust
Northstar · first useful action
Your Cardano records stay under the right control—even after keys change.
Northstar owns an on-chain record through its identity checkpoint. The record follows the organization’s current authority instead of being tied to one permanent key.
The Cardano record
Northstar’s pilot data
owner: checkpoint asset
value: pilot payload
version: 01
←
Every update checks
2/3of the keys that are authorized right now
reference input → raw keys → Ed25519 verify
←
Northstar approves
With its current team keys
keys rotate
asset id does not
After a rotation, the record and owner stay the same; only the authorized keys change.no key migration
current authorityEvery write checks the live checkpoint.
stable ownershipThe record does not move when keys rotate.
end to endThe runnable demo writes a real Cardano record through the identity.
needregisteruserotaterecovertrust
Northstar · month 3
Update keys directly—with public KERI confirmation.
Northstar chooses its successor keys without an identity oracle. Cardano activates them only after the team’s KERI witness threshold has receipted the update.
Three checks protect every key update
prepared keys
The revealed keys match the earlier commitment and both signing thresholds.
+
public KERI event
Northstar’s configured witness threshold receipts the anchor in its event log.
+
same resulting state
The signed update exactly matches the checkpoint Cardano creates.
No receipts, no seq + 1 checkpoint.fail closed
Production reserve example
Use 3 of 7 prepared keys
GLEIF Root uses this pattern: reveal only the keys needed now and keep the remaining reserve keys private.
no identity oracleThe controller chooses the keys; witnesses confirm the KERI event.
flexible reservesA rotation can reveal only part of the prepared set.
measured costEach revealed key uses one small Blake3 block.
needregisteruserotaterecovertrust
Northstar · incident day
Losing today’s keys does not mean losing the identity.
Even if every key valid today is stolen, the intruder cannot choose tomorrow’s keys. Northstar can use the successor keys it prepared earlier to recover control.
What the intruder has
Every key that is valid today
today’s signing rule is satisfied
×Cannot choose tomorrow’s keys
n
promise about
the next keys
What Northstar kept safe
The keys prepared for the next rotation
blake3(qb64(key)) ∈ prior n
✓Recovers the same identity
tested failureA full stolen current quorum still cannot rotate.
witnessed continuityThe receipted successor event removes the compromised set without changing the AID.
scope boundaryIf both current and successor keys are lost, this layer cannot recover the identity.
needregisteruserotaterecovertrust
Counterparty dApp · one reference input
Apps always read the keys that are valid now.
A Cardano app uses one read-only reference to Northstar’s checkpoint. The ledger verifies the identity record again before it accepts an action.
1 · find the identity
Look up the stable token
(policy_id, aid_asset_name)
An indexer suggests where the checkpoint lives; it does not decide who is authorized.
→
2 · read the checkpoint
Use a CIP-31 reference input
read-only · current datum
The transaction reads the current keys without consuming or moving the identity.
→
3 · verify on-chain
The ledger makes the final check
asset · quantity · datum · lineage
A stale or false lookup can delay a transaction, but it cannot invent authority.
Safe by default: if the identity is paused, applications reject actions automatically until the checkpoint catches up.fail closed
simple integrationThe app performs one lookup and one reference read.
limited trustAn indexer can delay service, but it cannot forge authority.
rotation-safeThe same asset resolves the new keys after an update.
needregisteruserotaterecovertrust
Counterparty · public safeguards
Public checks keep Cardano and KERI in sync.
Northstar cannot activate private Cardano-only keys and explain them later. Public KERI receipts are checked before new authority exists, while later evidence can pause a checkpoint, or burn a proven fork.
Cardano tries to move first
Controller signatures arrive without witness receipts
Reject the update
No checkpoint means the proposed keys can authorize no later Cardano action. Time never bypasses the check.
KERI has moved first
A witnessed KERI rotation is newer
Pause the checkpoint
The identity can only move forward until Cardano catches up. Applications reject authority in the meantime.
Two publicly accepted rotations
Both controller and witness thresholds prove an irreconcilable conflict
Convict the fork
The same token is burned and the conviction prover receives the deposit. Recoverable evidence only pauses.
Two gates, two jobs: controller signatures authorize; witness receipts prove public KERI acceptance. Conviction requires both.part of the identity-core validator
needregisteruserotaterecovertrust
Around Northstar · useful public services
The same public evidence supports useful services.
Because the KERI history and Cardano checkpoint are public, independent operators can keep them aligned, audit them, and publish credential status.
Watcher
Keep both histories aligned.
Compare the public KERI event log (KEL) with Cardano. Relay accepted updates, pause lagging checkpoints, and submit fully receipted conviction evidence.
open to anyone
permissionless pause
conviction alone pays
Auditor
Build reports from replayable facts.
Reconstruct the full KERI history, compare it byte-for-byte with Cardano, and cite the evidence.
full history replay
byte-for-byte evidence
retirement visible in history
Issuer
Publish credential status on-chain.
Mirror each issuer’s revocation registry so consumers can check status without calling the issuer’s API.
production credential IDs
ledger-ordered updates
issuer API not required
CLEAR SCOPE The identity core publishes credential status. Verifying the full GLEIF → QVI → legal-entity credential chain comes in the next verification milestone.
needregisteruserotaterecovertrust
Acceptance · runnable devnet
The end-to-end demo shows the complete journey.
A runnable local-devnet demo proves that registration, record ownership, key updates, and recovery work together—not only as separate unit tests.
01
Register
Bring a KERI identity controlled by any two of three officers.
→
02
Create a record
Write one Cardano data leaf owned by that identity.
→
03
Update keys
Collect witness receipts, then activate the prepared successor keys.
→
04
Reject both attacks
No receipts and stolen current keys both fail on-chain.
Haskell wire + semantics195 tests
Aiken on-chain contract157 checks
one continuous proof · register → create a record → receipted update → reject Cardano-first and stolen-key attempts
Honest boundary · pilot invitation
What this foundation proves—and what comes next.
Delivered by the identity core
- ✓Use an existing E-native KERI identity without re-issuing it.
- ✓Keep one stable Cardano handle while keys and approval rules change.
- ✓Own records, replay evidence, manage lifecycle, and publish credential status.
- ✓Pause or retire a checkpoint when public evidence proves divergence.
Built on top in later milestones
- →Verify the complete GLEIF → QVI → legal-entity credential chain.
- →Authorize arbitrary dApp actions through reusable signed envelopes.
- →Connect Veridian and Signify signing directly to Cardano workflows.
- →Add delegated identities and a superseding recovery path.
A useful first pilot needs
an existing KERI identity · one Cardano record it should control · a clear freshness policy