Anchor PDA

Each wallet can have one Entros Anchor PDA on Solana. The Anchor combines a non-transferable Token-2022 token with an IdentityState account that stores score, commitment, and verification metadata. Population-level uniqueness remains an active protocol objective.

Program identity

The entros-anchor program owns the Anchor state. It is deployed on devnet at:

GZYwTp2ozeuRA5Gof9vs4ya961aANcJBdUzB7LN6q4b2

PDA derivation

The IdentityState PDA is derived from two seeds: the literal identity and the user's wallet:

const [identityState] = PublicKey.findProgramAddressSync(
  [Buffer.from("identity"), wallet.toBuffer()],
  ENTROS_ANCHOR_PROGRAM_ID,
);

The associated mint PDA, which holds the non-transferable token, is derived from the seed mint plus the wallet:

const [mint] = PublicKey.findProgramAddressSync(
  [Buffer.from("mint"), wallet.toBuffer()],
  ENTROS_ANCHOR_PROGRAM_ID,
);

IdentityState layout

The account stores ownership, score, fingerprint commitments, and verification metadata. The Trust Score lives at offset 60 as a little-endian u16. For a one-line read of just the score, see the quickstart.

Field	Type	Offset	Purpose
Anchor discriminator	`u64`	0	Account-type tag
`owner`	`Pubkey`	8	Wallet that owns the Anchor
`creation_timestamp`	`i64`	40	Unix timestamp of first verification
`last_verification_timestamp`	`i64`	48	Unix timestamp of most recent verification
`verification_count`	`u32`	56	Successful re-verifications since the latest identity reset
`trust_score`	`u16`	60	Current Trust Score
`current_commitment`	`[u8; 32]`	62	Latest behavioral fingerprint commitment
`mint`	`Pubkey`	94	Address of the Anchor's Token-2022 mint
`bump`	`u8`	126	PDA bump seed
`recent_timestamps`	`[i64; 52]`	127	Rolling window of recent verification timestamps used by the score formula
`last_reset_timestamp`	`i64`	543	Unix timestamp of the most recent `reset_identity_state`
`new_wallet`	`Pubkey`	551	Authorized successor wallet for `migrate_identity`; zero when no migration has been authorized
`projection_version`	`u16`	583	Feature-projection version the stored commitment was produced under
`last_rebaseline_timestamp`	`i64`	585	Unix timestamp of the most recent `rebaseline_anchor`

Field offsets are documented for direct deserialization. For typed access from a Rust client, the canonical IDL is published with the entros-anchor program.

Token-2022 identity NFT

The Anchor mint uses the Token-2022 NonTransferable, MintCloseAuthority, MetadataPointer and TokenMetadata extensions. It is a one-supply, zero-decimal token held in the user's associated token account. There is no transfer hook and no royalty extension. The mint exists to make the Anchor visible in any Token-2022-aware wallet UI; the authoritative score and metadata live in IdentityState. MintCloseAuthority is held by the program so that migrate_identity can close the old mint when an identity moves to a new wallet.

Instructions

The entros-anchor program exposes the following identity instructions.

mint_anchor - Initializes a new Anchor after an enforced validator-signed receipt. Charges the protocol fee.
update_anchor - Re-verifies an Anchor. It checks the proof, updates the commitment, recalculates the score, and charges the fee.
reset_identity_state - Replaces an unusable baseline after a seven-day cooldown. It clears the score and verification history.
authorize_new_wallet - Records a successor wallet and delegates the identity token before migration.
migrate_identity - Moves the score and verification history to the authorized wallet. It closes the old mint.
set_encrypted_baseline - Stores the wallet-encrypted baseline blob.
rebaseline_anchor - Moves the Anchor to a new projection version after a validator-signed receipt.

No Entros Anchor program is deployed on mainnet today. Mainnet deployment remains gated on hardening, a new ceremony, and external audit.

Reading the Anchor

Use one of these patterns:

Context	Pattern
React component	`EntrosGate` or `EntrosBadge`
Server / edge function	Direct `getAccountInfo` on the PDA
Anchor program	Cross-program account constraint with `seeds = [b"identity", wallet.key().as_ref()]`

All three read the same canonical state.

Where to look next

Programs reference - instruction signatures and account constraints
PDAs reference - seeds and derivations
Threat model - current protections and open boundaries