Skip to main content

Overview

The ZKScore Identity SBT (Soulbound Token) is the core smart contract that manages ZKS identities on the blockchain. It implements the ERC-721 standard with soulbound token mechanics, ensuring that identities cannot be transferred once activated, making them truly soulbound to their owners.
The Identity SBT contract is deployed on multiple networks. Always check the latest deployment addresses in the Deployment section before interacting with the contract.

Contract Architecture

Core Components

The Identity SBT contract consists of several key components:
  1. ERC-721 Base: Standard NFT functionality for metadata and ownership
  2. Soulbound Mechanics: Prevents transfer after activation
  3. Access Control: Role-based permissions for minting and management
  4. Metadata Management: On-chain and off-chain metadata storage
  5. Event System: Comprehensive event logging for indexing

Key Features

  • Soulbound Tokens: Once activated, tokens cannot be transferred
  • Metadata Flexibility: Support for both on-chain and off-chain metadata
  • Role-Based Access: Granular permissions for different operations
  • Gas Optimization: Efficient storage and operation patterns
  • Upgrade Safety: Immutable core logic with configurable parameters

Contract Addresses

Mainnet Deployments

Testnet Deployments

Contract Interface

Core Functions

Events

Soulbound Token Mechanics

What Makes It Soulbound

The Identity SBT implements soulbound token mechanics through several mechanisms:
  1. Transfer Prevention: Once activated, the transferFrom and safeTransferFrom functions revert
  2. Approval Blocking: Approval functions are disabled for activated tokens
  3. Immutable Ownership: Token ownership cannot be changed after activation
  4. Metadata Locking: Metadata becomes immutable after activation

Activation Process

Metadata Structure

On-Chain Metadata

Off-Chain Metadata

The contract supports off-chain metadata through IPFS or centralized storage:

Access Control

Roles

The contract implements role-based access control with the following roles:

Permission Matrix

Gas Optimization

Storage Patterns

The contract uses efficient storage patterns to minimize gas costs:

Gas Estimates

Contract Verification

Etherscan Verification

The contract is verified on Etherscan for transparency and security:

Source Code

The contract source code is available on GitHub:

Integration Examples

Basic Contract Interaction

Event Listening

Security Considerations

Audit Results

The Identity SBT contract has undergone comprehensive security audits:
  • Audit Firm: ConsenSys Diligence
  • Audit Date: January 2024
  • Severity: No critical or high-severity issues found
  • Report: Available here

Security Features

  1. Reentrancy Protection: All external calls are protected
  2. Access Control: Role-based permissions prevent unauthorized access
  3. Input Validation: All inputs are validated before processing
  4. Gas Limit Protection: Functions have reasonable gas limits
  5. Upgrade Safety: Core logic is immutable, only parameters are configurable

Known Limitations

  1. Metadata Immutability: Once set, metadata cannot be changed
  2. Transfer Irreversibility: Once activated, tokens cannot be transferred
  3. Gas Costs: Complex operations may have higher gas costs
  4. Network Dependency: Contract behavior depends on network state

Best Practices

For Developers

  1. Always Check Activation Status: Verify if a token is activated before attempting transfers
  2. Handle Events Properly: Listen for events to track state changes
  3. Validate Inputs: Ensure all inputs are valid before calling contract functions
  4. Use Proper Error Handling: Implement comprehensive error handling for all operations

For Users

  1. Understand Soulbound Nature: Once activated, tokens cannot be transferred
  2. Verify Metadata: Check token metadata before activation
  3. Secure Private Keys: Keep private keys secure as tokens cannot be recovered
  4. Test on Testnet: Always test operations on testnet before mainnet