Skip to main content

​
Overview

The SessionRegistry provides a minimal onchain interface for checking user session state. These examples demonstrate common integration patterns for checking:
  • Whether a participant currently has an active session (isSessionActive / enforceSessionActive)
  • Whether a participant still has a present session (isSessionPresent / enforceSessionPresent)
Each venue can decide how to handle expirations, blacklists, or order cancellations according to its internal matching logic.

​
Example 1: Basic Settlement Guard

interface ISessionRegistry {
    function enforceSessionActive(address wallet) external view;
    function enforceSessionPresent(address wallet) external view;
}

contract SettlementExample {
    ISessionRegistry public immutable registry;

    constructor(address sessionRegistry) {
        registry = ISessionRegistry(sessionRegistry);
    }

    function settle(address maker, address taker) external {
        // 1. Taker must be active at time of execution
        registry.enforceSessionActive(taker);

        // 2. Maker must still have presence (not blacklisted)
        registry.enforceSessionPresent(maker);

        // Continue with trade settlement
    }
}
This pattern blocks explicitly blacklisted makers while allowing fills from expired but previously verified makers.

​
Example 2: Custom Matching Logic

function matchOrder(address maker, address taker) external {
    bool takerActive = registry.isSessionActive(taker);
    bool makerPresent = registry.isSessionPresent(maker);

    if (!takerActive) revert("taker:inactive");
    if (!makerPresent) revert("maker:blacklisted");

    // Optionally record or audit the session state
    // Continue with matching logic
}
Use this approach if your engine prefers explicit branching over revert-based enforcement.

​
Example 3: Library Helper (Reusable Guard)

library SessionGuards {
    function checkCompliance(
        address registry,
        address maker,
        address taker
    ) internal view {
        ISessionRegistry(registry).enforceSessionActive(taker);
        ISessionRegistry(registry).enforceSessionPresent(maker);
    }
}
You can import this library into routers or settlement contracts to standardize checks across venues.

​
Session Outcomes

RoleCheckPassedFailedInterpretation
TakerisSessionActiveTrade allowedTrade rejectedActive/inactive compliance
MakerisSessionPresentTrade allowedTrade rejectedPresent / blacklisted state

​
Implementation Notes

  • Takers must always be active at settlement.
  • Makers only need to remain present (not blacklisted).
  • Expired makers are still fillable to avoid unnecessary orderbook churn.
  • These examples represent reference patterns - the enforcement logic can be adapted for your architecture.
  • The registry itself is policy-agnostic and only exposes deterministic session state.