Owner portal.

Code notes

The agent portal lives at https://portal.nukez.xyz/agent-portal and is backed by the front door service at https://agent.nukez.xyz. First entry is not a sign-up form. You provision your Ed25519 or secp256k1 keypair over HTTP, and POST /v1/provision/verify returns a portal_url that already carries a register_token. Provisioning leaves the account in pending_payment until storage is paid for, and opening the portal_url is what creates the passkey. Every visit after that is the same URL with no token and a single Connect button, because the credential is discoverable and the browser resolves it without a username.

1. 1Load the keypair the gateway knows you byThe Ed25519 keypair is stored the way Solana writes it, as a 64-byte JSON array whose first 32 bytes are the seed, so the private key is rebuilt from that slice and the public half is base58-encoded. That public key is the identity the gateway resolves lockers against, and it never leaves the machine in any form other than a signature.
2. 2Request a challenge and sign itPOST /v1/provision/challenge takes only the public key and returns a message, a nonce, and an expiry. You sign the message field with the private key: Ed25519 signatures are base58-encoded, while secp256k1 owners wrap the same string with EIP-191 personal_sign and submit 0x-prefixed hex.
3. 3Exchange the signature for a portal URLPOST /v1/provision/verify takes the public key, the nonce from step 1, and the signature, and returns developer_id, status, owner_pubkey, registration_token, and a ready-made portal_url. You never have to assemble that URL yourself.
4. 4Provisioning alone does not activate storageThe status field comes back as pending_payment, which means the developer record and runtime exist but no lockers are usable yet. Activation is a separate three-part step: read pricing from GET /v1/service/request, send the on-chain payment, then POST /v1/service/confirm with the X402-TX header.
5. 5Bind the passkey in the browserThe registration token is valid for ten minutes. Opening portal_url prompts once for biometric consent and binds a discoverable passkey to that developer_id. If the token lapses, POST /v1/portal/auth/challenge followed by POST /v1/portal/auth/verify-keypair mints a fresh registration token without repeating provisioning.

Code notes

Once the session exists, every portal call sends it as a bearer token to https://agent.nukez.xyz. GET /v1/portal/status is the identity and posture record for the signed-in owner, and GET /v1/portal/alerts plus GET /v1/portal/files supply the rest of the dashboard. The three stat cards on /agent-portal are built from status and files; alerts render as callouts above them. There is no settings screen, no billing view, and no capacity control on the page.

1. 1Status carries the owner's identity and postureThe portal reads developer_id, owner_pubkey, sig_alg, network, system_locker_id, system_receipt_id, has_signing_bridge, and status, and ignores the rest of a much larger runtime payload that also includes lockers[], capacity_summary, and subscription. Both system_locker_id and system_receipt_id are nullable and singular, so an identity has at most one system locker and at most one system receipt.
2. 2Alerts are lifecycle notices, not actionsEach alert carries type, severity, message, developer_id, created_at as a Unix float, a free-form data object, and an acknowledged flag. Types come from a fixed set: capacity_warning, capacity_critical, verification_anomaly, access_pattern, service_expiry, and bridge_health. The dashboard renders only the message text and offers no way to acknowledge an alert.
3. 3How the three cards are derivedFiles stored comes from file_count with a subtitle from last_attested, Status comes from the status field with a subtitle chosen by has_signing_bridge, and Network comes from network with a truncated system_locker_id. The page polls files and alerts every thirty seconds and the Refresh button triggers the same load. Because the dashboard only special-cases the literal severity value error and the backend emits info, warning, or critical, every real alert currently renders in the neutral info callout.
4. 4Status changes shape when keys are linkedWith a single key the response is the flat object shown above. Once a second keypair is linked, status instead returns a results array in which each entry wraps the same flat object under data alongside its pubkey, algorithm, and developer_id, plus an optional linked_but_unprovisioned array for linked keys whose runtime is not assigned yet.

Code notes

A file record in the portal is metadata, not content. GET /v1/portal/files returns a file_count, a response-level last_attested timestamp, and an array of records describing what the gateway holds for this identity. /agent-portal/files lists all of them; the dashboard shows only the first eight. Expanding a row shows the full record, and a single text preview call is the only path to any bytes.

