On-Chain Identity (commonly implemented as ONCHAINID) is a decentralized identity system based on ERC-734 (Key Holder) and ERC-735 (Claim Holder) that represents a user's identity as a smart contract separate from their wallet address. This architecture enables: key rotation without losing verified status, portable credentials across multiple security tokens, and privacy-preserving verification where only cryptographic proofs (claims) are stored on-chain while actual personal data remains off-chain.

The article explains the problem this solves: "Standard whitelists are fragile; if a user loses their private key, they lose their identity." With traditional whitelists, identity is tied directly to a wallet address. Lose your private key, get hacked, or want to use a new wallet—you must re-do the entire KYC/verification process. On-chain identity contracts decouple identity from any single wallet, making verified status recoverable and portable.

Architecture

An on-chain identity consists of:

Identity Contract: A smart contract deployed for each user, storing their keys and claims:

1contract Identity is IERC734, IERC735 {
2    // Keys that can control this identity
3    mapping(bytes32 => Key) public keys;
4    // Claims about this identity
5    mapping(bytes32 => Claim) public claims;
6    
7    struct Key {
8        uint256 purpose; // 1=MANAGEMENT, 2=ACTION, 3=CLAIM, 4=ENCRYPTION
9        uint256 keyType; // 1=ECDSA, 2=RSA
10        bytes32 key;     // keccak256 of key data
11    }
12    
13    struct Claim {
14        uint256 topic;      // What the claim asserts
15        uint256 scheme;     // Verification scheme
16        address issuer;     // Who made the claim
17        bytes signature;    // Cryptographic proof
18        bytes data;         // Claim data (usually hash of off-chain data)
19        string uri;         // Where to find full claim data
20    }
21}

Key Types (ERC-734):

• Management Keys (1): Can add/remove keys and execute administrative functions
• Action Keys (2): Can execute transactions on behalf of the identity
• Claim Keys (3): Can add/modify claims
• Encryption Keys (4): For encrypted communication

Wallet Linking: Multiple wallet addresses can be linked to a single identity contract as Action Keys:

1function addKey(bytes32 key, uint256 purpose, uint256 keyType) public onlyManagement {
2    keys[key] = Key(purpose, keyType, key);
3    emit KeyAdded(key, purpose, keyType);
4}
5
6// Link new wallet as Action Key
7function linkWallet(address wallet) public onlyManagement {
8    bytes32 keyHash = keccak256(abi.encodePacked(wallet));
9    addKey(keyHash, ACTION_KEY, ECDSA_TYPE);
10}

Claim-Based Verification

Claims are the core of on-chain identity verification. Rather than storing personal data on-chain (privacy violation, GDPR issues), trusted third parties sign cryptographic attestations:

How Claims Work:

1. Off-Chain Verification: User submits documents to a KYC provider (Jumio, Onfido, etc.)
2. Claim Issuance: KYC provider signs a claim: "This identity has passed KYC verification"
3. On-Chain Storage: The signed claim is added to the user's identity contract
4. Verification: Anyone can verify the claim signature without accessing raw data

1function addClaim(
2    uint256 topic,
3    uint256 scheme,
4    address issuer,
5    bytes memory signature,
6    bytes memory data,
7    string memory uri
8) public returns (bytes32 claimId) {
9    // Only claim keys or self can add claims
10    require(keyHasPurpose(keccak256(abi.encodePacked(msg.sender)), CLAIM_KEY), "Not authorized");
11    
12    claimId = keccak256(abi.encodePacked(issuer, topic));
13    claims[claimId] = Claim(topic, scheme, issuer, signature, data, uri);
14    
15    emit ClaimAdded(claimId, topic, scheme, issuer, signature, data, uri);
16}

Common Claim Topics:

• KYC Verified (1): User has passed Know Your Customer verification
• Accredited Investor (2): User meets accreditation requirements
• Country of Residence (3): User's verified residence country
• AML Cleared (4): User has passed Anti-Money Laundering screening
• Professional Investor (5): User qualifies as professional (MiFID II)

Key Rotation and Recovery

The article highlights: "Allow Key Rotation: If a user's wallet is compromised, they can revoke the wallet key via the Identity Contract without losing their accumulated credentials/claims."

Revoking Compromised Key:

1function removeKey(bytes32 key) public onlyManagement {
2    require(keys[key].key != 0, "Key not found");
3    delete keys[key];
4    emit KeyRemoved(key, keys[key].purpose, keys[key].keyType);
5}
6
7// User's management key (stored safely, e.g., hardware wallet) revokes compromised key
8function revokeCompromisedWallet(address compromised) external {
9    bytes32 keyHash = keccak256(abi.encodePacked(msg.sender));
10    require(keyHasPurpose(keyHash, MANAGEMENT_KEY), "Not management key");
11    
12    bytes32 compromisedHash = keccak256(abi.encodePacked(compromised));
13    removeKey(compromisedHash);
14}

