Build on Array

Array verifies that someone is a real person, distinct from other real persons, without revealing who they are. The proof comes from the network effects of scaled physical co-presence, meaning two people with two phones in the same room, rather than from biometrics or know-your-customer checks. This guide covers one integration path. A user signs in from the Alive app, and your server verifies what their device signed. If a name or a term here is unfamiliar, Terms defines them in one page.

​

What you can build with it

The common thread is a gate that counts people instead of accounts. Each of these runs off the same sign-in and network membership proof.

• Token airdrops and claims. One allocation per real person. Deduplicate on the pseudonym the verifier hands back and someone holding a hundred wallets still gets one.
• Gated access. Private betas, community spaces and allowlists where the gate is network membership rather than a token balance or an invite code.
• Rate limits that count people. Per-person quotas on a free tier, where signing up again does not reset the counter.
• Anonymous participation that still has consequences. Votes, reviews and ratings. Pairwise mode gives you a stable pseudonym, so you can enforce one per person and ban an abuser without ever learning who anyone is.

The pseudonym is scoped to your application, so two services cannot pool what they each know about the same person.

​

How it works

Array does not authenticate your users. The device asserts, and your server verifies. That is the opposite of an ordinary federated login, where a provider authenticates the user and vouches for them to you.

Diagram: the same login, both ways round

Under Array the device signs for itself, and the only thing you trust is a key you pinned yourself.

Your backend issues a single-use nonce and signs a sign-in request. Your page renders it as a QR code or a deep link. The Alive app looks your application up in Array’s public client directory, shows a consent sheet naming you, and on approval mints a login token using the user’s own on-device key. Your server then verifies that token offline. No call to Array sits in the trust path, and Array is never told the login happened. One consequence is worth understanding before you start: verification has to happen on a server you control. A verdict computed in a browser is a verdict an attacker controls, so a single-page application with no backend cannot complete a sign-in.

​

What you can do today

Authenticate a user in one of two subject modes. Disclosed mode gives you their global AliveID (aka ArrayID). Pairwise mode gives you a per-application pseudonym that is stable for you and uncorrelatable anywhere else. Prove the user is an admitted [ ] network member, distinct from every other member. A sign-in request can ask for a zero-knowledge membership proof. Verified against an operator-signed Merkle root that your server pins, it returns the membership_proven verdict and a unique flag. That is the only tier carrying a sybil guarantee, and it is the reason to integrate Array rather than any other sign-in. Ask Array about a signed-in user, with their permission. A capability grant authorises your application to ask specific questions about that person, such as whether they are connected to someone else. The capability set is agreed per integration.

​

What isn’t here yet

• No public npm distribution. Packages are on a private registry, with access granted per team.
• Proving artifacts come from a development ceremony. Deployed verifiers carry DEVELOPMENT_ONLY provenance, so proofs have no cryptographic soundness guarantee until a production trusted setup runs. Use preview environments only, and do not gate real value on this yet.
• On-chain verification is not documented here either. A contract can check a membership proof directly against roots posted on-chain, which suits an airdrop claimed by transaction rather than gated by your backend. It is built and testnet-only.
• Asking Array about arbitrary people is not supported and will not be. A partner machine key (M2M Key) on its own resolves no person. Every question about a subject requires that subject’s authorization.

​

Next

​

Reference implementation

There is a complete, working web relying party, and we share it on request. It covers the whole flow against a local stack: signing the request, rendering the QR, the consent sheet on the phone, offline verification, and the verdict. It goes further than this guide does, into capability grants and on-chain claims, so it doubles as a preview of what lands next. It also ships a headless device simulator, which means you can drive a sign-in end to end without a phone in the loop. Useful for a first read, and for tests. Ask your contact on the team.

​

Feedback

This is a preview, so the feedback loop is the product. File issues against the GitHub org or reach your contact on the team. Send the package version, the call you made, and the error code.