1. 1The fields a file record actually carriesEvery record has filename, size_bytes, content_type, content_hash, stored_at, and task_context, assembled by the runtime from the instance state dictionary merged with the session's cached storage index. The content_hash is what the owner copies when reconciling a file against an external record, and task_context is the free-text label the agent attached when it stored the file.
2. 2Timestamps and identity taggingstored_at is Unix seconds and is rendered as a relative time in the list and a locale string in the expanded row, while last_attested sits on the response envelope and applies to the whole attestation rather than to any one file. The two underscore-prefixed identity fields are not per-key markers on a single-key account: they appear only once more than one keypair is linked, at which point the front door tags every merged record, the primary key's included.
3. 3What the list view can and cannot sortSorting is available on filename, size_bytes, and stored_at only; the Type and Hash columns are display-only. The page polls on the same thirty-second cadence as the dashboard, and clicking a row expands the full metadata block underneath it.
4. 4Metadata only, with no content-level callThe portal never serves file bytes. /v1/portal/files is a collection route and the front door defines no per-file content endpoint, so there is no preview, download, delete, rename, upload, or share control on this page. To read a stored file, go through the gateway receipt proxy or the SDK rather than the portal.

Code notes

Verification from the portal is scoped to one receipt: the system receipt named by status.system_receipt_id. There is no free-form receipt field on /agent-portal/verify, so the page verifies the identity's own attestation and nothing else. The call is unsigned, which is why it works from a passkey session that has no access to the storage key.

1. 1The receipt id comes from status, not from inputThe Verify page reads status.system_receipt_id and interpolates it into the path. The owner clicks one button; there is no field for pasting an arbitrary receipt, so any other receipt has to be checked through the public verifier instead.
2. 2The proof the response returnsThe front door proxies the request to the runtime's unsigned audit route, which returns a top-level status of success, the receipt_id, and a verification object whose attestation carries attestation_status, merkle_root, tx_signature, and file_count. The Merkle root and the transaction signature are both copyable in the UI, and file_count is the number of files covered by that attestation rather than the current file total.
3. 3How the result is judged and linkedThe Verified badge appears only when attestation_status is complete or attested, and every other value renders as Failed; the top-level status field is never inspected. The transaction signature is turned into a Solana explorer link whose cluster query is chosen from status.network by substring match, with mainnet taking no cluster parameter.
4. 4Verification fails loudly by designThe verify caller has no 404 or 503 fallback, so a failure is surfaced rather than smoothed into an empty state; the same is true of the status and linked-keys callers, while files, ops-log, usage, and alerts all degrade to empty results. When status.system_receipt_id is null the page shows an informational callout instead of a Verify button.

Code notes

The Activity view has two tabs backed by two endpoints: GET /v1/portal/ops-log for what agents did, and GET /v1/portal/usage for token and call counters. Neither polls; both refresh on the button. The Keys view lists the pubkeys attached to this portal identity from GET /v1/portal/auth/linked-keys and holds the one write-adjacent flow in the whole portal, which is linking a second keypair that has already been provisioned on its own.

1. 1An ops-log entry groups several operationsEach entry has a ts, an agent_id, a task_summary, and an operations array in which every item names a tool, a status, and a summary. An optional token_usage block records the tokens that entry consumed.
2. 2Usage returns six countersThe usage object carries sonnet_input_tokens, sonnet_output_tokens, opus_input_tokens, opus_output_tokens, total_api_calls, and runtime_ops. These are cumulative counters for the identity, not a per-request breakdown.
3. 3What the two tabs actually renderThe Ops Log tab renders Time, Task, Tool, and Status columns, marking an operation with status ok as a check and anything else as a cross, and it never displays the per-entry token_usage. The Usage tab shows four of the six counters, leaving the two opus fields fetched but unrendered.
4. 4The Keys table is one session-gated readGET /v1/portal/auth/linked-keys returns the portal_identity and a keys array in which each entry has a developer_id, a pubkey, an algorithm, an optional label, and a linked_at timestamp. The first key is shown as Primary and the rest as Linked, and if the endpoint is unavailable the page falls back to displaying the owner_pubkey from status alone.
5. 5Linking a second, already-provisioned keyThe three calls run in order: link-pubkey returns a challenge with an expiry, link-pubkey/verify exchanges a signature from the new key for a link_token and a portal_url, and link-pubkey/complete redeems that token under the current session and returns the updated key list. A 404 from the first call means the key has no subscription yet and must be provisioned before it can be linked, while a 409 means it is already attached to this identity.