A Deep Dive into Fogo Sessions

Fogo is a high-performance Layer 1 blockchain built on the Solana Virtual Machine (SVM) for ultra-low-latency, achieving near-instant transactions and gasless experiences by leveraging Firedancer and a specialized architecture for speed and fairness. Fogo Sessions are a core feature of Fogo, designed to reduce signing friction without weakening security. Instead of requiring a wallet signature for every interaction, users sign a single, structured intent that grants temporary, tightly scoped authority to a Session Account. This authority is enforced at the protocol level through the Session Manager Program and a modified, session-aware SPL Token Program. In this article, we'll go over how sessions are created, validated, enforced at runtime, and eventually revoked or closed.

Session Setup (The Intent Message)

A session first starts with an Intent Message, a payload that the user signs off-chain using their main wallet. It acts as the "configuration file" for the session, explicitly defining the boundaries of authority. The Message struct is parsed on-chain and used to enforce the following constraints:

pub struct Message {
    pub version: Version,
    pub chain_id: String,
    pub domain: Domain,
    pub expires: DateTime<FixedOffset>,
    pub session_key: Pubkey,
    pub tokens: Tokens,
    pub extra: HashMap<String, String>,
}

Starting a Session

In order to ensure that a Session is valid, instruction introspection is used. The transaction needed to start a session requires two instructions:

1. First, an instruction to the Ed25519 program to verify the intent signature validity.
2. Second, a start_session instruction to the Session Manager program.

Instruction 1: Signature Verification (Ed25519)

The first instruction invokes the Solana native Ed25519 Program with the user's public key, the signed Intent Message (serialized), and the signature as an input value. Because transactions are atomic, if this verification fails, the entire transaction reverts. This guarantees that the subsequent start_session instruction can never be reached unless the user's signature has been cryptographically proven valid.

Instruction 2: Session Initialization

The second instruction calls start_session on the Session Manager Program. This instruction does not take the signature as an argument. Instead, it looks backward at the previous instruction of the current transaction using introspection.

This mechanism ensures that a Session Account cannot be created unless the user has cryptographically signed the exact configuration parameters loaded by the program.

The start_session instruction performs the following operations:

Step 1: Load and Verify the Intent - The instruction introspects the sysvar_instructions account to find the Ed25519 verification instruction at index -1. This retrieves the user's signature and the signed message, binding them cryptographically to this transaction.

Step 2: Validate Contextual Integrity - The program validates that the session_key from the message matches the session account being initialized, the chain_id matches the on-chain ChainId account, the domain is properly registered, and the expiration timestamp is valid.

Step 3: Apply Token Approvals - For sessions with Tokens::Specific, the program converts the remaining accounts into pending approval operations, executes token approvals using a special PDA derived from SESSION_SETTER_SEED. For sessions with Tokens::All, no upfront approvals are set.

Step 4: Initialize the Session Account - The program creates a Session account containing the sponsor, user, domain_hash, authorized_programs, authorized_tokens, expiration, and extra metadata.

Runtime Checks

Once initialized, the Session Account can act as a signer on programs that integrate Fogo Sessions. The Fogo Chain ecosystem enforces conditions (expiration timestamp, authorized programs) at the protocol level during every interaction.

Token Operations (modified Token Program)

The standard SPL Token program has been modified to natively recognize Session Accounts. Whenever a transaction involves a token transfer signed by a session key, the program triggers a Session hook to validate the operation:

1. Expiry status - ensures the current block timestamp is within the expires window and the session state is not Revoked.
2. Token Account owner - ensures the user of the session matches the Token Account owner.
3. Authorized programs - verifies the program is listed as an authorized program in the session.

Session Revocation and Closing

Sessions can be explicitly revoked or closed when no longer needed. Revocation marks the session as inactive while keeping the account alive, whereas closing deallocates the account and returns rent. Both operations require the original user's signature, ensuring that only the session creator can terminate their own sessions.

Security Considerations

The Fogo Sessions design demonstrates a well-considered approach to the security-usability tradeoff in blockchain applications. By requiring cryptographic proof at session creation and enforcing constraints at the protocol level, it achieves a meaningful reduction in signing friction without introducing new attack surfaces. The use of instruction introspection for binding the intent message to the session initialization is particularly elegant, as it makes it cryptographically impossible to create a session with different parameters than what the user signed.