Skip to content

System architecture · Protocol Mode

Authorization stays onchain. The relay only pays and submits.

Lazee Kit separates passkey authorization, scoped sessions, fee sponsorship, intent execution, and app integration.

User / Agent

passkey or scoped session

authorize

Reference App

React PWA

Lazee SDK

TypeScript

React UI Kit

components

signed intent + plan

Sponsor Relay

simulate · sponsor · submit

Intent Orchestrator

quotes · routes · receipts

TRUST BOUNDARY — onchain authorization below

LazeeAccount

__check_auth · signers

SessionRegistry

policy · caps · expiry

GiftVault

escrow · claim · refund

token movement + events

Stellar Network

Soroban · RPC

Indexer & Receipts

event replay + query

Client / userOffchain serviceSoroban contractStellar network

Containers

Containers across three trust zones

Reference App

React PWA

Reviewer demo: account creation, gift link, claim, bridge-in, and DCA session flows

Lazee SDK

TypeScript

Passkey account creation, signing, session grants, intent creation, relay submission, status polling

React UI Kit

React

Passkey login, account creation, gift link creator, claim page, permission preview, session manager

Sponsor Relay API

Node / Bun service

Simulates, fee-sponsors, submits, and tracks transactions with per-app quotas and abuse controls

Intent Orchestrator

Node / Bun service

Normalizes intent schemas, requests quotes, selects routes, and returns readable receipts

Indexer & Events API

PostgreSQL + worker

Queryable state for accounts, sessions, gifts, sponsor usage, intents, and receipts

Passkey Account Contract

Soroban Rust

Custom __check_auth, signer registry, role and nonce checks, and policy hooks

Session Registry Contract

Soroban Rust

Scoped grants: allowed assets, contracts, intent types, caps, expiry, and revocation

Gift Vault Contract

Soroban Rust

Escrows gift funds, validates claims, expires links, and lets senders refund

Observability Stack

OpenTelemetry · Grafana · Sentry

Relay latency, RPC failure, intent status, sponsor spend, and claim completion

Trust model

What the sponsor relay can and cannot do

✓

User approval comes first. Direct actions need passkey or ed25519 authorization through the account contract.

✓

Agents never receive user keys — only a scoped session that is useless outside its onchain policy.

✓

The sponsor relay is never trusted for authorization; it only pays and submits after the user or session authorizes.

✓

Sessions enforce allowed assets, contracts, intent types, caps, expiry, and receiver allowlists — and revoke anytime.

✓

Every session execution emits app id, session id, intent type, amount, and policy counters for audit.

✓

Gift links carry no custody by themselves; a claim requires contract checks plus receiver authorization.

Core flows

Four flows, each reviewable end to end

Passkey account creation

  1. 01App calls SDK discovery by credential or account alias
  2. 02If no account exists, UI starts the WebAuthn passkey ceremony
  3. 03SDK prepares the account deployment transaction
  4. 04Sponsor relay simulates and sponsors the transaction
  5. 05LazeeAccount stores the owner signer and emits AccountCreated
  6. 06Indexer records the account address and app id

Gift link creation & claim

  1. 01Sender signs a gift_create intent and deposits the asset
  2. 02GiftVault escrows funds and emits GiftCreated
  3. 03SDK generates a claim URL with the gift id and proof material
  4. 04Receiver opens the link and creates a passkey account if needed
  5. 05Claim proves the secret, binds the receiver, and transfers funds
  6. 06Expired unclaimed gifts can be refunded to the sender

Bridge into Stellar intent

  1. 01User chooses a source-chain asset and target Stellar asset
  2. 02Orchestrator requests quotes from configured providers
  3. 03UI shows route, fees, expected amount, expiry, and risk note
  4. 04User confirms once with passkey or external wallet
  5. 05Provider settles to the user's Stellar passkey account
  6. 06Indexer and orchestrator return a receipt and recovery steps

Agent DCA session

  1. 01User chooses asset, amount per day, duration, and route limits
  2. 02SessionPermissionModal summarizes the grant in plain language
  3. 03User signs createSession with their passkey
  4. 04SessionRegistry stores the policy and initial counters
  5. 05DCA bot calls executeWithSession on schedule
  6. 06Each run is checked for cap, expiry, route, and revocation

Storage & TTL strategy

  • •Instance config (version, admin, registry addresses) extended during deploys
  • •Account state (signers, recovery, nonce) extended on login and execution
  • •Sessions (policy, spend counters, windows) extended until expiry plus grace
  • •Gifts (record, claim hash, expiry, status) extended until the refund window
  • •A TTL keeper extends required lifetimes; transient caches rebuild from events

Operational architecture

  • •Primary and secondary Stellar RPC with timeout-based failover
  • •Simulation gate before every sponsor signature
  • •Per-app and per-IP rate limits
  • •Per-app sponsor budget and action-type allowlist
  • •Transaction status worker for finality and error classification
  • •OpenTelemetry spans from UI to relay to RPC result