omnid-primary-sources-2026-05-10

Omnid primary-source snapshot

Fetched: 2026-05-10 UTC

1) Official essay / project framing

Source: https://omnid.io/essay/what-we-are-building

Selected excerpts from the official site:

We’re building a system—not a startup, not a social network—that starts from that need.

A mobile app that rethinks identity—not based on usernames, but on shared reality.

You prove your humanity through contact with other people in the real world

You build trust by doing things with others—not by optimizing your profile

Additional signals from the source:

• The marketing essay is more philosophical than technical, but it is still useful because it frames Omnid around contribution, trust, and real-world contact rather than around a single credential format.
• The most important mechanism hint in this essay is that identity is supposed to emerge from shared reality and real-world connection, not only from wallet possession or a static profile.
• This page is not enough on its own to understand the system, but it helps explain why the later docs mix social recovery, people discovery, reputation scoring, and anonymous proofs.

2) Official docs overview

Source: https://raw.githubusercontent.com/anudit/omniddocs/main/content/protocol/index.mdx

Selected excerpts from the docs repo:

Learn how Omnid leverages ZK Proofs for anonymous coordination.

Learn how Omnid handles user authentication.

Learn how Omnid operates on & communicates using multiple chains.

Learn how Omnid facilitates real world trust graphs using Connections.

Additional signals from the source:

• The overview page is useful because it shows the intended module boundaries: ZK proofs, authentication, cross-chain messaging, encryption, vault, proxy RPC, function cloud, connections, and AI.
• Omnid is therefore best treated as a stack of identity-and-coordination modules, not merely a score API or wallet-login product.
• The explicit presence of both Connections and Proxy RPC on the same overview page suggests Omnid is trying to bridge social trust inputs with transaction/privacy middleware.

3) Authentication model

Source: https://raw.githubusercontent.com/anudit/omniddocs/main/content/protocol/authentication.mdx

Selected excerpts from the docs repo:

This allows you get the public profile of user like their Ethereum Address, Humaness Metrics etc. Compatible with SIWE Standard.

This allows you get the ZK Commitment of user to access the various attributes of their persona.

You can request specific data items linked to the user from the vault only if the user permits.

Additional signals from the source:

• The docs split authentication into three layers: public profile access, private ZK attributes, and permissioned vault data.
• That split is analytically important because Omnid is not presenting identity as one flat object; it is separating public legibility from private commitments and consent-gated data retrieval.
• The phrase Humaness Metrics is especially revealing: Omnid wants to expose not just identifiers but some notion of humanity / trustworthiness through the public profile path.

4) ZK proof layer

Source: https://raw.githubusercontent.com/anudit/omniddocs/main/content/protocol/zk-proofs.mdx

Selected excerpts from the docs repo:

Semaphore helps you do this.

Your secret ID is added to a special tree (Merkle Tree) that keeps track of all the club members.

You can then show this proof to the club to prove you’re a member, without telling them your real identity.

Additional signals from the source:

• Omnid explicitly leans on Semaphore-style anonymous group-membership proofs rather than inventing its own brand-new privacy primitive in the docs.
• This makes Omnid a useful comparison case for other systems that wrap existing anonymity sets and Merkle-root membership under higher-level product branding.
• The relevant control surface is therefore likely group construction, membership admission, and verifier integration, not only the zero-knowledge proof system itself.

5) Cross-chain group messaging

Source: https://raw.githubusercontent.com/anudit/omniddocs/main/content/protocol/cross-chain.mdx

Selected excerpts from the docs repo:

Manage Groups and Prove from any Chain.

Call the following functions on the forwarder contract to pass messages to the base chain GroupManager Contract.

// Directly verify proofs on the base chain.

Additional signals from the source:

• Omnid does not present anonymous proofs as single-chain local objects; it wants group proofs and group-management messages to move across chains.
• The docs make a forwarder contract and a base-chain GroupManager central to that flow, which means bridge / forwarder operation is a real trust and liveness surface.
• This is one of the stronger reasons to keep Omnid in the corpus: it mixes identity middleware with cross-chain message routing rather than leaving identity state fully local.

