npm is where your package is published. This is where it has a public identity: who publishes it, what they have released, and a proof that links the two.
search the registry and import the one you publish.
official oauth. Read-only, and revocable from your GitHub settings.
we check your permission on the repository the package declares.
publish a version carrying a string we issue, or let npm's attestation speak.
sign a message to prove the key is yours. Optional, and nothing moves.
a deterministic devnet address holding the verified release record.
The repository field in a package.json is written by
whoever publishes the package, and the npm registry does not check it.
Two different people can publish two different packages both pointing
at the same repository. So owning a repository cannot be treated as
permission to publish a package, and here it is not.
With your own GitHub token we read one thing: whether you can push to the repository the package declares. A push, maintain or admin permission passes. If GitHub does not return a permission block for the scopes you granted, the answer is recorded as unknown rather than as a no.
When a package is published from a CI workflow through npm's trusted-publisher flow, npm publishes a signed provenance statement naming the repository the tarball was built from. We compare GitHub's immutable numeric repository id, not the name, because a repository can be renamed and its old name claimed by someone else. A match means the registry itself vouches for the link.
The route that needs no repository at all. We issue a one-time
string; you add it to your package.json and publish a version. Only
an account that can run npm publish for that package
can put a string into one of its published versions, so finding it
there proves publish authority outright.
We also check whether an npm maintainer's email matches a verified email on your GitHub account. It is shown because it is useful context, and it is labelled "signal only" everywhere it appears: a maintainer email is public on the registry, so matching it proves only that the same address is on both accounts. It never contributes to a verified status.
A package is verified when the publish proof passes, or when repository control and npm's build attestation both pass. Repository control on its own yields "repo linked". Nothing else reaches verified, and no combination of signals substitutes for a proof.
Connecting a Solana wallet is optional and proves one thing: that the key is yours. You sign a short message this server generated, containing a single-use nonce. Nothing is sent, no funds move, and we never hold your keys.
the server issues the exact message, your wallet signs it, and the signature is checked against your public key. A message we did not issue is rejected.
you keep your keys. There is no deposit step anywhere in this product, nothing to approve, and no token of any kind.
the identity program is not deployed yet.
An account at an address derived from the package name, so it is the same address for everyone and can be shown before it exists. It records the verified publisher, the repository that was proved, and a hash of each release: the package name, the version and the publish time, which anyone can recompute. A published version cannot change, so those records are written once and never rewritten.