WorldID Semaphore Contracts

These are the underlying contracts that power World ID. If you're looking to integrate with World ID, you should use the Foundry or Hardhat starter kits.

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.

About World ID

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.

Privileged Actions and Trust

The WorldID Identity Manager uses a bifurcated notion of privilege in production. This operates as follows:

• Owner: The owner is responsible for administrating the contract. In production, the contract's owner will be a multi-signature wallet.
• Identity Operator: The identity operator is responsible for performing identity operations using the contract. In production, the contract's identity operator will be a wallet associated with OpenZeppelin Relay, ensuring that identities are submitted on-chain reliably and in order.

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.

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.

Development

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.

Testing

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.

Deployment

Deploying the Semaphore contract will require generating a verifier contract for our batch insertion service. Calling make deploy will guide you through the process of downloading the relevant tools, initializing and creating the required contracts.