Advancing Decentralization

Decentralization is a non-binary and nebulous term in that it means different things to different people. In the blockchain community, decentralization often refers to important properties of infrastructure like transparency, verifiability and its ability to recover from local participant failures. Those properties are important for the Worldcoin project to be a public good. More details on the derivation of important properties of the Worldcoin infrastructure can be found in this blog post.

The following sections outline different areas of the Worldcoin project and how different mechanisms can increase their respective transparency, verifiability and ability to recover from local participant failures. The ideas for optimal mechanisms may evolve over time, and suggestions for improvements are welcome.

User Agent

The user agent, i.e. the wallet, is what connects the user to the system and executes all user actions. It manages the user’s keys for both finance and identity. The finance part is a self-custody crypto wallet and thus permissionless. For the identity part, the user agent combines independent components into a functional system.

World App was launched as the first user agent to support the Worldcoin protocol, enabling people to get their World ID verified at an Orb and, if eligible, receive their share of WLD tokens.

Eventually, when verifying with an Orb, users should be able either to export their accounts into other wallets or to use a third-party wallet. Additionally, a World ID Wallet Kit could incorporate all the required capabilities so that other wallets could integrate World ID. This gives the user the choice of which user agent to use.

On the frontend, World ID is already available to any developer that wants to use Sybil protection in their application through the IDkit and developer portal. Users are able to use any third-party application through the World App.

The following sections walk through the displayed potential further improvements in more detail.

Self-custodial Wallet

Users should be able to access and control their funds and World ID in a self-custodial and censorship-resistant way; wallets should still allow for robust recovery solutions in case users’ phones are lost or stolen. Users should also not need to have prior knowledge about blockchains or deal with lower-level blockchain fee-pricing mechanisms. Users should also be always able to switch between different wallet implementations, optimally by keeping their public-facing account address if they wish. Finally, a wallet should be extendable and designed to allow for e.g. technological upgrades. Most of this is already implemented in the World App. While a self custodial recovery solution is implemented via iCloud and GDrive, better solutions are still an active area of research and development in order to enable a more seamless user experience.

Independent World ID Client

There should be multiple clients for users to choose from at the time of verification at an Orb or when using World ID to receive the WLD airdrop, where available. This reduces the risk of any vulnerability affecting all users, while also helping to ensure that wallets are available (e.g. in app stores).

Integrity Gateway

World ID Face Auth requires verifying the authenticity of the client app, because the comparison happens only locally on the user’s phone. While local computation could potentially be secured through zero-knowledge proofs and the Orb’s image is signed, the second input image has to be taken through the phone’s camera. Unless manufacturers begin attaching hardware attestations to those images, it fully relies on trusting the integrity of the phone’s hardware and software. However, those attestations already exist on an app level (e.g. Apple App Attest or Google Play Integrity) and can be used as attestations. The verification of those can be handled by “gateways” that sign off on individual requests and provide onchain verifiable signatures. Those gateways would ultimately also need to be provided with a list of accepted apps, managed via governance.

Orb Connect

The Orb currently relies on one-way communication with the app through the QR code and the permissioned Orb backend. To instead share more data with the user, this model could be replaced by an end-to-end encrypted connection between the app and Orb. It could not only facilitate the exchange of public keys but also the encrypted images from the Orb. This enables self-custody of images on the user’s phone and allows for future upgrades of the system without trusting an external custodian.

World ID Wallet Kit

The World App already contains all the logic for handling an Orb verification and using World ID to generate and submit proofs (such as when receiving WLD grants). This process can be made simpler and quicker for new teams building their own wallets. Wallet Kit should handle Orb Connect and establish the privileged execution environment on the phone through the integrity gateway. Importantly, it should also contain the mobile-optimized proof generation library.

Multi-Wallet Infrastructure

Users should be able to use World App in a fully self-custodial and censorship-resistant manner. They should also be able to switch between wallet providers. An open-source stack will enable this by making it easier for new wallets to be created. The following subsections detail milestones towards such an open-source stack.

ERC4337 Support

User transactions in the World App are currently based on Safe transactions; the custom format makes it less likely for teams to implement and run the infrastructure around it (e.g. bundlers). ERC4337 defines a common API for smart contract wallets and allows for interoperability. There are already multiple different smart contract and bundler implementations for ERC4337, which is the fastest and most flexible way to facilitate the integration for other wallets.

Bundler

Meta-transactions allow the batching of multiple users’ transactions and compress them permissionlessly without any sacrifices on self-custody. This significantly reduces the costs for users, with the minor downside of small additional latency. While bundlers are trustless, it’s beneficial for censorship resistance to have many of them and allow the user to switch between them. Also, the World ID proof could be combined with other proofs in a batch proof to make its usage more affordable on the Ethereum mainnet.

Wallet Support

ERC4337 transactions have their own format. The client and Safe contract (and perhaps Wallet Kit) should support this standard.

Relayer

Especially at scale, it is important for bundlers to be able to send transactions reliably. This seems to be a general-enough problem that it would benefit from a dedicated component (with optimally different implementations). A similar, currently closed-source service, is Open Zeppelin Defender.

