This repository contains the underlying contracts that make World ID work, powered by the Semaphore library. These contracts are responsible for performing identity operations on chain, and attestation of identities for the purposes of semaphore proofs. Check out user-flows.md for more information on how these contracts relate to the rest of the World ID system.
World ID is a protocol that lets you prove a human is doing an action only once without revealing any personal data. Stop bots, stop abuse.
World ID uses a device called the Orb which takes a picture of a person's iris to verify they are a unique and alive human. The protocol only requires a hash-equivalent (i.e. irreversible) of the iris to be stored (which happens on a blockchain). The protocol uses Zero-knowledge proofs so no traceable information is ever public.
World ID is meant for on-chain web3 apps, traditional Cloud applications, and even IRL verifications. Go to the World ID app to get started.
The WorldID Identity Manager uses a bifurcated notion of privilege in production. This operates as follows:
All other contracts use a simple notion of an "owner", that will be held by a multi-signature wallet in production.
What follows below is a table of privileged operations in the WorldID Identity Manager contract, and which of the owner and identity operator has the permission to perform these actions.
||New Owner||Accepts the transfer of ownership.|
||Owner||Turns off the state bridge.|
||Owner||Turns on the state bridge.|
||Identity Operator||Registers new identity commitments into the World ID system.|
||Owner||Sets the table of verifiers used to verify proofs that correspond to identity updates.|
||Owner||Sets the address that has permission to act as the Identity Operator.|
||Owner||Sets the table of verifiers used to verify proofs that correspond to identity insertions.|
||Owner||Sets the amount of time it takes for a non-current tree root to expire.|
||Owner||Sets the contract used to verify semaphore proofs.|
||Owner||Sets the address of the state bridge. The state bridge is the contract responsible for sending identity tree updates to other chains.|
||Owner||Transfers ownership from the current owner to a new owner using a two-step process.|
||Identity Operator||Updates existing identity commitments in the World ID system. Updates are able to remove identities as well.|
||Owner||Upgrades the implementation of the identity manager to a new version.|
||Owner||Upgrades the implementation of the identity manager to a new version and executes a function call while doing so.|
While there have been some discussions pertaining to the implementation of timelocks for sensitive actions, many of these actions are required for administrating the contracts in conjunction with external services (such as the signup sequencer). To this end, timelocks would cause problems due to delays that could risk desynchronisation between the contract and external services.
This repository uses the Foundry smart contract toolkit. You
can download the Foundry installer by running
curl -L https://foundry.paradigm.xyz | bash, and
then install the latest version by running
foundryup on a new terminal window (additional
instructions are available on the Foundry repo).
You'll also need Node.js if you're planning to run the automated tests.
Once you have everything installed, you can run
make from the base directory to install all
dependencies and build the smart contracts.
The prover service comes with a way to generate test parameters—a mock insertion of a batch of
consecutive commitments into the tree. Assuming you've already run
make deploy, the prover service
binary should have been downloaded. To generate a test batch, run
./mtb/bin/mtb gen-test-params --tree-depth=... --batch-size=...
where the parameters MUST match the parameters passed for contract deployment. To transform these
into a proof, run the
prove command, passing the params on stdin:
./mtb/bin/mtb prove --keys-file=mtb/keys < GENERATED_PARAMS
The output of this, together with the relevant parts of the generated test params, should constitute
a correct input to the
registerIdentities method of the
Semaphore contract, as long as it was
deployed using the same keys file.
Deploying the Semaphore contract will require generating a verifier contract for our batch insertion
make deploy will guide you through the process of downloading the relevant tools,
initializing and creating the required contracts.