Gaming economies suffer when smurfs, bots, and farming rings can create fresh identities faster than your game can build trust. IAH gives studios a way to start every player with a light allowance and progressively unlock ranked ladders, withdrawals, tournaments, or quest rewards as proof signals strengthen.

• Gate ranked or tokenized modes behind stronger personhood thresholds.
• Let casual onboarding stay lightweight for real players.
• Use different thresholds for chat, rewards, and competition.

Token balances and wallet counts do not tell you whether the same operator controls fifty votes. IAH lets communities layer personhood checks on top of onchain governance so "one member, one meaningful voice" becomes enforceable without requiring full KYC for every participant.

• Run binary human-gates for elections and grants.
• Require stronger signals only for high-stakes ballots.
• Use whitelists and grey lists for fraud review before counting votes.

If your free tier is only protected by email, your real pricing model is "how many aliases can someone create." With IAH, apps can start everyone with a little, then unlock more messages, generations, credits, or API calls as users present stronger personhood signals.

• Stop repeated free-tier drains from recycled inboxes.
• Reward stronger users instead of punishing everyone equally.
• Collect useful trust context without jumping straight to KYC.

Airdrop mechanics attract swarms of throwaway accounts. IAH helps projects shape eligibility around composite human scores rather than a single brittle proof source, so distribution can stay open while the cost of sybil behavior rises sharply.

• Require one or several proof sources instead of just wallet age.
• Use cumulative scoring for higher-value reward tiers.
• Escalate to stronger proof only for suspicious clusters.

Microlending breaks when the same actor can default, re-register, and repeat. IAH lets lenders calibrate risk tiers around signal quality so smaller first loans remain accessible while abuse patterns trigger additional review or stronger verification.

• Start with low-value issuance for weak signals.
• Increase limits for users with more durable personhood evidence.
• Route suspicious overlaps into manual or KYC review.

Educational programs, quest systems, and other earned-reward products need reach, but reach alone invites abuse. IAH lets operators make completion rewards depend on progressively stronger trust signals, not just click-through behavior.

• Unlock completion rewards only after human checks clear.
• Use different thresholds for attendance, submissions, and payouts.
• Preserve simple onboarding for legitimate first-time users.

Moderation systems usually react to behavior after spam has already spread. IAH gives social products a front-door trust signal they can combine with behavioral data for rate limits, verification tiers, creator programs, or monetization access.

• Apply lower posting limits to weak or fresh identities.
• Unlock creator tools as trust rises.
• Use personhood signals to improve community safety, not just badge users.

UBI-style systems cannot tolerate one operator claiming many times. IAH helps programs mix stronger personhood protocols with lighter social and contact signals, giving operators a flexible trust threshold rather than a single all-or-nothing rule.

• Pair recurring claims with durable human signals.
• Greylist suspicious clusters before funds move.
• Maintain a documented escalation path to stronger verification.

Token sales and waitlists are especially vulnerable to sybil clustering. IAH lets projects mix region rules, proof-of-humanity signals, and selective KYC escalation so allocations become more resistant to wallet splitting and repeated registration.

• Prevent one actor from absorbing outsized retail allocation.
• Introduce selective KYC only where legal or risk thresholds require it.
• Keep the majority of the flow lightweight for legitimate participants.

GitHub, Google, X, Discord, Lens, Fractal, EVM wallet, Solana wallet, World, Farcaster, Gitcoin Passport, Humanity Passport, Instagram, phone, Telegram, GoodDollar, BrightID, and email.

These span social graph, direct contact, wallets, and personhood-native protocols so apps can mix lighter and stronger evidence in one trust model.

Stripe, PayPal, Wise, Revolut, credit card, LinkedIn, DNS, Persona, Onfido, Sumsub, Snapshot, ENS, Steam, Airbnb, Uber, Circles, Polkadot Unique ID, and Humanode.

The catalog is meant to grow with the product. If a trust source matters to your workflow, the integration surface should not have to be rebuilt from zero.

Different apps care about different failure modes. Some only need "not obviously a bot." Others need a much stronger guess that one account maps to one human. IAH is designed for this spread.

• Binary mode for fast gating.
• Threshold mode for weighted scoring.
• Escalation mode for selective KYC and manual review.

