LazorKit — Execution Layer for Web3

A permissioned execution layer that defines who can execute, how execution happens, and who pays for it.

---

TL;DR

• Passkey wallets — users authenticate with biometrics (FaceID, TouchID, Windows Hello); no seed phrase, no private key management
• Session keys — scoped, time-bound delegation keys that let apps or agents act on a user's behalf without repeated signing prompts
• Paymaster — a gas abstraction service that sponsors or routes transaction fees, so users never need to hold SOL to interact
• Programmable execution — RBAC roles define who can execute; session action constraints define what a delegated session key can do, to which programs, up to what value, and for how long
• Live on Solana — deployed in production with two reference products: Seedless (onboarding) and session.money (agent execution)

---

System Overview

There are two execution paths in LazorKit:

Direct execution — A wallet authority (Owner, Admin, or Spender) signs a transaction using their passkey or Ed25519 key. No session key involved. No action constraints — only role-based permission gates.

Delegated execution — An Owner or Admin creates a session key and hands it to an app or agent. The session key signs on the wallet's behalf within a defined scope (program whitelist, spending limits, expiry). No passkey prompt per transaction.

In both cases, the transaction goes to a Paymaster, which signs as the fee_payer, pays the SOL gas, collects compensation from the user in tokens (e.g. USDC), and submits the transaction. On-chain, the LazorKit program validates the signer and — if the Paymaster is a registered fee_payer — collects a protocol fee from the Paymaster's SOL.

The user bears the economic cost in tokens. The Paymaster is break-even. LazorKit captures a share as protocol revenue, recorded on-chain against the fee_payer for future early-contributor rewards.

---

The Problem

Web3 applications today impose a fixed set of prerequisites before a user can do anything:

• Wallet required at entry — users must set up a wallet before they can touch the product
• Every action requires signing — each transaction triggers a wallet prompt, breaking flow
• Gas is a hard requirement — if a user has no SOL, they cannot execute, regardless of intent
• No delegation or automation — there is no standard way for an app or agent to act on behalf of a user within defined limits

These are not UX problems. They are structural constraints built into how execution currently works.

---

The Shift

Execution should not be monolithic. It should be:

• Programmable — define what can be executed, against which programs, within what parameters
• Delegatable — users should be able to grant scoped execution rights to apps or agents
• Automatable — agents and services should be able to trigger execution without user interruption
• Sponsorable — any party should be able to fund a user's transaction based on business logic, not just the user themselves

LazorKit is the layer that makes this possible.

---

How LazorKit Works

Path A — Direct execution (user)

---

Path B — Delegated execution (agent or app)

---

Core Components

Smart Wallet (Passkey-controlled PDA)

An on-chain account controlled by the LazorKit program. The owner is authenticated via a WebAuthn credential, not a private key. Supports key rotation, spending policies, and session delegation.

Session Keys (Scoped Delegation)

Ephemeral keypairs granted limited execution rights. A session key can be constrained to specific programs, instruction types, value limits, and expiry windows. When the session ends, the key is invalid.

RBAC (Role-Based Access Control)

The on-chain permission model that governs who can execute and what wallet operations they can perform. Three roles — Owner, Admin, Spender — each with different capabilities. All three can call Execute. Only Owner and Admin can create session keys. Role enforcement is at the program level; it cannot be bypassed by the application.

Note: RBAC defines role-based gates. Action constraints (spending limits, program filters, expiry) are a separate layer that applies only to session keys — not to authorities executing directly.

Paymaster (Gas Abstraction)

The transaction's fee_payer — typically the integrating developer themselves. The fee_payer pays SOL for gas, pays LazorKit's protocol fee, and submits the transaction. The end user never needs to hold SOL; they compensate the developer through app-level mechanisms (on-ramp markups, subscriptions, product fees, etc.), which is outside LazorKit's scope. The fee_payer pubkey accumulates in FeeRecord — the basis for early contributor token rewards. Future versions will support open Paymaster competition for developers that prefer to outsource this role.