Multiple Implementations

All of the above applies here as well. Due to the requirement of establishing device integrity of the phone in order to increase the trust in local computation, supported wallet apps should be whitelisted individually. The biggest requirement for going from 1 to n wallets will be a more scalable governance process to audit and whitelist those wallets and to refresh this list from time to time. Therefore, the community should create guidelines (e.g. a requirement for open source or a code audit) for wallet providers. Ideally, integrity would be ensured by multiple public providers, not only single gateway.

Hardware

In the context of the Worldcoin project, specialized hardware devices (Orbs) enable the verification of humanness and the issuance of World IDs. Several aspects can contribute to making Orbs more transparent and verifiable and increase their accessibility. One factor is to increase the reliability of Orb availability via multiple distributors and manufacturers. Additionally, increasing the transparency and verifiability of the Orb’s functionality can help align the incentives of manufacturers not to be malicious. Furthermore, letting anyone develop alternative Orbs democratizes the solution space.

The following sections walk through different milestones that can contribute to the robustness of Orb infrastructure.

Reduced Trust in Secure Provisioning

Approved Orbs are able to issue new World IDs. To ensure the integrity of the network and reduce trust in provisioning, certain requirements should be fulfilled (see Secure Provisioning Standard). However, there is no provably secure hardware, and certain points of trust remain as described in Orb Provenance Verification via User Agent. Importantly, the Worldcoin protocol doesn’t rely on perfectly secure hardware, as described in the limitations section, and audits like In-Person Auditing of Orb Locations can help decrease incentives for malicious actors. The following requirements can help reduce trust assumptions.

Onchain Orb Registry

The “Orb Registry” refers to the set of active Orbs endorsed by the Worldcoin Foundation and eventually the community. Only Orbs in this set can be used to generate new World IDs. If an entity’s process can be sufficiently trusted (e.g. by implementing a Secure Provisioning Standard and regular audits thereof), the insertion of public keys from that entity in the Orb Registry could be delegated to that entity. To limit the harm caused by a malicious Orb, World IDs registered with different Orb manufacturers (and ideally with different Orbs) should be distinguishable from each other. This makes it possible for the ecosystem to respond to (inevitable) attacks by removing individual Orb manufacturers, and perhaps even individual Orbs, from the whitelist on-demand. Optionally, World IDs associated with fraudulent Orbs could be revoked (see Revocation in the Operations section). This information can be private and only stored on the World ID holder's device as long as it is provable on demand. If anyone were mistakenly affected by such action, they could re-verify through an active Orb. As a last resort, disagreement in the set of trusted provisioning entities could be resolved by forking the protocol and adding or removing provisioning entities.

Secure Provisioning Standard

The ability to add malicious keys to the Orb Registry would allow for the creation of fake World IDs. A secure provisioning standard can make it very difficult to inject malicious keys. “Secure provisioning” refers to the process of setting up the cryptographic keys of an Orb. One part of such a standard could, for example, specify that only certain approved secure element models can be used, and require proofs of authenticity from each secure element (via die-unique certificates, signed by the secure element vendor) be reported alongside the public keys. Public keys generated by this process can then be considered for insertion in the Orb Registry.

Today, a secure provisioning process is in place that involves generating private keys on a secure element as well as burning secrets generated on an air-gapped machine connected to a Hardware Security Module (HSM) into private fuses (only accessible by TrustZone applets) on the NVIDIA Jetson. These secrets are destroyed immediately after being derived (using a NIST-SP-800-108 KDF algorithm) into two keys transmitted to the backend used for future device attestation. The original key material only exists in the restricted fuse banks on the NVIDIA Jetson. Continuous auditing of the process can help maintain a high security bar.

Eventually, provisioning entities could be required to stake a security deposit, which would get slashed if fraudulent Orb public keys from that entity are detected, for example through In-Person Auditing of Orb Locations. This could be proportional to the number of verifications the hardware of that particular vendor has performed or the number of Orbs that have been sold.

In-Person Auditing of Orb Locations

Auditing in-person locations of operations can help detect malicious operator behavior as well as malicious Orbs, thereby disincentivizing malicious behavior. No entity in the Worldcoin ecosystem should have to be trusted. Therefore, all operations need to be audited in a distributed manner.

One primary concern is an entity submitting a fraudulent Orb public key to the Orb Registry. In this case, “fraudulent” means the entity has a way to spoof requests to the Uniqueness Service as if they came from a legitimate Orb. Any valid Secure Provisioning Standard should make such an attack very difficult. However, the risks associated with malicious individuals involved in provisioning and/or flaws in digital security can’t be entirely eliminated. If the Orb public key is inserted to the registry, generating fake World IDs becomes straightforward and can only be detected and prevented through Anomaly Detection methods and audits. Assuming the list of Orbs and their location is public, such an audit could look like the following:

1. Verify that the Orb actually exists and is in a given location i.e. not in a lab, disassembled and compromised and reporting a wrong location.
2. Attest that an Orb’s public key is in the Orb Registry via Orb Provenance Verification in User Agent. If no Orb can be found, the public key should be removed from the registry and corresponding World IDs could be revoked through governance. In case any user was mistakenly affected, they could re-verify through an Orb.
3. Optionally, a mechanism to verify that the number of in-person verifications matches the number of onchain verifications could be implemented. If there is a mismatch, this indicates the generation of fake identities in the process. Importantly, such a mechanism should be implemented in a privacy-preserving way.