The team sits at the intersection of developer tooling, crypto identity, fraud systems, and product operations. That mix matters because proof-of-humanity is not just a protocol problem. It is a developer-experience and policy problem too.

IAH is structured to be legible to founders and usable by engineering teams, not just identity researchers.

Most proof-of-humanity tools ask products to choose one protocol and inherit its assumptions. Real products usually need a more adaptive model: multiple signals, risk-specific thresholds, and the ability to escalate only when it is worth the friction.

IAH began as that missing layer: not another standalone proof system, but a meta-protocol for working with many of them.

We map what is being abused, what the unit economics are, and which actions really need stronger proof. That usually reveals where lightweight signals are enough and where escalation needs to exist from day one.

Most teams begin with one or two product surfaces: signup, reward claim, withdrawals, or free-tier expansion. That keeps the signal model legible and lets the team tune thresholds with evidence instead of intuition.

Once the pilot is stable, teams usually add more signals, formal whitelisting and greylisting rules, and stronger audit trails for support and compliance-sensitive decisions.

npm install @iah/sdk

import { IAHSDK, configureIAHSDK } from "@iah/sdk";

configureIAHSDK({
  baseUrl: "https://passport.cubid.me/api/v2",
  apiRootUrl: "https://passport.cubid.me/api",
  walletConnectProjectId: "your_project_id",
});

const iah = new IAHSDK("dapp_id", "api_key");

Major tuning surfaces include backend URLs, provider project IDs, created-by app IDs, wallet settings, and the thresholds or escalations your application applies to returned scores.

• Keep defaults if you are using the shared backend as-is.
• Override provider settings if your app needs its own project IDs.
• Keep policy outside the SDK where possible so thresholds stay editable.

Teams typically expose three modes in product logic: a low-friction human gate, a richer cumulative score, and an escalation path for cases where regulation or fraud severity justifies stronger proof.

The algorithm should be read as a cost shaper. Weak identities get less access, more scrutiny, or smaller limits. Stronger identities unlock more of the product. Suspicious overlaps are slowed down before damage compounds.

• Whitelist: strong signals or operator-approved identities with broader access.
• Greylist: conflicting or incomplete signals that need more proof or manual review.
• Blacklist: repeated abuse, duplicate behavior, or explicit operator blocks.

Most systems fail when they collapse everything into allow or deny. The grey zone is where operational intelligence lives.

The system may collect connected social, wallet, or contact proofs, metadata needed to verify them, and operational evidence tied to scoring or review. The goal is to store what is necessary to support the chosen trust model, not everything that could be asked.

Apps should be able to request a score, a threshold result, or a category of trust instead of full raw identity by default. That keeps the data surface smaller and makes proportionality possible.

Users should be able to decide whether they want to stay at a lighter trust tier or connect stronger evidence for more access. That makes trust a negotiable product surface instead of a hidden extraction mechanism.

Good policy matches proof strength to risk. Low-value actions can often run on lighter signals. High-value payouts, regulated flows, or governance-critical actions may justify stronger requests.

Humanode offers one proof path with its own assumptions and strengths. IAH is useful when a product wants to work with Humanode-like signals alongside other sources and tune policy at the application layer.

If a product loves Idena, it can use it. If it also needs social, wallet, or regulated verification inputs, IAH provides the surface for combining those without rebuilding the trust stack.

Products rarely stop needing policy once proof is available. They still need thresholds, escalation, allowlists, reviews, and the ability to compare multiple sources over time.

Single-protocol strategies are clean until your product needs a different region rule, trust tier, or fallback source. IAH is designed so your product policy can evolve without a full rewrite.

The studio kept casual play open, but tied tournament rewards and rare drops to a blended score using wallets, social accounts, and personhood protocols. Reward abuse dropped while onboarding stayed soft for new players.

Rather than rejecting suspicious voters outright, the community routed them into a review lane. That cut false-positive anger and still prevented obvious duplicate clusters from affecting the vote.

Anonymous users received a tiny free quota. Users with stronger proof got larger trial pools and faster queues. Credit leakage dropped, and the team learned which trust signals actually mapped to long-term paid conversion.