> ## Documentation Index
> Fetch the complete documentation index at: https://docs.array.network/llms.txt
> Use this file to discover all available pages before exploring further.
# Build on Array
> Public preview guide for relying parties integrating Sign in with Alive. What you can verify today, and what isn't here yet.
**Maturity:** Limited preview, in active development. The surface documented
here is built and tested end to end, and published as release candidates
(`0.x-rc`), but wire shapes can still change. Pin exact versions.
Access is granted per team rather than self-serve: packages are on a private
registry, and your application record is created by us. Everything runs on
testnets, with no production environment stood up. Do not gate real value on
it yet.
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](/build/glossary) 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.
```mermaid theme={null}
sequenceDiagram
autonumber
participant U as User
participant IDP as Identity provider
participant RP as Your application
U->>IDP: authenticates here
IDP-->>RP: assertion, signed by the provider
Note over IDP: sees every login,
and you trust its word
```
Under Array the device signs for itself, and the only thing you trust is a key
you pinned yourself.
```mermaid theme={null}
sequenceDiagram
autonumber
participant A as Array
participant U as User's device
participant RP as Your application
A--)RP: signed roots, polled in the background
U->>RP: login token and membership proof,
signed by the user's own key
Note over RP: verified locally against a pinned root.
Array is not called, and is never
told the login happened
```
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](/build/capability-grants) 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
Register your application, generate a presenter key, install the packages.
A working sign-in. Sign the request, render it, verify the response.
## 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](https://github.com/vibechecklabs) or reach your contact on
the team. Send the package version, the call you made, and the error `code`.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.