6) Connections / IRL trust graph surface

Source: https://raw.githubusercontent.com/anudit/omniddocs/main/content/protocol/connections.mdx

Selected excerpts from the docs repo:

What purpose do IRL connections serve

• Social Recovery
• Real World Trust Graphs
• People Discovery

Additional signals from the source:

• This is a very small page, but it is analytically dense.
• Omnid is explicitly tying real-world connection graphs to three downstream uses: account recovery, trust scoring / trust topology, and discovery.
• That makes Omnid a useful bridge case between BrightID-style social graphs, proof-of-personhood systems, and recovery / account-abstraction conversations.

7) V1 API / TrustScore layer

Source: https://raw.githubusercontent.com/anudit/omniddocs/main/content/v1/api.mdx

Selected excerpts from the docs repo:

Omnid aggregates multiple on/off-chain sources of reputation into an overall social graph where each source counts towards some points in building the overall TrustScore for any Ethereum Address.

This score is continuously evolving. As more platforms get integrated, the weights and the score will update too.

Omnid uses 0xCCcccCcC54317EE02C2dBfdD832a67C7acD28e06 as SignatureAddress to sign the oracle data.

Using a naive implementation of a Range Proof SNARK, we create a circuit to generate a proof of: whether a TrustScore is within a specific range … without revealing the original score.

Additional signals from the source:

• The API docs are the clearest statement that Omnid is a reputation oracle as well as an identity stack.
• The integration table matters because it mixes many different signal types — Aave, Boardroom, BrightID, DeepDAO, ENS, Gitcoin, Idena, Lens, POAP, Proof of Humanity, RabbitHole, RSS3, and more — into one score surface.
• The fact that Omnid signs the response as oracle data is analytically important: even if the score is derived from many public sources, final authority over the returned payload still sits with a signing key.
• The range-proof feature is a useful decomposition layer: Omnid is not only exporting a raw score, it is trying to let applications consume score predicates privately.

8) Transaction relay

Source: https://raw.githubusercontent.com/anudit/omniddocs/main/content/integration/transaction-relay.mdx

Selected excerpts from the docs repo:

Omnid’s Transaction Relay, relays Login and Membership proofs on-chain for a gasless user experience.

It focuses on transction privacy by dropping any Privately Identifiable Information like origin IP etc, uses private Mempools and super-fast transaction inclusion.

Additional signals from the source:

• Omnid is trying to own the delivery path for login and membership proofs, not just proof creation.
• This adds another practical control plane: users may depend on Omnid-operated relays and privacy claims around submission infrastructure.
• It also makes Omnid relevant to discussions about whether identity middleware quietly recentralizes around relayers even when proof formats are nominally portable.

9) Deployment surface

Source: https://raw.githubusercontent.com/anudit/omniddocs/main/content/integration/deployments.mdx

Selected excerpts from the docs repo:

GroupManager

OauthJwkRegistry

MetadataExtension

LoginVerifier

LoginApp

Additional signals from the source:

• The deployments page shows a larger contract surface than the high-level marketing language suggests.
• The stack includes verifier contracts, registries, metadata extensions, and login-specific contracts, which makes Omnid more infrastructural than a simple reputation API wrapper.
• The presence of both cryptographic verifier contracts and application-facing login components reinforces the idea that Omnid is collapsing several layers into one product family.

Notes

• Omnid is worth cataloging because it combines score aggregation, privacy-preserving proofs, social-recovery / trust-graph inputs, cross-chain verification, and relay middleware in one stack.
• The most important comparison axis is not generic identity or reputation, but how public profile scoring, private commitments, connection-graph curation, verifier / forwarder contracts, and relay infrastructure are split across different actors.
• The main caveat is that the current public materials are fragmented and partly aspirational. That said, the fragmentation still exposes a distinctive architecture that would be easy to lose if Omnid were filed only as another identity startup.