Boundless SmartWallet

A minimal, programmable smart account (contract wallet) for the Stellar ecosystem, designed to support flexible authentication, delegation, and recovery — while remaining fully compatible with existing Soroban contracts.

This repo exists to support feature implementation and future extensibility for Boundless and similar protocol-level tooling.

---

Why This Exists

Boundless is designed to be wallet-first but UX-friendly. To support non-crypto contributors, program teams, and advanced workflows, we need a wallet abstraction that:

• Works with passkeys, MPC, and delegated access
• Keeps the wallet as the canonical on-chain identity
• Does not force auth or business logic into application contracts
• Can be introduced without rewriting existing contracts

This SmartWallet contract is that abstraction.

---

Design Principles

• Auth-agnostic: application contracts should not care how auth happens
• Minimal on-chain logic: reduce attack surface
• Upgradeable by replacement, not mutation
• EOA-compatible: behaves like a normal address to other contracts
• Future-proof: supports smart-account features without locking v1 design

---

Non-Goals

This contract intentionally does not:

• Implement bounty, escrow, or reputation logic
• Enforce program-specific rules
• Act as a DAO or governance framework
• Replace application-level permissioning

It is a programmable signer, nothing more.

---

High-Level Architecture

User (Passkey / MPC / Delegate)
        ↓
SmartWallet Contract (this repo)
        ↓
Boundless Contracts (Escrow, Bounties, Reputation)

From the application’s perspective, the SmartWallet is just an Address that can authorize calls.

---

Core Capabilities

• Execute arbitrary contract calls
• Verify authorization via __check_auth
• Support multiple auth keys (MPC, passkey, session keys)
• Delegate limited permissions
• Rotate keys
• Recover access without changing wallet address

---

Contract Overview

Storage (Conceptual)

SmartWallet {
  auth_keys: Vec<AuthKey>,        // primary auth keys (MPC, passkey, etc.)
  threshold: u32,                 // signatures required
  recovery_keys: Vec<Address>,    // recovery authorities
  delegates: Map<Address, Permissions>,
  nonce: u64                      // replay protection
}

---

Core Contract Functions

Initialization

initialize(
  auth_keys: Vec<AuthKey>,
  threshold: u32,
  recovery_keys: Vec<Address>
)

Sets initial control of the wallet.

---

Execute Call

execute(
  target: Address,
  function: Symbol,
  args: Vec<Val>
)

• Executes a call to another contract
• All outbound interactions go through this function
• Authorization is enforced via __check_auth

---

Authorization Hook

__check_auth(
  payload: Bytes,
  context: AuthContext
)

This function:

• Verifies signatures against stored auth keys
• Enforces threshold rules
• Checks nonce / replay protection
• Validates session key scope and expiry (if used)

If valid → execution proceeds If invalid → transaction reverts

---

Delegate Management

add_delegate(
  delegate: Address,
  permissions: Permissions,
  expiry: u64
)

remove_delegate(
  delegate: Address
)

Allows scoped, time-bound delegation without exposing primary keys.

---

Key Rotation

rotate_auth_keys(
  new_keys: Vec<AuthKey>,
  new_threshold: u32
)

Used for routine security maintenance or device changes.

---

Recovery

recover(
  new_auth_keys: Vec<AuthKey>,
  signatures: Vec<RecoverySignature>
)

• Requires M-of-N recovery keys
• Preserves wallet address
• Preserves on-chain reputation and history

---

Authentication Methods

This contract is designed to support:

• MPC-controlled keys
• Passkeys / WebAuthn public keys
• Session keys (short-lived, scoped)
• Multisig / DAO wallets
• Programmatic delegates

All auth methods resolve to a valid signature inside __check_auth.

---

Compatibility

• Fully compatible with:

  • EOAs
  • MPC wallets
  • Other smart accounts

• No special handling required in downstream contracts

• Uses standard Soroban auth primitives

---

Security Model

• No single party controls funds
• No hardcoded admin
• Explicit replay protection
• Recovery without custodial lock-in
• Minimal contract surface area

This contract should be audited independently before production use.

---

Intended Use Cases

• Boundless contributor wallets
• Program admin wallets
• Reviewer / arbiter wallets
• DAO-controlled bounty funds
• Migration target from abstracted wallets

---

Development Status

This repo is:

• Experimental
• Intended for feature development and testing
• Not yet production-hardened

APIs may change before stabilization.

---

Roadmap

• Minimal v1 implementation
• Session key support
• Delegate permission scopes
• MPC compatibility testing
• Migration tooling
• Security audit

This SmartWallet is intentionally boring.