Adding New Wallet:

1function addNewWallet(address newWallet) external onlyManagement {
2    bytes32 keyHash = keccak256(abi.encodePacked(newWallet));
3    addKey(keyHash, ACTION_KEY, ECDSA_TYPE);
4    
5    // Update Identity Registry to point to new wallet
6    identityRegistry.updateIdentity(oldWallet, newWallet);
7}

The user's claims (KYC, accreditation) remain intact—they don't need to re-verify because their identity contract still holds valid claims.

Integration with Identity Registry

The Identity Registry connects wallets to their identity contracts:

1// In Identity Registry
2function isVerified(address wallet) public view returns (bool) {
3    address identityContract = identity[wallet];
4    if (identityContract == address(0)) return false;
5    
6    // Check identity has required claims
7    return IIdentity(identityContract).hasValidClaim(KYC_TOPIC);
8}
9
10// Checking claim validity
11function hasValidClaim(uint256 topic) external view returns (bool) {
12    bytes32 claimId = keccak256(abi.encodePacked(trustedIssuer, topic));
13    Claim memory claim = claims[claimId];
14    
15    // Verify claim exists and signature is valid
16    if (claim.issuer == address(0)) return false;
17    
18    bytes32 dataHash = keccak256(abi.encodePacked(address(this), topic, claim.data));
19    return verifySignature(claim.issuer, dataHash, claim.signature);
20}

Privacy Considerations

On-chain identity preserves privacy while enabling compliance:

What's On-Chain:

• Identity contract address
• Cryptographic claim signatures
• Claim topics and issuers
• Hash of verification data

What's Off-Chain:

• Actual personal documents
• Name, address, SSN
• Passport scans
• Full KYC records

The article states: "Store Claims On-Chain, Data Off-Chain: Do not store PII (names, passports) on the blockchain. Instead, a trusted 3rd party signs a hash (a Claim) validating the user."

Security Considerations

Management Key Security: The management key is critical—it controls the entire identity. If compromised, attackers can: add their own wallets, remove legitimate keys, and take over the identity. Mitigation: store management keys in hardware wallets, use multi-sig for management operations.

Claim Issuer Trust: The system's security depends on trusted claim issuers. If an issuer is compromised: fake claims can be added to any identity, verification becomes meaningless. Mitigation: multiple required issuers, issuer reputation systems, claim expiration.

Claim Revocation: Issuers must be able to revoke claims if user status changes (lost accreditation, moved to sanctioned country). Without revocation: outdated claims remain valid, compliance is compromised. Mitigation: on-chain revocation registries, claim expiration timestamps.

Identity Squatting: Malicious actors could deploy identity contracts for addresses they don't control. Mitigation: require proof of address ownership during identity deployment.

Cross-Chain Identity: If identities are used across chains, claim verification must work cross-chain. Mitigation: standardized claim formats, cross-chain verification bridges.

Audit Checklist for On-Chain Identity

1. Key Management: Are key addition/removal properly restricted to management keys?
2. Claim Validation: Is signature verification correct? Can claims be forged?
3. Issuer Trust: How are trusted issuers managed? What's the compromise impact?
4. Revocation: Can claims be revoked? Is revocation checked during verification?
5. Privacy: Is PII ever stored on-chain? Are data hashes properly anonymized?
6. Recovery: Can identities be recovered if all keys are lost? What's the process?
7. Cross-Contract: Are identity interactions with registries properly secured?
8. Upgradability: Can identity contracts be upgraded? What are the risks?

Real-World Implementations

ONCHAINID (Tokeny): Reference implementation used by major security token platforms. Implements full ERC-734/735 with modular claim types.

Civic: Consumer identity verification with blockchain attestations. Focus on reusable KYC across platforms.

Polygon ID: Zero-knowledge identity claims enabling private verification without revealing underlying data.

Worldcoin: Proof of personhood using biometric verification with on-chain identity representation.

Identity Portability

A key benefit of on-chain identity is credential portability:

1// User verified for Token A can use same identity for Token B
2function investInNewToken(address newToken) external {
3    // Identity already has KYC claim
4    // New token's Identity Registry just needs to:
5    // 1. Trust the same claim issuers
6    // 2. Register the existing identity contract
7    
8    ISecurityToken(newToken).identityRegistry().registerIdentity(
9        msg.sender,
10        myIdentityContract,
11        myCountryCode
12    );
13}

Users complete KYC once, then use their verified identity across multiple security tokens—no re-verification required (assuming tokens trust the same claim issuers).

Understanding on-chain identity is essential for auditing compliant tokenization systems. The identity contract is the foundation of user verification—if it can be compromised, spoofed, or bypassed, the entire permissioned DeFi model fails. Auditors must verify: key management security, claim validation correctness, issuer trust boundaries, and proper integration with identity registries.