The auditing of Orb locations by incentivized users and dedicated auditing organizations, when combined with software and hardware security measures, can make generating fake IDs very hard. Today, operations are already audited by third-party organizations. To increase the robustness of this process, a list of all Orbs, their locations, and verification counts could be made public. Further, appropriate incentives could be put in place. To disincentivize malicious behavior even further, Orb manufacturers and operators could be required to stake a security deposit that would get slashed in the case of malicious behavior.

Incentivized Re-Verification

Similar to In-Person Auditing of Orb Locations, verified users can be randomly incentivized to re-verify at a different Orb. For any attacker who compromised an Orb or spoofed verifications, such a second verification at a different Orb would be very difficult to also spoof. Therefore, statistically, the fraction of incentivized users that end up verifying a second time with a different Orb would be lower for a compromised Orb.

Distributed Orb Supply

Increasing the number of entities that distribute and produce Orbs can help improve the robustness of the availability of Orbs. Importantly, hardware and firmware of Orbs should be standardized. While variability could eventually be beneficial in increasing network resilience, allowing for variability in the firmware would make it harder for the community to audit all implementations and would increase the probability of a fraudulent entity to issue World IDs.

Further, companies developing Orbs would by default be incentivized to build the cheapest devices possible by compromising quality (e.g. camera quality, hardware security, software security, privacy) to maximize profits. This can undermine the set of verified World IDs in the long term. Aligning developer incentives would require defining precise standards. While this is likely possible, it is impractical; complex incentive mechanisms for manufacturers, audits and bug bounty programs would be required, especially for the firmware (e.g. spoof detection, platform security). Even when standardizing firmware and hardware, there are serious trust assumptions with manufacturers, which are discussed in more detail in Verifiable Orb Provenance and Firmware.

Therefore, at least initially, the hardware and firmware should be standardized. Focusing ecosystem efforts on distributing production, making components public, verifying Orbs and conducting in-person audits is likely the best path to increase transparency, verifiability and robustness of Orbs. These mechanisms can help detect malicious manufacturers and disincentivize the spoofing or compromising of Orbs. Below are possible improvements to distributing and manufacturing Orbs:

Orb Supply Incentive Design

Financial incentives can encourage additional entities to distribute and produce Orbs.

Firmware Integrity Check

Due to the risks associated with malicious firmware developers, only firmware endorsed via governance should be able to run on Orbs. This also decreases the trust requirements in manufacturers. Today, this is achieved through NVIDIA’s secure-boot mechanism and Linux integrity checking (dm-verity). While no hardware security measure is impossible to circumvent, the above mentioned measures make loading unapproved firmware onto Orbs very difficult.

Second Orb Distributor

Additional entities that buy Orbs from manufacturers and distribute them through global warehouses can increase the robustness of global stock levels.

Second Orb Manufacturer

Additional entities that buy parts and modules and manufacture them in physically different locations can help increase the robustness of the supply of Orbs.

[Research] Secure Device Recovery

Firmware bugs could lead to non-functional “bricked” devices, with no possible resolution via over-the-air updates. While some bugs can be prevented through canary releases, others take much longer to surface. In such cases, a secure device-recovery mechanism can help re-enable bricked devices. Common options like password logins, SSH, and secondary boot media are inappropriate given the Orb’s security requirements. Further, NVIDIAs built-in recovery mode is deemed insufficiently secure and therefore disabled.

Today, Tools for Humanity uses an open-source remote access solution (Teleport) for device recovery. A more transparent and secure recovery mechanism might configure the Orb such that it enters a custom “recovery mode” when an authenticated USB device is present. Such a device would contain a signed payload consisting of the Orb’s public identifier and command to be run. Both should be signed by the provisioning entities' recovery private key ensuring that only a particular Orb could run the payload. This mode could provide enough access to restore the firmware to a known-good version. However, such a recovery mechanism would require physical access to the Orb’s mainboard, which means the tamper detection mechanisms will be tripped. Therefore, the Orb needs to be reprovisioned after it is recovered. The corresponding updates to the Orb Registry would then be a public record of the recovery.

Core Orb Engineering open source

To allow functionality of the Orb to be verifiable and enable anyone to build their own Orb, the firmware and hardware should be made open source.

Hardware source-available

Today, hardware components that aren’t security critical (e.g. tamper detection and security board) have been made source-available. Eventually, everything should be made source-available.

Core Firmware Components open source

Publishing core firmware components makes the functionality of the Orb more transparent and is a requirement to achieve Verifiable Orb Provenance and Firmware. Publishing the following components could satisfy those requirements:

• The main Rust application on the Orb, which handles (among other things) biometric capture, iris code generation and backend communication
• Custom applets for the Trusted Execution Environment (TrustZone)
• The secure element interface
• The custom GNU/Linux-based Orb OS, including the over-the-air update system, the Linux kernel configuration, and the file system integrity configuration (dm-verity)

