Gaming economies suffer when smurfs, bots, and farming rings can create fresh identities faster than your game can build trust. Cubid 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. Cubid 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 Cubid, 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. Cubid 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. Cubid 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. Cubid 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. Cubid 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. Cubid 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. Cubid 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. Cubid 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.

Cubid 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.

Cubid 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.

• @cubid/core: the runtime-agnostic client for your server, worker or edge function.
• @cubid/browser: headless browser flow helpers, without a React dependency.
• @cubid/react: React components and hooks on top of the browser layer.

# Server client
npm install @cubid/core@0.3.0

# Optional: choose the UI layer your app needs
npm install @cubid/browser@0.2.1
# or
npm install @cubid/react@0.1.3

These packages are published on npm. The older @iah/sdk example has been retired; the @iah/* quickstart helpers are unpublished and are not substitutes for these packages.

Initialize the client with the backend origin and app credentials approved for your integration. Supply the origin, not an origin with /api/v2 appended; the SDK adds its route. After resolving the user through your supported flow, use its app-scoped Cubid ID, not an arbitrary email, internal person ID or interchangeable OIDC subject.

import { createCubidApiClient } from "@cubid/core";

const cubid = createCubidApiClient({
  baseUrl: process.env.CUBID_API_BASE_URL,
  apiKey: process.env.CUBID_API_KEY,
  dappId: process.env.CUBID_DAPP_ID,
});

const result = await cubid.fetchScore({
  userId: appScopedCubidUserId,
});
// Check errors and disclosure limits before applying
// your application's authorization policy.

This is a server-side read example, not a complete login or authorization flow. fetchScore returns cubidScore, scoringSchema, error and raw; it does not return an access verdict.

Follow the documented browser or React flow for the UI you are building. Sign in with Cubid uses a separate auth package and provider contract; installing an SDK does not activate federation or link existing accounts automatically.

The IAH hosted-redirect quickstart uses different verification methods and event shapes. Do not rename its imports and assume it becomes a Cubid integration. Validate the exact package, backend route and webhook contract you intend to use.

Write down what you want to improve: fewer duplicate claims, more confidence in a vote, or fairer access to a benefit. Request the least evidence needed for that action, rather than collecting every available signal.

An illustrative app policy might allow basic browsing with little evidence, require more proof for a valuable claim, and offer review when evidence is incomplete. These are choices your app implements, not an automatic Cubid allow/limit/review state machine or a guarantee of one person per account.

Scoring aggregates the evidence disclosed to your app under a scoring schema. Use cubidScore together with scoringSchema and the request’s error state. Keep the same documented route and schema when comparing outcomes; legacy and v2 score routes can produce different totals.

Missing stamps or a low or zero score can reflect selective-disclosure limits, not fraud. A genuine numeric zero is valid; a failed request or an absent raw score is not zero. Check errors and the raw numeric score, because legacy SDK normalization can return zero when the field is missing. Current v2 identity, stamp and score responses do not always distinguish “no disclosure grant” from “no data.” Do not invent that distinction or silently treat either as abuse.

Keep authentication, evidence disclosure and authorization separate: a successful sign-in does not by itself satisfy the policy for every protected action.

For an app and verification page you are authorized to manage, inspect its available stamp types, required information and sharing settings. Catalog visibility is not proof that a signal can be used for authentication or scoring. A verified contact requirement is not proof of unique humanity; an address is profile information, not a personhood shortcut.

Inspect the scoring schema supported by your integration. There is no public SDK slider for arbitrary signal weights. Check the route you consume: legacy score routes do not uniformly honor a page’s Score setting, so a checkbox alone is not evidence that a particular score changed.

Keep your app’s thresholds and escalation rules in your own reviewed server policy. Test them against the actual disclosed result instead of copying a universal score cutoff.

• Greylisted: a credential is associated with distinct Cubid account families.
• Blacklisted: duplicate records exist within the calling app.

These flags do not prove fraud or identify another person’s account. Do not apply one flagged credential to every unrelated email or app. Where an account-merge handoff is available, guide the user through it and refresh status afterward; do not promise that merging clears every flag.

Bind the returned app-scoped identity to your own authenticated session, validate callback state for the flow you use, and check authorization on the server before granting a benefit. Never trust a redirect parameter or a client-side score alone.

Handle transport failures separately from privacy-limited results. If your integration uses webhooks, verify the exact runtime’s signature and event contract, deduplicate deliveries and refresh your stored evidence before reevaluating access. The IAH scaffold’s verification events are not interchangeable with Cubid score or stamp events.

Keep secrets and raw identity payloads out of browser bundles and routine logs. Store only the evidence and decision records your product needs, with a clear retention policy.

Before a pilot, test your own expected decisions with safe fixtures:

• Minimum required evidence succeeds; stronger evidence unlocks only the intended benefit.
• Missing or declined disclosure has an explicit path, without being labelled fraud.
• Zero-weight or disabled signals, flagged credentials and changed policy produce the expected result.
• Expired callbacks, failed requests and repeated webhooks cannot accidentally grant access.
• A signed-in user can still be denied a protected action by your app’s policy.

Start with a small pilot. Track completion, abandonment, support requests, abuse outcomes and benefit uptake using minimal data. Review who is excluded as well as who passes; change one policy assumption at a time and retest before expanding.

SDK installation and a passing demo do not certify hosted readiness. Confirm your exact backend, consent, callback and event contracts before production. Additional app provisioning and the new multi-app dashboard remain in development.

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. Cubid 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, Cubid 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.

Human Passport, formerly Gitcoin Passport, is similar at the signal layer: users collect attestations from many sources and those stamps become useful proof material. Its standard output is a minted credential or NFT with a pre-calculated score that other apps can ingest.

The standard Cubid scenario is different. Cubid uses those signals to let a user selectively share identity facts with an app. A product can learn that someone is over 18 without seeing their birthdate, or that they are a citizen of a country without receiving their address.

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

Cubid gives web app developers a focused way to verify users, launch hosted proof flows, check verification status, and receive webhooks. I Am Human app is the human-facing part of this wider ecosystem. Cubid also provides: Passport, Admin, OIDC, app-scoped disclosure, policy, custody, chain integrations, and canonical SDK behavior.

Teams can start with human verification and use more of Cubid's identity, protocol, or custody capabilities as their needs grow. I Am Human app gives people their own entry into the ecosystem.

Compared with the proof-of-humanity apps above, Cubid also layers in adjacent account infrastructure such as Sign in with Cubid, passkey assurance, secure wallet recovery, custody flows, and app-scoped identity sharing.

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.