> For the complete documentation index, see [llms.txt](https://dataroom.mercle.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dataroom.mercle.ai/faqs.md). # FAQs What have other investors asked us.
How are you different from Worldcoin? World and Mercle are solving the same high-level problem, but with very different deployment models. World’s model depends on specialized Orb hardware and in-person verification. Their own materials describe the Orb as necessary for full verification, and World’s rollout is tied to Orb locations and operators. As of April 2025, World said it had more than 1,500 Orbs live across 23 countries. Mercle is built around a software-first model. Our thesis is that proof-of-humanity should eventually run on devices people already have, starting with smartphones. That makes onboarding more accessible, reduces operational overhead, and gives us a path to scale more like software than like a physical network. The strategic difference is in how each system gets there: * **World** is building around permanent specialized hardware. * **Mercle** uses limited high-fidelity collection infrastructure as a temporary training advantage, with the goal of pushing verification onto consumer devices over time. So the simplest way to say it is: **World scales by deploying more hardware. Mercle scales by improving software.** **Note:** our verification cost is at least 40x cheaper than Orb-based verification. In simple terms, World is closer to Waymo: specialized hardware, controlled rollout, physical deployment. Mercle is closer to Tesla: software-first, built on hardware people already have, and designed to improve and scale through the model.
Why choose Mercle over Worldcoin? S**hort answer:** mercle is built to be software-first, hardware-optional, so it scales at dramatically lower cost and with much higher accessibility. **1)** U**nit economics: materially lower cost per verified human** Worldcoin’s model depends on proprietary hardware and dedicated operator-led enrollment locations. that creates two cost layers: • High device capex, • Recurring opex for staffed, dedicated verification sites, Mercle is designed differently: • Works with existing camera + depth-sensor infrastructure (current mvp device cost: \~$350, expected to decline further at production scale), • Does not require a dedicated human operator, • Can be deployed inside existing high-footfall environments (e.g., retail points, supermarkets, cafés) instead of building net-new enrollment centers, **Result:** materially lower total cost to acquire and verify each unique human (current estimate: **\~40x lower** in comparable deployment settings). **2) Accessibility: verification should happen where users already are** Our goal is to make human verification frictionless and globally accessible: • No dependency on specialized, scarce hardware access points, • Verification can run on user-owned devices as camera quality improves over time, • Model performance compounds with richer real-world facial/depth data, improving uniqueness + liveness detection in a pure software loop, **Result:** faster onboarding, wider geographic reach, and better long-term scalability.
Why can’t Apple do this with Face ID? Because **Face ID is designed for authentication, not global uniqueness**. Apple built Face ID to answer a **1:1** question: *“Is this the authorized user of this device?”* Apple’s own documentation shows that Face ID is used to unlock a phone, approve purchases, and sign into apps, while the biometric data is encrypted, stored in the Secure Enclave, and kept on the device. Proof-of-humanity needs to answer a different **1:N** question: *“Is this the same human who already signed up somewhere else in the network??”* This requires some form of cross-device uniqueness check. Under Apple’s current architecture, Face ID is not built for that. It is intentionally designed to protect local device authentication, not to act as a shared biometric network. There are two reasons Apple is unlikely to solve this on its own. **First, the privacy architecture.** Apple’s model keeps biometric templates on-device and inside the Secure Enclave. That is excellent for privacy-preserving authentication, but it makes network-level deduplication much harder to do within the same design constraints. **Second, platform scope.** A proof-of-humanity standard is most useful when it works across platforms, apps, and devices. Face ID is a strong trust primitive inside Apple’s ecosystem; Mercle is building the network layer that can sit above any single hardware vendor. The best analogy is **Apple + ChatGPT**. Apple did not need to build every frontier model itself to give users AI, Apple Intelligence can call ChatGPT for Siri and Writing Tools. In the same way, Apple does not need to build a global uniqueness network itself. Apple can provide trusted hardware and sensors, while Mercle provides the cross-platform uniqueness layer.\ \ Other useful links:\ \ this validates that face as the input make sense as the UX to verify humanity
What’s your moat? Our moat today is **proprietary verification data** and the **learning loop** built around it. Over time, that compounds into **cross-platform network effects**. **1. Proprietary verification data** We are not training on generic face datasets. We are building a dataset from real onboarding flows across devices, environments, and geographies, including the cases that matter most for proof-of-humanity: spoof attempts, duplicates, retries, and real-world failure modes. That data is much harder to collect than 2D web-scraped imagery, and it directly improves model performance on liveness and uniqueness. This is the kind of data you only get by operating a live verification product. **2. Compounding learning loop** More usage gives us more attack data and edge cases. That improves accuracy, fraud resistance, and onboarding conversion. Better performance makes Mercle more attractive to platforms and users, which drives more usage and more data. The system gets stronger as it scales. **3. Cross-platform network effects** As more platforms accept Mercle ID, it becomes more useful to users because they can verify once and reuse that proof across products. As more users adopt Mercle ID, it becomes more valuable to new platforms. Over time, this creates a network effect around a shared proof layer. **Bottom line** Our moat is not just a static dataset. It is a live system that improves with real-world verification traffic and becomes more valuable as more platforms and users join. We start with proprietary data, strengthen through the learning loop, and compound into network effects.
What’s your business model? We are a **B2B API and SaaS company**. Platforms pay us to verify that their users are real and unique humans. Users do not pay. We make money in two ways: **1. Per-verification fees** Customers pay each time they verify a user. **2. SaaS / enterprise contracts** Larger customers pay a monthly or annual fee for volume, tools, support, and custom integrations. The logic is simple: the platform gets the value. Verification helps them reduce fake accounts, Sybils, spam, and abuse, so the platform should pay, not the user.
What’s your traction? We have 6 live SDK integrations, a 45,000-person waitlist, and face scans are growing 41% month over month.
What if someone just uses a photo or video replay? That is a basic **spoof attack**, and it is one of the first things our system is designed to detect. A real human face is a **3D object** with natural skin texture, depth, and subtle motion. A printed photo or a video replay on a screen behaves differently: it is either a **flat reflective surface** or a **light-emitting surface**. Because of that, the way light interacts with it is different from how light interacts with a real face. Those differences show up in the signals our liveness system looks for, including depth, motion, texture, and light-response patterns. So while a photo or replayed video may look convincing to a person at a glance, it is one of the simplest classes of attacks to test for in modern biometric verification.
For what use cases do you need proof-of-human vs derivative intent signals? Use intent signals for optimization, use proof-of-human for Trust. 1\. Intent signals are useful but probabilistic They’re great for ranking risk, UX tuning, fraud scoring, and low-stakes gating, where occasional mistakes are acceptable. 2\. Proof-of-human is needed when the downside of being wrong is really high For example: payments, account creation, access control, referral/bonus abuse prevention, reviews and ratings integrity, marketplace trust, voting and surveys, online exams/certifications, support abuse prevention, and any one-human-one-account workflow. 3\. Intent signals decay once exposed As soon as rules become known, attackers adapt and game them, this is an arms race. 4\. Proof-of-human is a root trust primitive It gives a direct yes/no on “is there a real unique human behind this action?”, which intent heuristics can’t guarantee. 5\. Best system is hybrid. Use proof-of-human as the hard identity anchor, then layer intent signals on top for risk and behavior monitoring,
What are you focused on in the next 3-6 months? Two priorities: 1\. Build proprietary human verification infrastructure + data moat, * deploy first batch of \~50 devices in live environments. * collect high-quality consented real-world verification data. * improve matching quality + anti-spoofing from that proprietary dataset. 2\. Close design partners through direct b2b sales. * run founder-led 1:1 on-ground sales in sf. * convert pilots into paid contracts with buyers who have immediate bot/sybil pain.