Making these core components open source enables others to understand the functionality of the Orb in more detail and build alternative Orb firmware implementations. Once parts of the firmware are open source, there should be incentives through a public bounty program to submit potential vulnerabilities.

Given no hardware device can be perfectly secured, other sensitive components (like spoof prevention algorithms and fraud models) that may pose a direct integrity or security risk to the ecosystem if exposed should likely not be made open source. Importantly, the Worldcoin protocol doesn’t need to rely on perfect hardware security, when complemented with mechanisms like In-Person Auditing of Orb Locations. To reduce trust requirements, the open source code can define software “jails” for some closed-source components. For example, consider a closed-source fraud-detection module that ingests biometric data. The open source code that interfaces with this module can provide strong evidence that the closed-source code cannot save/upload the biometric data.

[Research] All Firmware open source

It is unclear whether publishing all Orb components is desirable given security considerations described in the section Core Firmware Components are open source. There should be a continuous evaluation of which sensitive components can be made open source. The most difficult types of components are likely to be machine learning models and code related to spoof detection.

Orb Security Transparent

Conducting and publishing audits, an open source code base, and employing bounty programs can help make the Orb more secure and increase transparency around security. Below are possible steps towards making the security of the Orb more transparent.

Presentation Attacks Bounty Program

One possible attack vector on the Worldcoin protocol is to create fake World IDs by spoofing the Orb (presentation attacks). Apart from other methods to detect and prevent such attacks, a bounty program can help raise the security bar. For example, the Worldcoin Foundation could award a certain amount of WLD for every novel presentation attack that is reported.

Publish Audits

Requiring conducting and publishing of audits of hardware and firmware can help reduce trust requirements and increase incentives for developers to implement secure systems. Such audits could entail both security and privacy considerations.

Private Bounty Program

A bounty program can raise the security bar by finding vulnerabilities early. A first version of a private bounty program has been launched on HackerOne. Gradually, more endpoints and source code should be added.

Public Bounty Program

Making the bounty program public can help increase the reach of the program. This should happen gradually.

[Research] Verifiable Orb Provenance and Firmware

While there is significant research involved, it would be ideal to allow the public to verify properties of active Orbs (don’t trust, verify), including:

• An Orb is from an Orb vendor that meets the standards and is not a counterfeit
• An Orb is configured to only boot signed firmware
• An Orb is running a specific version of the firmware

These verifications can help mitigate important privacy concerns related to biometrics. The public should not need to blindly trust an Orb vendor to faithfully/correctly implement privacy-preserving firmware.

Eventually, there might be a path to also allow for non-Worldcoin Foundation-governance-approved firmware, though it is unclear whether this would be desirable given the potential downsides. Appropriate incentive and audit mechanisms to disincentivize malicious behavior would be required, which might not be viable in practice.

Orb Provenance Verification via User Agent

A first step towards verifying an Orb as non-counterfeit could be implemented through provenance verification via the User Agent. Such a mechanism could help verify that an Orb is from a vendor that has been approved by Worldcoin governance and therefore is running approved firmware. Such a feature can be integrated in other protocol-compatible apps.

One possible path for such a verification could be to ask the Orb to sign a challenge that has been generated by the App. Orbs contain two mechanisms for cryptographically attesting they are in the Orb Registry: private keys in the secure element and private keys derived from fuses on the NVIDIA Jetson. Verifying signatures from both sources provides strong evidence that an Orb was manufactured by a vendor that has been approved and was not subsequently tampered with. Verification of the NVIDIA Jetson fuse state can provide strong evidence that Orbs can only boot firmware that has been signed. The user agent could also request an Orb’s firmware version from the Trusted Execution Environment’s (TEE) secure storage. As part of a normal boot, the root hash for dm-verity can be delivered to the bootloader by the TEE, ensuring that only code authorized by the TEE is able to boot. Inside of secure storage, these hashes would be associated with version numbers, allowing an entity (e.g. the World App) to request attestation of the current hashes and version numbers existing in the secure storage.

This mechanism assumes that an Orb’s private key only exists in its secure element (i.e. there are no other copies), a constraint which should be specified by the Secure Provisioning Standard. Private keys are generated on the secure element directly and never leave, and a series of transparent certificate attestations during generation and export can prove that a particular key originated from a legitimate secure element. Therefore, physically attesting an Orb has a private key provides strong evidence that the same private key is not in the control of an attacker. Extracting private keys from the Orb’s secure element is assumed to be extremely difficult.

It is important to note that it is impossible to fully eliminate trust in the Orb hardware vendor/manufacturer or upstream vendors. The following attack vectors remain:

• The Orb vendor could bypass parts of the secure provisioning process (due to malice or incompetence), invalidating the guarantees of the proposed verifications. Therefore, Orb manufacturers should be audited to ensure the Secure Provisioning Standard is maintained.
• NVIDIA firmware could have security vulnerabilities or backdoors, which could threaten the Jetson fuse attestation.
• The secure element vendor could be compromised/incompetent/malicious, which would threaten the integrity of the corresponding attestation.
• While the combination between dm-verity and TrustZone version tracking based on the filesystem’s merkle-tree may allow for extremely trustworthy version information to prevent the use of signed but deprecated firmware, bugs in the TEE implementation could lead to a loss of integrity.
• The Worldcoin Foundation could sign malicious firmware. Adding Hardware Support for Firmware Verification can help set up procedures to verify the actual firmware that is running on an Orb.

