Authenticates the owner session in the browser.
Docs · Portal
Multi-keypair management.
Ed25519secp256k1
Multiple signing identities under one owner.
Multi-keypair management lets one owner account work with multiple gateway signing identities: separate devices, agent runtimes, delegated peers, archive keys, or both Solana-style Ed25519 and EVM-style secp256k1 signers.
Signs protected gateway envelopes from local Solana-style keys.
Signs equivalent owner requests from EVM or Monad-side identities.
Model
Separate passkeys from signing identities
Portal login and gateway authorization are different layers and should be reasoned about separately.
Owner identity Portal login: passkey Gateway signer: Ed25519 public key Gateway signer: secp256k1 address # passkey authenticates the browser session# keypairs authorize gateway envelopes
Code notes
The owner portal uses passkeys for human login. Gateway operations use Ed25519 or secp256k1 signing identities. Multi-keypair management is about the signing identities, not the passkey credential.
A passkey can unlock the owner portal without becoming a Nukez gateway signer.
Link
Attach a signer by proving key control
A new Ed25519 or secp256k1 identity is linked by signing a challenge, not by uploading private key material.
Owner portal Keys Link another keypair Algorithm: ed25519 | secp256k1 Public key or address Sign challenge GET /v1/portal/status
Code notes
To link another signing identity, the portal asks the owner to prove control of the new keypair by signing a challenge. Once verified, the key appears in linked-key status and can be used according to its assigned role.
Do not upload private key material to Nukez. The portal only needs a signature proving control of the public identity.
Roles
Give each linked key a clear job
Device, agent, peer, and archive keys should be named by the authority they are expected to exercise.
Common key shapes:primary Ed25519 owner workstationdelegate Ed25519 second device or agent runtimepeer secp256k1 EVM or Monad counterpartyarchive Ed25519 long-term read / audit key
Code notes
Linked signing identities should have clear operational intent. Common patterns are same-algorithm device split, cross-algorithm peer access, and archive keys for long-term retrieval or audit workflows.
All signatures are recorded with their algorithm tag so verification remains unambiguous.
Lifecycle
Rotate future authority without changing history
Key changes affect future operations while existing receipts and Merkle commitments remain verifiable.
Key lifecycle: Rotate compromised signer Revoke retired device Link replacement key Re-attest new operational state # old receipts remain verifiable# future writes require active linked authority
Code notes
Rotation and revocation are per-key authority changes. They affect who can authorize future operations. Existing Merkle history, receipts, and attestations remain committed and independently verifiable.
Treat signer lifecycle changes as owner-control operations; they should be deliberate and auditable.
Verification stays algorithm-explicit.
Each signed request and receipt path carries the signer algorithm, so Ed25519 and secp256k1 identities can coexist without ambiguity. Rotating or revoking a key changes future authority only; committed receipt history remains anchored and independently verifiable.