> 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/traction-and-gtm.md). # Traction? & GTM? Learn about current traction and future GTM Mercle is live and showing early traction across both user verification and third-party platform integrations. As of March 19, 2026, Mercle has verified 1,148 humans across 30+ countries, and 25 active third-party applications have integrated the Mercle SDK, generating 649 completed verification sessions. The product is pre-revenue today: integrations are free while Mercle grows verification volume, improves model performance, and validates the highest-value workflows for customers. Monetization begins as Mercle becomes embedded in recurring trust-sensitive workflows inside partner platforms.
#### Traction Snapshot **Developer and user traction** * 1,148 verified humans across 30+ countries * 6 active third-party applications using the Mercle SDK * 649 completed verification sessions through third-party applications **Live verification performance** * Across 931 live sessions, liveness pass rate was 92.16% * Face-match verification rate was 99.46% * Phone verification rate was 99.89% * 19 duplicate / suspected sybil accounts flagged to date #### Growth Mercle launched in August 2025. Growth to date has been entirely organic, driven by social distribution and developer word-of-mouth rather than paid acquisition, outbound sales, or formal partnerships. Monthly new verified humans were 54 in August 2025, 173 in September, 54 in October, 301 in November, 386 in December, 74 in January 2026, 79 in February, and 27 so far in March. The strongest growth came in November and December, when focused content on X and a product video drove 300–400 new verified humans per month. This showed that lightweight, content-led distribution can generate real demand without paid acquisition. In Q1 2026, the team shifted effort toward infrastructure and model development, and growth slowed accordingly. The seed round funds the next phase: turning early organic pull into repeatable distribution and structured platform partnerships. #### Third-Party Usage Mercle is already being used inside external products, not just its own app. Completed verification sessions through third-party applications grew from 4 in October 2025 to 165 in November and 270 in December, before settling at 107 in January 2026, 69 in February, and 34 so far in March as product focus shifted toward infrastructure and model development. This matters because it shows Mercle’s demand is not limited to direct user acquisition. Developers are already routing real verification traffic through partner surfaces, which validates the SDK as a distribution channel and the product as infrastructure rather than a standalone app. #### Early Use Cases Mercle’s strongest early traction is in products where fake users directly break the experience or economics: games distributing financial rewards, online communities managing participation and moderation, and crypto applications defending against sybil abuse. Current use cases include proof-of-human gating for token and reward systems, verified participation across Telegram, Discord, and Reddit communities, and other trust-sensitive flows where platforms need confidence that an account or claimant maps to a real human. *** ### GTM Mercle’s ‌go-to-market ‌plan ‌is straightforward: begin in places where proof-of-human has clear, immediate financial value, then carry that same credential forward as the internet shifts toward agents. #### Initial Wedge Mercle starts in environments where fake or duplicated users directly damage the product: games distributing financial rewards, online communities managing participation, and crypto applications defending against sybil attacks. In these markets, the core problem is the same: platforms need to know that an account, participant, or claimant maps to a real human. Mercle solves that problem with a mobile-first verification flow and a lightweight integration model that fits directly into existing products. The product is designed for this wedge. Verification runs on devices users already have, and the integration pattern is lightweight enough to fit naturally into onboarding, gated access, rewards claims, and other trust-sensitive workflows. Platforms can deploy proof-of-human without specialized hardware or major infrastructure changes. #### Go-to-Market Motion Mercle’s initial distribution model is developer-first and bottom-up. Developers integrate Mercle to solve a single high-pain workflow such as gated access, anti-sybil rewards, or verified participation. Once deployed for one trust-sensitive surface, the same integration can expand into other parts of the product, including moderation, reputation, rewards, and identity-based participation. The next step is to turn this organic developer pull into structured distribution through better developer tooling, targeted outreach in high-abuse communities, and direct partnerships with mid-sized platforms in gaming, social, and community infrastructure. Over time, Mercle expects a land-and-expand motion: start with one use case, prove value quickly, then become a broader trust layer across the product. #### Expansion: Human-Backed Agents The same proof-of-human primitive extends naturally into the next market: agents acting on behalf of humans. As users increasingly rely on agents to browse websites, retrieve information, access services, claim rewards, and complete online workflows on their behalf, platforms will need a way to distinguish between arbitrary automation and an agent backed by a real human principal. That is the next trust layer the internet will require. Mercle can provide that credential. Instead of only verifying humans directly, Mercle can allow platforms to require proof that an agent is operating on behalf of a verified human before granting access to protected pages, gated workflows, rewards flows, or other higher-trust actions. This makes Mercle more than a verification tool for accounts. It becomes the human credential layer for the agentic internet: infrastructure that lets platforms safely unlock agent-driven use cases without opening themselves to spam, fraud, or sybil abuse. #### Why This GTM Works Mercle does not need to start by selling a speculative future category. It starts where proof-of-human already solves painful, high-frequency problems today. That creates near-term adoption, real verification volume, and product distribution inside third-party platforms. From there, the same credential expands into a larger market as agents become a more common interface to the internet. Mercle starts by proving humans directly, then extends that same trust layer to agents acting on behalf of those humans. *** ### Why Mercle Will Win To ‌prove ‌someone ‌is human across the public internet, you have to address three linked problems at the same time. Most approaches tune for one, sometimes two. Nobody has reliably delivered all three together because each fix pushes on the others, the same core design choices that increase verification efficiency also set the limits on accessibility and cost. Mercle is designed with that dependency in mind.
**Verification Efficiency** Verification efficiency is the system's ability to correctly distinguish every individual on Earth from every other individual measured by false accept rate (FAR). At 9 billion scale, this requires capturing roughly 70 or more bits of entropy per person. Standard RGB cameras fall short. The biometric signal from a typical selfie simply does not contain enough unique information to guarantee one-to-one distinction across a global population. Mercle's approach is to build a specialised capture device that collects high-resolution, multi-dimensional facial data far exceeding the entropy available from a standard camera. This rich dataset is then used to train a distilled model that can approximate uniqueness verification on RGB input alone. The device generates the data that makes the software work without the device. **Accessibility** Accessibility is the friction required to onboard a human into the system. This is determined almost entirely by what device is needed at the point of authentication. If verification requires proprietary hardware every time a user authenticates, adoption is capped by device distribution. Mercle's approach is to use the specialized device only once at initial enrollment. From that enrollment data, Mercle trains a lightweight uniqueness model that runs on a standard phone camera. After the first visit, any subsequent verification happens on the device the user already has in their pocket. One enrollment, then frictionless access everywhere. **Cost** Cost is what it takes to deliver a single verification to any application. In a system that depends on proprietary data collection, this is primarily driven by two things: the cost of the capture device and the cost of operating enrollment locations. Mercle's approach is to keep device costs low through vision systems based on RGB and commodity depth sensors rather than custom-engineered optics, and to deploy these devices at existing public retail locations rather than building dedicated infrastructure. This means Mercle does not need to lease space, staff locations, or build a physical network from scratch. The operational cost per enrollment drops as density increases. **The Flywheel** These three problems are not solved independently. They form a system. The low-cost device generates high-entropy enrollment data. That data trains the RGB-only model that enables phone-based verification. Phone-based verification removes friction, which drives platform adoption. Platform adoption funds further device deployment. Each layer makes the others stronger, and the full loop becomes harder to replicate over time.