Basic Integration
This document provides an overview and integration guide for our smart contract, available as an npm package. You can install it with:
Package Structure and Overview
The package structure and a brief explanation for each part are as follows:
Basic Integration Strategy
To leverage the apps and infrastructure provided by Self, extend the SelfVerificationRoot
contract and use the verifySelfProof
function. Since SelfVerificationRoot
already contains a simple implementation, you usually won’t need to add extra code. For example:
For more details on the server-side architecture provided by Self, please refer to the detailed documentation on our website.
How the Integration Works
Application Integration: In your third-party application (which integrates our SDK), specify the target contract address for verification.
User Interaction: The user scans their passport on their device. The passport data, along with the contract address specified by your application, is sent to our TEE (Trusted Execution Environment) server.
Proof Generation: Our TEE server generates a proof based on the passport information and automatically calls the specified contract address.
Fixed Interface: The called contract uses a fixed interface—the
verifySelfProof
function in the abstract contractSelfVerificationRoot
—ensuring consistency across integrations.
Parameters: olderThan
, forbiddenCountries
, and ofacEnabled
olderThan
, forbiddenCountries
, and ofacEnabled
These parameters serve to both verify the correctness of the Groth16 proof and validate the public signals contained in the proof. The following points summarize their roles:
Verification: They ensure the proof is valid and that the public signals are correct. This validation is performed by our
IdentityVerificationHub
.Configuration: Set the minimum age (
olderThan
), the list of forbidden countries, and the type of OFAC check on each contract that integrates our system.
Proof Verification in IdentityVerificationHub
The following Solidity function shows how the IdentityVerificationHub verifies the proof:
Key Points in Proof Verification
Merkle Tree Usage: The proof must be generated using the Merkle tree maintained in our registry.
Timestamp Verification: The proof must have been generated recently, within a valid time window.
Older Than Check: If enabled, the proof must contain a valid age verification:
For example, if the contract is set to require an age of 18, then a proof generated for a user who is 20 will pass. Conversely, if the contract requires a minimum of 20 and the user’s proof indicates 18, the verification will fail.
Forbidden Countries Check: If enabled, you can specify forbidden nationalities.
The forbidden countries are represented as a packed list of three-letter country codes.
For gas efficiency, the check is performed on the packed data without unpacking.
Ensure that the order of the forbidden countries specified in your integrated application matches the
forbiddenCountriesListPacked
value in the contract.
OFAC Check: Self supports OFAC checks against the U.S. Treasury’s sanctions list.
There are multiple OFAC verification methods:
ofacEnabled[0]
: OFAC check using passport number.ofacEnabled[1]
: OFAC check using name and date of birth.ofacEnabled[2]
: OFAC check using name and year of birth.
Configure your contract to enable the same OFAC checks as those enabled in your application.
Enabled Flags: The flags (
olderThanEnabled
,forbiddenCountriesEnabled
, andofacEnabled
) allow you to save gas by skipping unnecessary verifications.
By following this guide, you should be able to integrate our smart contract into your application while maintaining flexibility over age restrictions, forbidden country checks, and OFAC verifications.
Feel free to adjust or extend the code and configuration according to your application’s needs.
Last updated