This specification defines a mechanism for issuing a non-transferable Soul Bound Token (SBT) as proof of successful authentication based on a Decentralized Identity (DID).
The proposed approach enables on-chain verification of credential possession using zero-knowledge proofs, allowing a smart contract to validate authentication without revealing personal information. Upon successful verification, an SBT is issued to the user’s address and can be used by relying services as an authentication and access control primitive.
Many blockchain-based applications rely on wallet addresses as the sole representation of user identity. While this model provides strong pseudonymity, it also introduces significant limitations for applications that require accountability, trust, or credential-based access control. As a result, decentralized finance platforms, metaverse environments, and on-chain governance systems often struggle with issues such as Sybil attacks, duplicate participation, and the inability to distinguish verified users from anonymous actors.
Decentralized Identity (DID) credentials provide a standardized way to represent verifiable claims about a user, such as affiliation, qualification, or eligibility. However, directly presenting or storing credentials on-chain raises privacy, usability, and interoperability concerns, making them difficult for application developers to adopt consistently.
This specification addresses these challenges by introducing a standardized mechanism for issuing non-transferable Soul Bound Tokens (SBTs) as a representation of successful credential verification. By binding the verification result to an SBT, applications can rely on a simple, privacy-preserving on-chain signal without accessing the underlying credential data.
This approach enables developers to build applications that require authenticated or credentialed users—such as gated DeFi participation, verified metaverse avatars, reputation systems, and access-controlled services—using familiar token-based interfaces. Service providers and application developers can integrate this standard without implementing custom credential verification logic, while users benefit from improved privacy, portability, and reusability of their authenticated status across platforms.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
NFT metadata structured according to the ERC-721 metadata standard is as follows.
{
"description":"University bachelor KYC",
"external_url":"https://api.kor.credential/metadata/1/1",
"home_url":"https://app.kor.credential/token/1",
"image_url":"https://www.poap.xyz/events/badges/example.png",
"name":" KOREA KYC",
"attributes" : { ... },
}
In addition to the existing NFT metadata standards, a new standard for identity verification supplements the metadata with the "Issuer" and "credentialNumber" sections. When issuing SBTs, the Issuer and the credential number from the Credential are specified. This approach ensures that the user's personal information remains private. In case of any issues, the identity verification process can be traced back by requesting the credential number used for verification from the Issuer without revealing the user's information. This standard represents an extension of ERC-721 metadata.
{
"description":"University bachelor KYC",
"external_url":"https://api.kor.credential/metadata/1/1",
"home_url":"https://app.kor.credential/token/1",
"image_url":"https://www.poap.xyz/events/badges/ethdenver-19.png",
"name":" KOREA KYC",
"attributes" : { ... },
"Issuer" : { ...},
"credentialNumber" : { ... },
}
We have defined a structure to represent VerifiedPresentation. It includes the user's wallet address, issuer, user name, and Credential Number
struct VerifiedPresentation {
address userAddr;
string issuer;
string user;
uint CredentialNumber;
}
Following that, here is the contract that verifies a user's Credential proof and issues SBTs:
In this scenario, a verification function validates a proof of credential possession. The mechanism used to generate and verify the proof is implementation-specific. Upon successful verification, the implementation issues a SBT to the user's address, completing the authentication process.
Implementations of this ERC MUST ensure that issued SBTs are non-transferable and MUST implement ERC-5192 (Locked SBT).
// SPDX-License-Identifier: CC0-1.0
pragma solidity^0.8.0;
interface IERC7574 {
/// @notice Verifies credential possession.
/// @dev Verification mechanism is implementation-specific.
function verify(bytes calldata verificationData) external returns (bool);
/// @notice Issues a non-transferable SBT after successful verification.
function issueSBT(address to, string calldata tokenURI)
external
returns (uint256 tokenId);
/// @notice Updates metadata to reflect revocation or status change.
function updateTokenURI(uint256 tokenId, string calldata tokenURI) external;
}
Through this process, obtaining SBT is the only means of authentication, and the possession of SBT subsequently serves as a method for identity verification.
This specification represents successful credential verification using a non-transferable SBT rather than exposing or storing the credential on-chain. A token-based signal allows relying contracts to integrate authentication using familiar ERC interfaces, while avoiding the privacy and linkability risks of publishing credential contents.
The standard intentionally does not mandate a specific credential-proof mechanism (e.g., a particular zero-knowledge proving system). Different ecosystems may prefer different proof systems or verification approaches, and requiring a single tool would prevent independent interoperable implementations. Instead, the ERC standardizes the outcome: successful verification results in issuance of a non-transferable token to the user.
Metadata is used to reference verification context (e.g., issuer and a credential reference identifier) while minimizing exposure of personally identifiable information. This enables auditability and revocation workflows (e.g., a relying party can request confirmation from the issuer using the reference identifier) without encoding user data in the token itself.
Revocation and status changes are represented by updating token metadata (e.g., tokenURI) rather than burning the token. Preserving token existence while changing its status allows applications to distinguish between "never verified" and "verified but later revoked" states, which is useful for access control and compliance scenarios.
Finally, transferability is disabled to ensure the authentication signal cannot be sold or lent. This preserves the intended meaning of the token as proof of verification bound to a specific address.
No backward compatibility issues found.
This specification does not mandate a specific credential verification mechanism. Implementers are responsible for ensuring the correctness and soundness of their verification logic, including protection against forged proofs or replay attacks.
Additionally, while the standard minimizes on-chain exposure of personal data, metadata fields such as issuer references should be designed to avoid unintended linkability across applications.
Copyright and related rights waived via CC0.