Architecture & security

Who controls what

The Solbound site is a statically exported Next.js App Router application. The guides ship as readable HTML. The My Links workspace runs in the browser, discovers compatible Solana wallets and talks directly to devnet over HTTPS. The contact form sends messages through a separate server endpoint. Each participating website runs its own server to verify a delegate and decide who can use its protected routes.

1. Vault walletSigns a grant in My Links
2. Devnet registryStores the public permission
3. Partner serverChecks a signed-in delegate

A vault signs a public statement that an everyday wallet may represent it for holder verification. A participating app decides which benefit to offer and checks whether the vault qualifies. The vault can go offline after creating the grant.

• Vault and delegate. The vault authorizes changes to its grants. The delegate can sign in as itself. Anyone can read the link between the two addresses on devnet, including after revocation through transaction history.
• Registry. Its three instructions write or close permission records. The program calls the Solana System Program to fund and allocate those records. Its interface has no token account, token approval, asset-transfer instruction or arbitrary program call. The vault pays network fees and any required record deposits.
• My Links and the wallet. The browser prepares the transaction. The connected wallet controls the signing key. The owner relies on the site, wallet software and wallet display to present the intended program, accounts and transaction.
• Partner and RPC. The partner controls its protected service, verifies the delegate and reads finalized Solana state through its chosen RPC. A grant has effect only where an app integrates these checks. The reference verifier trusts the RPC’s account data and the partner server’s clock.

On-chain registry source · Partner server source

Devnet program and release fingerprint

Program address

FX2zKgkTSrmUpQcfNsrahQN7Mer5gfPo6Ec8FLX3SuaR

Devnet genesis hash

EtWTRABZaYq6iMfeYKouRu166VU2xqa1wcaWoxPkrZBG

SHA-256 of the 9,216-byte executable

9fdcd1f09c0910a6318eb8f5fd9f963a622d4453987d8c815da9466cc17163f1

The reference client checks the genesis hash, the executable’s owner and type, and its link to the canonical ProgramData account under Solana’s upgradeable loader. It hashes the executable bytes after the 45-byte ProgramData header and requires the fingerprint above. A reviewer can repeat these read-only checks against a separately chosen HTTPS devnet RPC and compare a local rebuild of the source.

The November 9, 2026 deployment is upgradeable. The upgrade authority can replace the code at this address. The digest check describes the bytes seen at the time of the read. The check and transaction execution are separate operations. Each integration must pin its intended program address as well as its digest. Inspect the devnet program and authority · Deployment checks · Build recipe

What a grant covers

Every grant names a vault, delegate, audience, asset scope and expiry. Wallet-wide grants cover current and future supported holdings. An asset grant names one address. A collection grant names a collection mint and requires an integration to verify the membership of the particular NFT. Creating a grant records the vault’s choice. Asset ownership is checked when the partner grants access.

The audience is either one canonical HTTPS origin, such as https://gallery.example, or the literal urn:solmate:delegation:all-apps:v1. This identifier predates the Solbound name. Keeping its exact bytes lets integrating apps recognize existing grants and new all-apps grants. A website-specific grant covers that origin, including its different page paths. A partner always binds its sign-in challenge to its own origin.

Wallet and single-asset grants hash the UTF-8 audience string with SHA-256. A collection grant hashes urn:solmate:verified-collection:v1: followed immediately by the audience string. The different hash distinguishes a collection permission from a single-asset permission even when both reference the same mint. Audience normalization · Scope encoding

Addresses and binary interface

Both account types use canonical program-derived addresses (PDAs) under the registry program. Seeds below are listed in order. Use the canonical bump returned by findProgramAddress. Public keys and audience digests are raw 32-byte values, scope is one byte, and every multibyte integer is little-endian.

• Vault state seeds. UTF-8 vault, then the vault public key.
• Grant seeds. UTF-8 grant, vault public key, delegate public key, audience digest, scope byte, asset address. Scope 0 uses 32 zero bytes for the asset. Scope 1 uses a nonzero address.

Account data

Offsets below start at zero. The vault epoch is an unsigned counter shared by that vault’s grants.

• Vault state, 41 bytes. Tag 1 at 0, vault at 1, epoch (u64) at 33.
• Grant, 146 bytes. Tag 2 at 0, vault at 1, delegate at 33, audience digest at 65, scope at 97, asset at 98, copied epoch (u64) at 130, Unix expiry in seconds (i64) at 138.

Instructions and accounts, in order

1. Create or renew, opcode 0. Payload length is 106 bytes. Opcode at 0, scope at 1, delegate at 2, audience digest at 34, asset at 66, expiry at 98. Accounts are the signing writable vault, writable vault state, writable grant, and read-only System Program. The on-chain clock requires a future expiry within 366 days.
2. Revoke one, opcode 1. Payload is one byte. Accounts are the signing writable vault and writable grant. The program verifies the grant’s owner fields and canonical address, refunds its lamports to the vault and closes it.
3. Revoke all, opcode 2. Payload is one byte. Accounts are the signing vault and writable vault state. The instruction increments the vault epoch. A fee-paying vault is also writable in the containing transaction.

All three instructions require a signing vault with an empty, non-executable, System-owned account. Renewal of the same grant address stores the current epoch and new expiry. Instruction implementation · JavaScript encoder and decoder

From review to a finalized grant