Therefore, there should be mechanisms to mitigate the risk of fraudulent manufacturers or compromised Orbs. In-Person Auditing of Orb Locations and Incentivized Re-Verification can make exploiting backdoors significantly harder and help detect malicious verification of World IDs in retrospect.

Public Build Pipeline

The builds for each production Orb firmware release can be built in a publicly-visible way. This does not have the same guarantees associated with reproducible builds and the ability to dump the flash of the main computing unit of the Orb. However, it still improves transparency and verifiability as it provides a mechanism to trace changes in open source Orb firmware components to their inclusion in the deployed firmware. For each Orb firmware version, there should be a link to the corresponding sources and public build logs.

[Research] Reproducible Builds

Without reproducible builds, the public is required to trust that compiled firmware wasn’t maliciously modified during/after the build. Reproducible builds provide a mechanism to verify that Orb firmware was compiled from a specific state of the public repositories. To verify the integrity of the firmware, third parties should be able to build it from source on their own infrastructure. Full reproducibility means the resulting artifacts should be identical to those deployed to Orbs, and the signature from the signed firmware should be valid for the self-built firmware. The initial priority should be to make privacy-sensitive components of the firmware open source and reproducibly built.

However, there are some limitations. The firmware should (at least initially) include closed-source components, which are opaque parts of the system. Some of these are from Tools for Humanity (e.g., spoof-detection models) and some are from vendors (e.g., NVIDIA firmware components). Additionally, some components may be hard to make reproducible. These can be built separately and pulled in as compiled components to the main build.

[Research] Hardware Support for Firmware Verification

The most transparent way to verify firmware would be by having read access to the persistent storage of the main computing unit. Future Orb versions could include external ports for directly reading the flash memory of the main processor. However, a hardware implementation that provides read-only access to the flash memory—without introducing new security risks—still needs to be validated. If a hardware implementation is possible in a secure way, public auditors could then be incentivized to use this mechanism for verifying the integrity of a particular Orb’s firmware. The integrity verification of the dumped memory could optionally reuse the Orb’s internal integrity verification mechanism (dm-verity). This can provide stronger guarantees than Orb Provenance Verification via User Agent as there are less attack surfaces for spoofing direct physical access relative to remote attestation schemes.

While this mechanism would provide very strong guarantees for the firmware state, it is still possible to spoof the auditor at the hardware level. For example, there could be a second hidden flash chip that the Orb is actually booting from. This risk could be mitigated by additional audits that inspect the hardware directly on a random subset of devices. Further, in-person audits of Orb locations can make attacks significantly easier to detect and can create disincentives for malicious behavior.

Build Your Own Orb

Enabling anyone to build their own version of the Orb is an important aspect to enable forkability of the Worldcoin project.

Non-provisioned Orbs for Sale

Enabling anyone to buy non-provisioned / unlocked hardware allows them to flash their own firmware and do their own development.

Operations

Operations, in the context of the Worldcoin project, refers to procedures in the “analog world” that allow people to get their World ID verified. The primary participants are Orb operators (i.e. independent entrepreneurs and their organizations around the world) who provide Orbs in physical locations for people to verify. Certain infrastructure primitives can help reduce trust assumptions and aligning the incentives of all participants.

Responsible Operations Assurance

Auditing of operations from different angles can help reduce trust assumptions and align incentives of ecosystem participants. The following subsections very briefly introduce mechanisms that can help to this end.

Code of Conduct

Basic set of rules operators should adhere to and can be audited against.

Community Hotline

Ability for anyone to submit reports of fraudulent behavior. To avoid spam, this might eventually have to be gated on the reporting individual having a World ID or staking a small sum.

In-Person Auditing of Locations

See Hardware

Incentivized Re-Verification

See Hardware

Location Audit Bounty Program

A location-audit bounty program can help increase the resilience of in-person audits by incentivizing random ecosystem participants to audit operations. Importantly, such a bounty program requires careful mechanism design to avoid unintended side effects, including collusion.

Onchain Orb Registry

See section in Orb

Public Orb Metrics for Anomaly Detection

Metadata from Orbs could be made public to be utilized for distributed anomaly detection, to spot outliers and inform decisions on which Orbs to audit in person as well as surfacing discrepancies between onchain verifications and in-person verifications.

World ID Integrity Mechanisms

Distributing the issuance and custody of World ID requires incentive mechanisms to ensure high World ID integrity (i.e. making it hard to illegitimately acquire and use the World ID of others). Such mechanisms across all participants—from hardware manufacturers to individual Orb operators to users—can disincentivize actions that undermine World ID integrity.

There are several scenarios that could result in the illegitimate creation or fraudulent ownership of World IDs:

