Authentication

Authentication Layers

Sails.to implements a four-layer authentication model. Each layer builds on the one below it. No single layer is sufficient — all four must agree before any operation proceeds. This is not over-engineering; this is what you build when you're responsible for other people's securities.

Layer 1: Solana Wallet Signature

The cryptographic foundation. Every request begins with a Solana wallet signature proving ownership of the private key. This is standard Ed25519 — the same signature scheme that secures every transaction on the Solana network. No password, no username — just cryptographic proof of identity.

Layer 2: NFT Verification

A wallet signature proves you exist. An NFT proves you're authorized. The platform inspects the wallet for role-specific NFTs minted by the Melusina authority program. No NFT, no access — regardless of how valid your wallet signature is. The NFT encodes your role, your permissions, your expiration date, and whether the platform can recall your authorization.

Layer 3: Sandstorm Session

OS-level isolation. Once wallet and NFT are verified, the Sandstorm runtime establishes a session bound to a specific grain. You can only interact with grains you've been explicitly granted access to. The session is not a cookie — it is a kernel-enforced security boundary. A compromised application cannot reach another grain's data any more than a Linux process can read another process's memory.

Layer 4: Powerbox Capability

Inter-grain authority. When one grain needs to interact with another — a Broker Portal placing an investor into an Offering Grain, for example — the Powerbox mediates. A claim token is issued, converted to a sturdyRef, and that sturdyRef grants persistent, cross-session access to specific capabilities. Not to the whole grain — to specific methods on that grain's Cap'n Proto interface.

Layer 1: Solana Wallet Signature   → proves wallet ownership
Layer 2: NFT Verification          → proves role authorization
Layer 3: Sandstorm Session          → proves grain access
Layer 4: Powerbox Capability        → proves inter-grain authority

Compromise one layer and three remain. Steal a wallet key but lack the NFT — denied. Hold the NFT but lack a Sandstorm session — denied. Have a session but no Powerbox capability for the target grain — denied. This is defense in depth as architecture, not as aspiration.

Role NFTs

The Melusina program mints role-specific NFTs that encode participant authorization. Each is a print edition from the Sails Master NFT, carrying role-specific metadata and optional expiration. Every role NFT is recallable — the issuing authority can revoke it at any time.

Role NFT	Capabilities	Issued By	Recallable
Platform Operator	Deploy offerings, manage platform configuration	Master (3-of-5)	Yes
White-Label Operator	Operate branded instance, manage own issuers	Platform Operator	Yes
Trustee	Authenticate transactions, validate CrossConversions	Platform Operator	Yes
KYC Issuer	Issue KYC credential NFTs to verified investors	Platform Operator	Yes
Broker	Place investors, execute secondary trades	Platform Operator	Yes
Issuer	Create offerings within their Series, manage investors	Platform Operator	Yes
Paying Agent	Execute distributions, manage revenue waterfall	Trustee	Yes

The hierarchy is strict. A Platform Operator is minted only by the Master NFT's 3-of-5 threshold signing ceremony. A Trustee is minted only by a Platform Operator. A Paying Agent is minted only by a Trustee. The chain of authority is unbroken and on-chain — every role can be traced back to the Master NFT in a single walk of the mint history.

Threshold Operations

Critical operations require M-of-N keyholder approval, implemented via threshold cryptography from the Melusina program's Shamir-like signing scheme. The threshold levels are calibrated to the severity of the action:

Threshold	Operations	Rationale
3-of-5	Master NFT operations, force transfers, contract upgrades	Highest-impact actions affecting platform-wide security. Requires supermajority of geographically distributed keyholders with hardware wallets.
2-of-3	Large CrossConversions (>$1M), emergency freezes	High-value operations requiring additional oversight beyond single-Trustee authentication.
1-of-1	Standard CrossConversions, distribution authentication	Routine operations authenticated by a single appointed Trustee holding a valid Trustee NFT.

Key compromise mitigation: hardware wallet enforcement for all keyholders, geographic distribution of signers, documented key rotation procedures, and the ability to recall any role NFT instantly if a keyholder is compromised. The 3-of-5 threshold means an attacker must compromise three separate hardware wallets held by three separate people in three separate locations. This is the standard we hold ourselves to.

Session Management

Sandstorm sessions are not traditional web sessions. They are capability-bound, grain-scoped, and kernel-enforced:

• Session Creation: After Layer 1 (wallet) and Layer 2 (NFT) verification, the platform provisions a Sandstorm session tied to the user's role-appropriate grain. An Issuer gets a DAO Manager grain session. An Investor gets an Investor Self-Service grain session. A Broker gets a Broker Portal grain session.
• Session Scope: Each session is bound to a single grain. To access another grain's capabilities, you must go through the Powerbox — there is no session that spans multiple grains.
• Capability Persistence: Powerbox sturdyRefs persist across sessions. If a Broker was granted an OfferingAPI capability from an Offering Grain, that capability survives session restart — it is stored in the grain's journal and restored on replay.
• Time-Bound Tokens: Trustee sessions include time-bound authentication tokens. A Trustee must re-authenticate periodically — the session itself may persist, but high-value operations require fresh NFT verification within a configurable window.
• Audit Logging: Every session creation, capability grant, capability use, and session termination is logged to the grain's append-only journal. Seven-year retention. No exceptions.

The result: a system where authentication is not a gate you pass through once, but a continuous assertion of identity, role, access, and authority — verified at every layer, for every operation, without exception.