1. The vault connects a wallet that can sign transactions. My Links validates the delegate, scope, audience and expiry against the finalized chain clock, derives the record addresses and quotes the network fee and maximum record deposit.
2. The client builds a transaction with two explicit compute-budget instructions and one registry instruction. It simulates the message and keeps a copy of its bytes with the owner’s review. The vault signs that transaction. Changes to the wallet account invalidate the session.
3. Before submission, the client checks that the wallet returned the same message bytes and that the signatures verify. It sends with preflight enabled and waits for finalization. If confirmation is interrupted after submission, check the returned transaction signature before retrying.

The sample wallet keeps its grants in browser storage and produces no chain receipt. A partner checking devnet cannot recognize those sample grants. Review and submission · Wallet connection · Transaction assembly and signature checks

How a partner grants access

The downloadable @solbound-io/sdk binds a website origin and access rule to fresh server-side verification. An existing authenticated wallet session can call solbound.verify for each private request. Websites using the packaged sign-in routes can call gate.protect before serving a benefit. Its default sessions and one-time challenges live in one process. Multi-instance deployments need shared expiring storage with atomic consumption or an existing verified session system.

The setup dashboard compares the public SDK report with the configured rule and devnet program. The report includes network and deployment checks. Testing a signed-in wallet before and after revocation separately establishes that the website actually enforces its policy. Website setup and access checks

The SDK is an unaudited devnet preview. The release brief describes the scope, source fingerprints and reproducibility steps for independent reviewers. SDK review brief

1. Authenticate the everyday wallet. The server binds a random nonce, delegate, origin and three-minute expiry to the browser session. The delegate signs the exact UTF-8 message. The server verifies the Ed25519 signature and atomically consumes the challenge. The reference server then issues a five-minute HttpOnly session cookie.
2. Look up the permission. The partner uses the authenticated delegate and its own configured origin and holder rule. Discovery supplies candidate vaults and assets. The verifier derives the expected PDAs for the partner-specific and all-app audiences, validates the accounts and requires an active grant in the current vault epoch.
3. Check current holdings. A wallet-link rule needs a wallet-wide grant. For an exact NFT, the verifier checks an initialized classic SPL mint with supply one and zero decimals, and an account holding one unit for the vault. A collection rule also requires canonical Metaplex Token Metadata with a supported non-fungible standard and a verified link to the configured collection. A balance rule sums distinct qualifying classic SPL token accounts in base units.
4. Decide on the server. The final decision reads the vault state, candidate grants, Clock and required asset accounts together at one finalized slot. The verifier requires chain time strictly before expiry and within 90 seconds of the server clock. The example checks each protected request, withholds content on denial or RPC failure, and marks responses private and uncached.

A delegate address proves who signed in. The eligible vault is returned separately. Each integrating app must enforce its own rule on protected actions. The example stores sessions and challenges in one process. A deployment with several processes needs shared expiring sessions and atomic one-time challenge consumption. Verifier and holder rules · Protected route and session handling

Revocation and independent recovery

Closing one grant releases its deposit. Another matching grant, such as a wallet-wide grant, can still authorize access. Revoke all increments a persistent vault counter, invalidating every earlier grant from that vault at once. Those records remain on chain until the owner closes them individually to recover their deposits. The vault-state deposit remains locked. A later, explicitly signed renewal can activate a grant in the new epoch.

Open My Links to review and revoke grants. If the site is unavailable, run the recovery client from a trusted checkout. List grants with your public vault address and the program address above. Add --grant <grant-address> to review one revocation or --all to review a bulk revocation.

node tools/revoke.mjs --program FX2zKgkTSrmUpQcfNsrahQN7Mer5gfPo6Ec8FLX3SuaR --vault <vault-address>

The review prints the fee and unsigned transaction. Sign a decoded transaction with a compatible wallet before its blockhash expires. The CLI also supports an existing local devnet file signer with --keypair, --execute and interactive confirmation. Keep hardware-wallet keys on the device. After finalization, repeat the partner check. Independent recovery client

Test evidence and review limits

Download the review source and compiled program or inspect the SHA-256 file manifest. The bundle preserves the paths used by the tests and recovery client. It includes the transaction-building client, program, verifier, test sources and locked package versions.

Extract the archive into an empty folder. With Node 24, run npm ci and npm test there. Run npm run build to generate the static website in out/. For a local program rebuild and validator checks, follow the protocol build and test instructions. Compare the output digest to the devnet fingerprint above.

• Program. The offline validator harness deploys the compiled executable, compares the loader’s stored bytes and sends signed transactions to exercise scope, expiry bounds, signer checks, renewal, refunds and both revocations. The public devnet deployment also has finalized receipts. Validator tests · Grant receipt · Revocation receipt
• Client and partner. Run npm test from the project root with dependencies installed. The tests use fixtures and test wallets for audience isolation, account decoding, ownership changes, expiry, stale state, modified wallet messages and one-time sign-in. HTTP tests exercise each partner rule with a controlled eligibility result. Client and verifier tests · Wallet signing tests · HTTP gate tests
• Coverage. Core assets, compressed NFTs and Token-2022 need additional ownership adapters. Automatic lookup considers up to 40 records per audience filter, two vaults to search for collection holdings and six candidates. Holders can specify a vault and, for collections, a candidate mint. Balance checks consider up to 90 distinct token accounts, so unusually fragmented holdings may fail the threshold.
• Assurance. This is an unaudited devnet release. Independent security review, physical hardware-wallet coverage and acceptance testing by each adopting partner remain open.