1. Verification Device Compromise: A third party submits fraudulent verifications by compromising the hardware or spoofing the verification process.
2. Identity Theft: The device operator or a third party manipulates individuals into verifying or compromising their phone to access their World ID.
3. Identity Sale: An individual decides to sell their World ID to a fraudulent actor.
4. Issuer Fraud: Organizations developing the firmware for verification devices secretly generate World IDs.

Each scenario decreases the utility of the World ID issued by the Orb, so measures to make these attacks more costly are important. The difficulty of compromising verification devices is increased by the Bug Bounty Programs mentioned in the section about the Orb. Another important defense is the In-Person Auditing of Locations, which increases the difficulty of a large amount of attacks. Additional defenses are described below:

Face Authentication

As part of the verification process, a signed and encrypted face image could be transferred to the user's phone. The user could then authenticate against that image within the app, an approach similar to FaceID, making it hard to authenticate using the World ID of someone else. Beyond face recognition, the phone would also need to perform liveness detection to prevent spoofing attacks. The security guarantees that such a liveness check has actually been conducted and not spoofed are lower on consumer phones compared to custom hardware like the Orb (given consumer cameras are less advanced and that it is hard to create a trusted execution environment on a person’s phone to ensure computational integrity). With improvements in mobile zero-knowledge proof abilities, it may become possible to compute the authentication and liveness checks inside zero-knowledge proofs on the user's phone, which would increase the security guarantees.

Iris Authentication

Similar to face authentication, iris authentication performs a biometric authentication against a biometric template as well as a liveness check. By requiring people to come back to a biometric verification device, the security guarantees that the liveness check has not been spoofed or bypassed are increased at the cost of convenience. If both face authentication and iris authentication were implemented, developers could choose which level of security is required for their application.

World ID Reset

World ID Reset allows anyone to get a new World ID in case they have lost their previous World ID. Further, victims of social fraud and identity theft should be able to reset their World ID through an Orb using only their biometrics. This would also make the purchase of other individuals’ proof of personhood less profitable from a game-theory perspective given individuals could get a new World ID and deactivate the sold one.

Revocation

If a particular firmware version of a verification device is deemed insecure or an operating organization is found to be fraudulent, World IDs can be revoked in retrospect, to eliminate potential fraudulent identities. Eventually, there might be the need for an adjudication body that conducts such investigations and actions. If any real and legitimate individuals are affected, they could re-verify at an Orb.

[Research] Permissionless Operations

In an ideal world, anyone should be able to acquire Orbs and onboard others. To reach this point, however, significant research is required and operations must be audited with a high degree of certainty.

Operators Receive Rewards in WLD

Initially, operators were paid in USDC. Since the launch, the operator rewards have been transitioned to WLD, where laws allow.

Protocol

The protocol contains off- and onchain components that are responsible for handling e.g. verification or authentication requests from users. Since privacy is central to World ID, it is especially important to not sacrifice it in favor of accelerated increases in transparency, verifiability and resilience. One example of this is the uniqueness service, which still requires more research before it can be made more permissionless.

The following sections describe possible improvements to further increase transparency, verifiability and robustness of the protocol.

Protocol Open-Source

Most of the components of the protocol components are already open source (see the open source tree)—except for the uniqueness service.

Protocol Security Transparent

Over the course of several months beginning in April 2023, audit firms Nethermind and Least Authority conducted two separate security assessments on the off-chain and onchain components of the Worldcoin protocol, including the following parts of the protocol:

• Correctness of the implementation, including cryptographic constructions and primitives and appropriate use of smart contract constructs
• Common and case-specific implementation errors
• Adversarial actions and other attacks on the code
• Secure key storage and proper management of encryption and signing keys
• Exposure of any critical information during user interactions
• Resistance to DDoS (distributed denial of service) and similar attacks
• Vulnerabilities in the code leading to adversarial actions and other attacks
• Protection against malicious attacks and other methods of exploitation
• Performance problems or other potential impacts on performance
• Data privacy, data leaking and information integrity
• Inappropriate permissions, privilege escalation and excess authority

Of the issues detected by Nethermind, which performed a comprehensive audit of Worldcoin’s smart contracts, 92.6% were identified as fixed after the re-audit stage, while 3.7% were mitigated and 3.7% were acknowledged.

Details of both audits can be found in the Nethermind and Least Authority reports.

Publicly Available Merkle Tree

The set of World ID public keys is already publicly available and committed to by the sequencer on Ethereum. The public keys are available as calldata and the current state of the Merkle tree is committed as a Merkle root. Its validity is enforced through a ZK validity proof of batch insertions of public keys. While this ensures that the committed root actually corresponds to a Merkle tree, it’s not yet ensured in the validity proof that the public keys actually originate from an Orb. Even though the leaves are publicly available, it’s practically infeasible for the client to download all of this data and reconstruct the tree in order to be able to compute a Merkle inclusion proof. The tree availability service serves those Merkle inclusion proofs to clients. Clients can check the correctness of the Merkle proof against the onchain root. However, this request can leak additional metadata about the client (e.g. IP address). This can be addressed by routing those requests through mixnets or Private Information Retrieval (PIR).

Permissionless Merkle Tree

