At the heart of Omni-ID technology is a Dynamic Soulbound Token. We abandoned the ERC-721 standard used for art collection and adopted the ERC-5192 (Minimal Soulbound NFTs) standard, which is designed specifically for “non-transferable relationships.”
5.1.1 Compliance with ERC-5192
Why choose ERC-5192?
The traditional ERC-721 standard allows for the free transfer of tokens, which is fatal to reputation systems—if a "five-star" account can be sold to malicious fraudsters, then reputation becomes worthless.
ERC-5192 is the "minimum soul-binding interface" standard established by the Ethereum community. It enforces locking logic on top of ERC-721.
2. Locking Mechanism
The Omni-ID contract rewrote the underlying transfer functions, physically blocking the transfer path at the code level:
Solidity
// Omni-ID Core Logic
function transferFrom(address from, address to, uint256 tokenId) public override {
revert("OmniID: Soulbound token cannot be transferred");
}
function safeTransferFrom(address from, address to, uint256 tokenId) public override {
revert("OmniID: Soulbound token cannot be transferred");
}
// ERC-5192 Interface Implementation
function locked(uint256 tokenId) external view returns (bool) {
return true; // Permanently locked upon minting
}
Uniqueness constraint: Each wallet address is limited to one Omni-ID in Mint.balanceOf(user) It is always equal to 0 or 1.
Revocability: Although users cannot transfer their IDs, the protocol has the highest authority (triggered by DAN adjudication) to executeburn() This is the ultimate punishment for serious fraudsters (such as those proven to have carried out Sybil attacks or malicious scams) – a “digital death penalty.”
5.1.2 Metadata Storage and Update Logic
Omni-ID had to resolve a contradiction: reputation scores needed to be frequently accessed by smart contracts (e.g., to calculate fee discounts), but complete profile data was too massive to be stored entirely on the blockchain.
To address this, we adopted a "dual-layer storage" architecture.
A. Layer 1: On-Chain Reputation State
Storage location: Ethereum/L2 State Trie
Data content: Only the most core quantitative indicators are stored.
Solidity
Purpose: To allow other smart contracts (such as OES escrow contracts, DeFi lending protocols) to IIdentity.getScore(user) It atomically reads user credit information, thereby automating the logic of "high credit, no deposit required" or "low fee".
B. Layer 2: Off-Chain Contextual Metadata
Storage location: IPFS / Arweave
Data content: Rich, visually appealing data.
JSON
Linking method: On-chain storage only tokenURI pointer.
Purpose: To provide front-end DApps, OpenSea, or recruitment platforms with a way to display users' detailed resumes.
C. The Dynamic Update Cycle
Omni-ID is not a static NFT; it evolves in real time with user behavior.
Trigger:
When an OES escrow transaction is finalized or arbitration is completed, the OES contract triggers emitReputationUpdate.
Calculation:
The on-chain ReputationController contract calculates the new score increment $\Delta S$ according to a predefined formula (see Section 5.2).
State Mutation:
The controller calls the Omni-ID contract's updateScore(tokenId, newScore).
Access control: This function is modified by the following modifiers onlyProtocol Protect your data and strictly prohibit users from modifying their scores.
Metadata Refresh:
If a user's level changes (e.g., from Level 1 to Level 2), the contract will trigger the BatchMetadataUpdate event (EIP-4906), notifying platforms such as OpenSea to fetch the latest NFT image again (e.g., a medal changes from bronze to gold).
This section demonstrates to technical readers, through a two-layer storage architecture, that Omni-ID possesses both DeFi composability (lightweight on-chain data) and a Web2-level user experience (enriched off-chain data).