---

Use Cases

1. Gasless Onboarding

A new user opens a Web3 app for the first time.

1. User authenticates with FaceID
2. LazorKit creates a smart wallet on Solana — the developer signs as fee_payer and funds the wallet creation fee
3. The user executes transactions directly via their passkey authority — no session key required
4. Optionally, the app creates a session key scoped to its program so the user is not prompted on every action

Who pays: The developer acts as fee_payer and sponsors wallet creation + transactions in SOL. The user compensates the developer through the app's own monetization — on-ramp markups, subscription, product fees. The developer's pubkey accumulates in FeeRecord and earns early contributor rewards at token launch.

---

2. Agent Execution

An on-chain agent needs to execute recurring actions on behalf of a user (e.g. rebalancing, auto-compound, limit orders).

1. User creates a session key with a defined scope: program address, max value per tx, expiry date
2. Agent holds the session key and triggers execution on its own schedule
3. Each execution passes RBAC validation before the Paymaster funds it
4. Session expires automatically — no manual revocation needed

Who pays: The agent operator pre-funds the Paymaster, or the user configures a self-funded execution budget.

---

Economic Model

Who pays what

• User — pays the developer through app-level monetization (on-ramp fees, subscriptions, product markups, in-app purchases). LazorKit does not prescribe this layer.
• Developer — acts as the transaction's fee_payer. Pays SOL for gas + LazorKit's protocol fee. Recouped from the user via the app.
• LazorKit — captures a protocol fee from the fee_payer (the developer) on each sponsored execution. Currently a fixed SOL amount; configurable by admin.

The developer's fee_payer pubkey is recorded in the on-chain FeeRecord, along with cumulative fees paid, transaction count, and wallets created.

Developer incentive — early contributor rewards

FeeRecord.total_fees_paid is the basis for early contributor rewards at token launch. Developers who sponsor their users' fees earn protocol tokens proportional to the volume of activity they funded.

Concretely: every time a developer creates a wallet for a user or sponsors an execution, the fee accumulates against their pubkey. At token launch, a snapshot of FeeRecord.total_fees_paid determines each developer's share. There is no application process — the on-chain record is the reward claim.

LazorKit does not take a cut from app-level revenue. The developer keeps everything they earn from users; LazorKit's protocol fee flows through the developer as fee_payer, and comes back as token share. A parallel mechanism for tracking end users directly may be added later.

Current model

• Fees collected in native SOL, no token required
• One Paymaster configuration, fixed fee schedule
• Fees charged on every transaction when the protocol is enabled. Reward tracking is opt-in — registering a FeeRecord for your fee_payer is what turns the fees you pay into a claim at token launch

Future model

• Paymaster competition: multiple providers compete on fee rates, supported tokens, and SLAs
• Fee configurability: protocol fees shift from fixed to configurable based on execution type
• Protocol token: introduced for governance, fee settlement, and Paymaster staking — distribution weighted by FeeRecord data

---

Current Status

LazorKit is live on Solana mainnet. Two products are in production:

• Seedless — a reference implementation of gasless passkey onboarding. Users create a smart wallet with biometrics in under 10 seconds.
• session.money — an agent execution interface using LazorKit session keys. Demonstrates scoped delegation for automated on-chain actions.

The core protocol (smart wallet program, session key validation, Paymaster service) is deployed and actively used.

---

Positioning

LazorKit is not a wallet. It does not have a user-facing interface for managing assets.

LazorKit is not a dapp. It does not define what users do on-chain.

LazorKit is an execution layer — infrastructure that sits between the user (or agent) and the blockchain. It handles authentication, permission enforcement, fee routing, and transaction submission. Applications and agents build on top of it.

---

Closing

Every Web3 application today manages execution ad-hoc — wallets, signatures, gas, and delegation handled differently by every team. LazorKit turns execution into a programmable layer: consistent, composable, and sponsorable. Any application that needs to move users or agents from intent to on-chain action can build on it.