Skip to main content
The ComplianceRegistry stores compliance attestations on-chain. The SettlementCoordinator checks this registry as a gate before allowing transitions past the compliance phase.

​
How it works

  1. Off-chain compliance oracle screens parties via LSEG World-Check (entity) and CipherOwl (wallet)
  2. Oracle submits attestation on-chain: attest(settlementId, partyHash, status, refHash)
  3. When the engine proposes a transition past compliance, the SettlementCoordinator calls areAllPartiesCleared(settlementId)
  4. If all parties have passing attestations, the transition is allowed

​
Functions

​
attest()

Submit a compliance attestation for a party in a settlement. 
function attest(
    bytes32 settlementId,
    bytes32 partyHash,
    ComplianceStatus status,
    bytes32 referenceHash
) external
ParameterDescription
settlementIdUUID converted to bytes32
partyHashkeccak256(abi.encode(participantId_bytes32, walletAddress))
statusPass (1), Flagged (2), or Fail (3)
referenceHashKeccak256 of the compliance provider’s reference ID
No personal data is stored on-chain. The partyHash is a one-way hash that cannot be reversed to identify the party. The referenceHash is a hash of the provider’s reference ID, not the ID itself.

​
isCleared()

Check if a specific party has a passing attestation. 
function isCleared(
    bytes32 settlementId,
    bytes32 partyHash
) external view returns (bool)

​
areAllPartiesCleared()

Check if all registered parties for a settlement have passing attestations. This is the function the SettlementCoordinator calls as a gate check. 
function areAllPartiesCleared(
    bytes32 settlementId
) external view returns (bool)

​
Party hash computation

Party hashes are computed as keccak256(abi.encode(participantId_bytes32, walletAddress)):
Check typeparticipantIdwalletAddress
Entity screeningParticipant UUID as bytes32Zero address (0x0000...0000)
Wallet screeningParticipant UUID as bytes32Actual wallet address
This allows separate attestations for entity-level and wallet-level screening while maintaining a consistent hashing scheme.

​
Status mapping

API StatusContract Enumuint8 Value
PASSComplianceStatus.Pass1
FLAGGEDComplianceStatus.Flagged2
FAILComplianceStatus.Fail3
Only Pass (1) counts as cleared for the gate check. Flagged and Fail both prevent the transition.

​
Open attestation interface

KeyStone operates the default compliance oracle, but the attestation interface is open:
  • Platform-operated oracles: Platforms can run their own compliance screening and submit attestations directly
  • Multi-attester: Templates can require attestations from multiple providers for higher assurance
  • Verifiable: All attestations are permanent on-chain records - a false attestation is provable liability
This design separates the screening (off-chain, provider-specific) from the enforcement (on-chain, standardized gate check).

​
What KeyStone stores

KeyStone never stores raw KYC/AML data. The compliance flow stores:
LayerWhat is stored
Off-chain (KeyStone DB)Compliance status (pass/fail/flagged) + reference ID pointing to provider’s record
On-chain (ComplianceRegistry)Hashed party identifier + status enum + hashed reference ID
The compliance provider (LSEG, CipherOwl) remains the source of truth for the actual screening data. KeyStone only records the outcome.