Coinrule DeFi Docs
Start NowHelp Center
  • Welcome
    • About Coinrule
  • Onboarding
    • How to Get Started
      • Connecting Your Wallet
      • Funding Your Wallet
      • Smart Account Balance
      • Withdraw Funds
      • Create a DeFi Rule
    • DeFi Wallets
      • Supported DeFi Wallets
      • What wallet should I use?
    • SAFE {Wallet}
      • Viewing Your Assets
      • Sending Assets
    • Multiswap
    • Strategies for DeFi
      • Trailing Stop-Loss
      • Dollar Cost Average (DCA)
      • Momentum Surge
      • Double Tap
      • Quick Rebound
  • Technical Overview
    • Trading
      • LI.FI Integration
      • Token List
      • Gas
        • Role of the Paymaster
      • Fees
      • Slippage
      • Supported Blockchains
      • Market Data
    • Smart Account
      • Signer Wallet
      • Session Keys
      • Smart Session Manager
      • Account Security
  • Links
    • Twitter
    • Instagram
    • Youtube
    • Facebook
    • Medium
  • Resources
    • Help Centre
    • Trading Academy
    • Blog
  • Terms & Conditions
  • Privacy
Powered by GitBook
On this page
  1. Technical Overview
  2. Smart Account

Smart Session Manager

PreviousSession KeysNextAccount Security

Last updated 3 months ago

and co-developed the Smart Session Manager. It is highly customizable, and compatible with ERC-771.

The Smart Session Manager’s design separates policies and validators. This allows for a much more composable developer experience, where session keys can be configured by reusing existing policies and validators.

Below is an overview of the Smart Session Manager architecture:

A Policy is a defined permission, such as a gas limit, spending limit, or a whitelist of contract addresses. The (Stateless) Validator is a signing mechanism, such as an ECDSA validator (EOA), MPC, passkeys, etc. The Smart Session Manager stores validator IDs, which map to an IValidator contract that verifies signatures and an IPolicy contract that validates policies.

Each Smart Session, created by Coinrule and approved by the user, has a corresponding validator ID. When a transaction is triggered against a specific validator ID, the policies are looped over, and the session key signatures are verified against the signing mechanism.

Composability emerges here because a specific Policy and Validator (Coinrule) only needs to be written once and can be reused anytime a Rule/Strategy condition is met to execute a trade.

Rhinestone
Biconomy