As mentioned above, the validity proof of the Merkle tree needs to be enriched by a signature check of the public key. Once this check is added, trust in the identity sequencer is no longer required. Similar to the uniqueness service, this sequencer also needs to actually implement coordination to rotate between multiple sequencers, so there is no possibility of censorship.

User-Centric Flow

Currently the verification flow (and similarly the reset flow) are intertwined with different services, with some being permissionless and others not. Going from an intertwined architecture to one in which components are separated allows to increase transparency, verifiability and robustness of individual components. This architecture is described in more detail in the Advancing Decentralization blog post. This also allows the user to own their data and selectively share certain parts with the required services. A first step and prerequisite for this is to allow the user to retrieve all the data generated by the Orb. This requires an end-to-end encrypted, direct peer-to-peer connection between the user and the Orb, which is referred to as “Orb Connect.” However, the primitives used to build this communication layer could also be reused for all other communication between the client and nodes or services.

No Single Point of Failure for Orb Verification

Increasing the resilience of the uniqueness service is challenging, because a permissionless operation of the service would require iriscodes to be public. A permissioned set of nodes that run the computation and agree on the result through consensus, or run the comparison on a reduced version of the iris codes so that no node has the full code improves the verifiability of the system. Successful research on iris hashes could enable making them publicly available and allow for permissionless operation. A draft with more details can be found here.

Public and Permissionless Uniqueness Service

The most difficult dependency is the research on beyond state-of-the-art template protection of iris codes. This is a prerequisite to make the operation of the uniqueness service permissionless. This can be achieved either by publishing anonymized iris hashes (the database needs to be available and readable for the service to run the deduplication) or by multiple parties running the service where each party performs the computation on one shard of the data. Besides that, research similar to that currently being conducted with respect to other sequencer models (e.g. for rollup sequencers) is needed. The problems and solutions should be very applicable to this model as well.

Governance

A global community of developers, individuals, economists and technologists conceived and made early contributions to the Worldcoin protocol. The original idea started with co-founders Sam Altman, Alex Blania and Max Novendstern, who assembled a team to take the initial steps toward development of technology to support Worldcoin via their company Tools for Humanity.

Tools for Humanity’s mission is to build a more just economic system. It is a Delaware (U.S.) corporation headquartered in San Francisco, California, with a wholly-owned subsidiary, Tools for Humanity GmbH based in Germany. Tools for Humanity supported Worldcoin’s multi-year beta testing phase, during which it developed the Orb and the World App.

To date, Tools for Humanity and other early contributors are committed to providing every person on the planet access to the global economy, regardless of country or background.

Today, the governance of the Worldcoin project is overseen by the Worldcoin Foundation, an independent entity, which is committed to continue transitioning governance to all of humanity. It is also important that this happens in a deliberate way and that governance (e.g., voting) is well studied and tested before complete control is fully transitioned.

The following sections describe different improvements that already have and can contribute towards this objective.

Worldcoin Foundation Setup

On October 31st, 2022 the Worldcoin Foundation was established as the non-profit steward of the Worldcoin protocol, supporting and growing the ecosystem as it becomes self-sufficient. The Foundation’s main objective is to scale an inclusive identity and financial network as a public utility and to expand the governance thereof. This infrastructure has the potential to empower everyone to participate in the global economy in the age of AI and provide the foundation for shared governance of for universal basic income.

The Foundation is an exempted limited guarantee foundation company, which is a type of non-profit incorporated in the Cayman Islands. It has a wholly-owned business company subsidiary in the British Virgin Islands called World Assets Limited. This is “one of the most often used, and internationally recognized structures” for decentralized blockchain projects. To learn more about this entity arrangement, check out this Guide to the Cayman Islands Foundation Company from the Foundation’s outside counsel at the law firm Ogier. The Worldcoin Foundation is “memberless”; it has no owners or shareholders.

This entity setup was a good fit for the Worldcoin project due to the Foundation’s separate personhood, limited liability, tax efficiency, support for compliance with virtual asset regulations, and suitability for long-term community governance. That last point is especially important. Cayman foundation companies can be structured to be “memberless” (that is, have no owners or shareholders) and instead to take instructions from token holders and/or World ID holders. They can therefore gradually steer matters such as running a grant program, open sourcing intellectual property (IP), entering into service agreements, and managing a treasury. In the case of the Worldcoin project, the shared governance model is all the more critical so that, in the long-term, decisions can reside with the community.

At the same time, the Foundation can aid the community’s governance by safeguarding protocol IP. In most legal systems today, a traditional legal entity is needed to protect IP such as trademarks, open-source copyrights and domains. Tools for Humanity has already transferred core protocol IP to the Foundation, including smart contracts, the World ID SDK, patents for the Orb design and iris recognition technology, brand assets, domains and social media accounts. And the Foundation has open sourced several core tech repositories and made the Orb’s hardware available under its Responsible Use License.

Transfer of Control and Ownership to the Foundation

In order to facilitate a governance model that involves all of humanity, several assets and key components have been transitioned to the Worldcoin Foundation:

