Session Vaults

Phase 2 of the scaling roadmap introduces the SessionVault -- an agent-based execution model that enables hundreds of interactions to be settled in a few on-chain transactions. A user opens a session with a GHOST budget, an agent performs work off-chain, and the results are settled on-chain with cryptographic proofs of correctness.

Model

The SessionVault enables the "2 transactions for 1,000 interactions" model:

1. Open session (1 transaction): User locks GHOST budget and assigns an agent
2. Agent works off-chain (0 transactions): Agent executes 100-10,000 interactions
3. Settle batches (1-N transactions): Agent submits settlement proofs periodically
4. Close session (1 transaction): Remaining budget returned to user

Session Lifecycle

States

State	Description
INACTIVE	Default state / session not created
ACTIVE	Session is open, agent can settle batches
CLOSED	Session ended normally, remaining budget returned to user
DISPUTED	User has disputed a settlement, under review
EXPIRED	Session passed its expiry block without being closed

Opening a Session

function openSession(
    address agent,
    bytes32 sessionCommitment,
    uint64 duration
) external payable returns (uint256 sessionId)

Parameter	Description
agent	Address authorized to submit settlement batches
sessionCommitment	Poseidon hash of session parameters (initial state root)
duration	Session duration in blocks
msg.value	GHOST budget locked for the session

Constraints:

Constraint	Value	Description
MIN_DURATION	300 blocks (~5 minutes)	Minimum session length
MAX_DURATION	604,800 blocks (~7 days)	Maximum session length
Agent address	Must not be address(0) or msg.sender	Agent must be a separate address
Budget	Must be > 0	Session must have funds

Settling Batches

The agent periodically settles completed work on-chain:

function settleBatch(
    uint256 sessionId,
    uint256 interactionCount,
    uint256 paymentAmount,
    bytes32 newStateRoot,
    bytes calldata batchProof
) external

The off-chain state is tracked as an incremental Poseidon hash chain:

stateRoot_0 = sessionCommitment
stateRoot_n = Poseidon(stateRoot_{n-1}, interaction_hash_n)

The Groth16 proof verifies that the hash chain transition from stateRootBefore to stateRootAfter was computed correctly for the claimed number of interactions. This is an integrity proof, not a privacy proof -- it ensures the agent did not fabricate or skip interactions.

Settlement proof public inputs:

Index	Field	Description
0	sessionId	The session being settled
1	interactionCount	Number of interactions in this batch
2	paymentAmount	GHOST earned by agent in this batch
3	stateRootBefore	State root before this batch
4	stateRootAfter	State root after processing interactions

On successful settlement, the agent receives payment immediately (optimistic). The user has a dispute window to challenge fraudulent settlements.

Dispute Resolution

Users can dispute a settlement within the DISPUTE_WINDOW:

function disputeBatch(
    uint256 sessionId,
    uint256 batchIndex,
    bytes calldata fraudProof
) external

Constant	Value	Description
DISPUTE_WINDOW	3,600 blocks (~1 hour)	Time window for user to dispute a settlement

The dispute window operates per-settlement: each settled batch has its own 3,600-block window. If the user does not dispute within this window, the settlement is considered finalized.

When a dispute is submitted, the session transitions to the DISPUTED state. In the current implementation, disputes flag the session for manual review. Future versions will implement full on-chain fraud proof verification.

Closing a Session

function closeSession(uint256 sessionId) external

Both the user and agent can close a session:

• User closes: Can close at any time (users are the party protected by disputes)
• Agent closes: Must wait for the dispute window to pass on the latest settlement

On close, remaining budget (budgetTotal - budgetSpent) is returned to the user.

Expired Sessions

If a session passes its expiryBlock without being closed, anyone can call reclaimExpired() to return the remaining budget to the user:

function reclaimExpired(uint256 sessionId) external

This prevents GHOST from being permanently locked in an abandoned session.

Session Data

Each session stores:

Field	Type	Description
sessionCommitment	bytes32	Poseidon hash of session parameters (initial state root)
agent	address	Delegated agent address
user	address	Session creator (budget provider)
budgetTotal	uint256	Total GHOST locked at session open
budgetSpent	uint256	Total GHOST paid to agent so far
settledCount	uint256	Number of settled batches
totalInteractions	uint256	Cumulative interactions across all batches
expiryBlock	uint64	Session expires after this block
currentStateRoot	bytes32	Latest settled state root
state	SessionState	Current session state

Security Model

The SessionVault uses an optimistic settlement model:

1. Agent settles immediately: Payment is sent to the agent on settlement (no delay)
2. User can dispute: Within the 3,600-block dispute window, the user can submit a fraud proof
3. Dispute freezes session: A disputed session transitions to DISPUTED state, preventing further settlements

This model is optimistic because it assumes the agent is honest and pays immediately. The dispute mechanism provides recourse if the agent misbehaves. The economic incentive for honest behavior comes from:

• Reputation: Agents who are disputed lose credibility
• Bond forfeiture: Future versions will require agent bonds that are slashed on successful dispute
• Session termination: A disputed session is immediately frozen

Use Cases

AI Agent Task Execution

An AI agent handles a user's trading strategy. The user opens a session with a 100 GHOST budget. The agent executes 500 trades off-chain, settling every 50 trades. Each settlement proves the hash chain of trades was computed correctly and claims the agent's fee.

Batch Data Processing

A data pipeline commits thousands of data hashes per day. A session vault allows the pipeline agent to accumulate commits off-chain and settle them in batches, reducing the on-chain footprint from thousands of transactions to a handful of settlements.

Subscription Services

A service provider opens a session for a subscriber. The agent tracks API calls off-chain, settling the usage periodically. The subscriber's budget decreases with each settlement, and the session closes when the subscription ends or the budget is exhausted.