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 — ranks define who can manage a wallet; spending policies and session actions define what a delegated key can do, to which programs, up to what value, and for how long
• Live on Solana — protocol v1 runs on mainnet, with Seedless (passkey onboarding) in production; protocol v2 runs on devnet, and its mainnet deployment is pending (see Networks & versions)

---

System Overview

There are two execution paths in LazorKit:

Direct execution — A wallet authority (Owner, Admin, or Delegate) signs a transaction using their passkey or Ed25519 key. No session key involved. An Owner or Admin spends without limits; a Delegate only within its spending policy.

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, and submits the transaction. Usually the paymaster is run by (or for) the integrating developer, who recoups the cost through the app. On-chain, the LazorKit program validates the signer and — when the protocol fee is configured — collects a protocol fee from the fee_payer's SOL and records it in that payer's FeeRecord.

The user bears the economic cost through the app (tokens, subscriptions, product fees). LazorKit captures a protocol fee, 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.

Ranks and policies

The on-chain permission model. Each authority has a rank — Owner, Admin or Delegate — that says what it may manage, and optionally a spending policy that says what it may spend. All three ranks can call Execute; a Delegate must carry a policy, and spends only within it. Only Owners and Admins can create session keys. A wallet may have several Owners (one per device). Enforcement is at the program level; the application cannot bypass it. See Ranks & policies.

Action constraints (spending limits, program filters, expiry) are one engine shared by session keys and Delegate policies.

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 at its slot and can no longer sign. After expiry anyone may close the account and keep its rent (CloseExpiredSession), so revoke it yourself if you want the rent back

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 CreateWallet, Execute and ExecuteDeferred when the protocol fee is configured; when it is not, collection is skipped rather than failing the transaction
• Each fee is capped at 0.01 SOL on chain
• In protocol v2 every paying fee_payer gets a FeeRecord automatically: the SDK prepends a permissionless RegisterPayer to its first fee-paying transaction (protocol v1 tracked only payers registered beforehand)

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 protocol v1 is live on Solana mainnet. In production:

• Seedless — a passkey wallet built on LazorKit, with gasless onboarding. Users create a smart wallet with biometrics in under 10 seconds.

Protocol v2 — ranks and policies, several Owners per wallet, a passkey challenge that names the wallet, CloseExpiredSession, and MigrateWallet for moving v1 wallets — runs on devnet at its own program id. It also carries the fixes from the 2026 audit of the program: fee collection that can no longer freeze funds, passkey authentication that refuses to run through another program, rank checked separately from spending, and a fee payer that inner calls cannot conscript. Its mainnet program is not deployed yet. After it is, the v1 program will be retired to a sunset binary that only lets wallets move out. See Networks & versions and Migrating from v1.

---

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.