• Treasury: The Worldcoin Foundation (and/or its affiliate entities) manages the treasury of tokens once they are unlocked. This includes Worldcoin grants, Operator rewards, and other contributor grants.
• Orb IP: Tools for Humanity has transferred the Orb IP to the Worldcoin Foundation. - The Orb hardware and software will be made publicly available under a restricted use license, prohibiting the misuse of the technology. This allows the Foundation to onboard other organizations building Orbs or similar devices.
• Data: In the case of the Worldcoin project, due to the protocol’s use of personal data, the shared governance model is especially important. The Foundation is the “data controller” for any personal data collected via Orb sign-ups after network launch. Through its data consent form, the Worldcoin Foundation makes it clear that “We will never sell your data. We will also not use any data listed in this form to track you or to advertise third parties’ products to you,” and that “We will not sell, lease, trade, or otherwise profit from your biometric data.”
• Ability to Whitelist Orb Provisioning Entities: The Foundation manages the permissions for adding Orbs to the network, balancing hardware distribution, security, and growth.

In order to grow the network and ultimately enable all of humanity to participate in the governance of the Worldcoin project, the issuance of World ID and allocation of the WLD token (in certain countries) is ongoing.

Support Future Development

To encourage individuals and organizations to contribute to the Worldcoin ecosystem through research, the development and production of Orbs or auditing the system, the Worldcoin Foundation is setting up a grants program. Further, the Worldcoin Improvement Proposals (WIP) process is currently being created and will be open for proposals soon.

Separately, the Foundation intends to work on common standards and ecosystem-wide proposals. For example, today, Orbs are developed and produced by Tools for Humanity. Orb operations are managed by several organizations around the world. With support from Tools for Humanity, the Foundation will work on standards and incentives for organizations to develop, produce and operate Orbs such that production of Orbs and their operation can be further distributed. More details can be found in the sections on Hardware and Operations.

Initial Community

The Worldcoin project maintains a dynamic and evolving blueprint that is subject to change and refinement through input and decisions from the Worldcoin community. Today, whether you are a developer, a user, an enthusiast, or simply someone interested in the future of decentralized systems, you can learn more and participate through the following channels:

• Join the community discussion on Twitter or Discord
• Contribute to open-source repositories on Github
• Visit the World ID Developer Docs and Portal
• Reach out directly to the World ID team
• View live onchain data on Dune Dashboard
• View the Open Source Overview

To enhance transparency and facilitate community involvement, regular community calls should be established with the aim to provide a platform for open dialogue and updates on the Worldcoin project's progress. Additionally, a dedicated forum similar to ethresearch should be set up to further foster meaningful discourse and engagement around the Worldcoin project. This forum will serve as a hub for ideas, suggestions, and discussions among community members and the project team. Lastly, the Foundation has already hosted several developer meetups and strives to create more opportunities for developers to collaborate, innovate, and contribute to the Worldcoin project.

Decisions by Community

Increasing the resilience of the governance of the Worldcoin protocol is both imperative and unprecedented, given the foundational nature of proof-of-personhood infrastructure and the ambition to scale it to billions of people. Building a community-based governance system for Worldcoin represents perhaps the most formidable challenge of the entire project, and this process is still in its earliest stages.

The Foundation should ultimately have a limited role in the protocol's governance. To this end, the Foundation’s founding documents have provisions for community-driven governance. These provisions make it possible, through a prescribed process, for the community to make recommendations to the Foundation’s Board of Directors. For further details, see the Foundation’s Memorandum of Association and Articles of Association.

World ID provides unique infrastructure for distributed governance and presents the opportunity to harness input from a large and diverse set of individuals for community-driven governance. The reach of World ID is unprecedented: over two million World IDs have already been issued, and tens of thousands more are issued each week. As a proof-of-personhood protocol, World ID naturally supports “one-person-one-vote” voting, in contrast to token-based voting commonly used by other blockchain projects. Notably, this adds more democratic options to the design space of voting mechanisms for Worldcoin. However, the exact structure of delegating decisions to the community needs careful iteration and consultation with experts. Further, many governance decisions notoriously lack engagement from participants. Therefore, it will be important to encourage a large set of people to participate and explore the decisions. In the future, the User Agent should not only serve as an entry point into using Worldcoin, but also the governance over it.

[Research] Full Handover to Community

The Worldcoin Foundation is committed to continuously transition governance towards a model that involves all of humanity. This is an unprecedented endeavor in scale and complexity for a decentralized system, which will require a methodical and gradual approach. Key aspects like voting mechanisms should be thoroughly researched, validated with experts and tested before meaningful control is transferred. Transparency, inclusivity, and neutrality are essential. However, these attributes contribute to intricate governance structures like today’s democracies, which can lead to often slow and expensive decision-making. While this deliberateness is beneficial for making long-term strategic decisions, such as amending a constitution, it can hinder the ability to quickly adapt to new challenges during the initial growth phases. Hence, prematurely adopting a governance model that fully transitions governance to the community without a well-vetted plan is itself a failure mode to be avoided.

The Foundation will solicit proposals for how token holders and World ID holders should interact in Worldcoin’s governance model. In general, the Foundation seeks input from contributors, the community and experts in the field as it increases the robustness of the governance of the Worldcoin protocol.