Costs
Protocol fee configuration, requested compute limits, and Solana rent examples.
Wallet transactions use the on-chain fee configuration, Solana account rent, transaction fees, and requested compute limits.
Protocol fee
The deployed config account is the source of truth. Program initialization sets a 0.005 SOL default, and the authority can update it.
| Operation | Fee | Configurable | When |
|---|---|---|---|
mint_anchor | verification_fee | ProtocolConfig | First verification for a wallet |
update_anchor | verification_fee | ProtocolConfig | Each re-verification |
reset_identity_state | verification_fee | ProtocolConfig | Recovery after the seven-day cooldown |
The two-signer migrate_identity flow reads a separate migration_fee field from ProtocolConfig. The current registry interface exposes no public setter for that field.
The fee is charged in the wallet-connected transaction that mints or updates the Anchor. The public entros.io/verify route currently offers only wallet-connected verification. A future walletless tier can provide an ephemeral result without writing Anchor state.
The fee accumulates in the Treasury PDA owned by entros-registry. A future validator network can change the economic flow only after specification, implementation, and audit.
Compute units
The dominant on-chain cost is Groth16 proof verification during re-verification. The SDK adds a ComputeBudgetProgram.setComputeUnitLimit instruction to each wallet transaction.
| Transaction | Requested CU |
|---|---|
| First verification without encrypted baseline write | 200,000 |
| First verification with encrypted baseline write | 250,000 |
| Re-verification without encrypted baseline write | 250,000 |
| Re-verification with encrypted baseline write | 300,000 |
| Baseline reset | 200,000 |
These values are configured request limits, not measured consumption. A reproducible compute benchmark remains planned before mainnet. It will record the program commits, Solana runtime, transaction shape, and observed units. The protocol can evaluate Pinocchio after those measurements identify a path that needs lower overhead.
Rent
Each new account requires rent-exempt funding. The examples below depend on the cluster rent schedule. Query the target cluster before displaying a transaction estimate.
| Account | Size | Rent | Refundable |
|---|---|---|---|
IdentityState | 593 bytes | 0.00501816 SOL | No (held while Anchor is active) |
Mint (Token-2022 with NonTransferable + MintCloseAuthority + MetadataPointer + TokenMetadata) | 415 bytes | 0.00383496 SOL | No |
| Associated Token Account (Token-2022 with ImmutableOwner) | 174 bytes | 0.00210192 SOL | No |
Challenge | 90 bytes | 0.001517 SOL | Yes, via close_challenge |
VerificationResult | 182 bytes | 0.002158 SOL | Yes, via close_verification_result |
| Agent metadata entry | Governed by Solana Agent Registry | Query the registry transaction | Immutable Entros entries remain allocated |
At the rent schedule used for this table, the three persistent first-verification accounts require about 0.01096 SOL. Add the live verification_fee and transaction fees.
A re-verification funds Challenge and VerificationResult accounts in addition to the live fee and transaction fees. Their close instructions can return rent when a client invokes them.
Economic notes
Detection decides whether a verification passes. The fee provides a secondary bound on repeated attempts. The protocol authority can update verification_fee through update_protocol_config.
Where to look next
- Concepts: Trust Score - score formula and policy guidance
- Reference: Programs - the
ProtocolConfigsurface