​
June 10, 2025
v1.1.0

​
New Features

  • Passkey Support (WebAuthn)
    • Added support for passkey-based authentication and signing using the industry-standard WebAuthn protocol.
    • Users can now create and authenticate passkeys (biometric or hardware-backed) as Smart Account signers, eliminating the need for traditional private key management.
    • Secure session tokens enable seamless, passwordless transaction signing across web and mobile.
    • Passkeys can be integrated into any Smart Account operation as a signer.
    • See Passkeys Introduction and Integration Guide for details and code examples.

​
Migration Guide

  1. Integrate Passkey Flows
    • Use the new /api/v1/passkeys endpoint to create or authenticate passkeys via a hosted WebAuthn UI.
    • On successful authentication, use the returned session token and onchain passkey address as a signer in Smart Account operations.
    • For web, embed the hosted UI in an iframe; for mobile, open in a browser session.
    • See the Integration Guide for best practices and code samples.
  2. Update Signer Logic
    • Passkey addresses can be used anywhere a transaction signer is required.
    • Use the session token to sign Smart Account transactions for authentication.
​
March 3, 2025
v1.0.0

​
New Features

  • RESTful API Design The v1 API follows standard REST conventions with a clear resource hierarchy:
    • Consistent URL patterns with resource-based endpoints
    • Standard HTTP methods (GET, POST, PATCH, DELETE)
    • Improved response formats and error handling
  • Admin Control
    • Optional admin address for settings management. See Admin Control for more details.
  • Idempotency Support
    • Added x-idempotency-key header for account creation to prevent duplicates
    • Status tracking for idempotent requests
  • Improved Gas Abstraction
    • Pay transaction and rent fees from the Smart Account by setting it as the payer_address in the fee_config
    • Added support for USDT as a payment token. Use usdt in the fee_config to pay with USDT.

​
Breaking Changes

  • API Path Structure (High Impact) All endpoints now follow RESTful conventions with a clear resource hierarchy. Examples: Examples of endpoint changes:
    • /api/v0/smart_account/transaction/create → /api/v1/smart-accounts
    • /api/v0/smart_account/transaction/threshold/update → /api/v1/smart-accounts/{address}
    • /api/v0/smart_account/transaction/spending_limit/create → /api/v1/smart-accounts/{address}/spending-limits
  • Request Body Format (High Impact)
    • Snake case is consistently used throughout the API
    • Standardized parameter naming
  • Response Format (Medium Impact)
    • Standardized success and error responses
    • Consistent error object structure with code, message, and details
    Before (v0): 
    {
  "error": "Invalid request parameters"
}
    After (v1): 
    {
  "error": {
    "code": "ERROR_CODE",
    "message": "Human readable message",
    "details": {
      // Additional context
    }
  }
}

​
Migration Guide

  1. Update Request Paths (High Priority)
    • Convert all endpoints to follow the new RESTful pattern
    • Use proper HTTP methods (GET, POST, PATCH, DELETE)
    • Move smart_account_address and spending_limit_address to the url path
    • Example: 
      // Old way (v0)
api.post("/api/v0/smart_account/transaction/create", {...});

// New way (v1)
api.post("/api/v1/smart-accounts", {...});
  2. Update Error Handling (Medium Priority)
    • Adapt to the new error response structure
    • Check for error.code in addition to error messages
  3. Add Idempotency for Critical Operations (Low Priority)
    • Use the x-idempotency-key header for account creation
    • Handle idempotency response status
​
January 13, 2025
v0.1.0

​
New Features

  • Improved Smart Account Creation Creating smart accounts is now simpler and more cost-effective:
    • No transaction submission required
    • No transaction fees to pay
    • Instant account creation
    • Streamlined response with just the account address

​
Breaking Changes

  • Request Body Restructuring (High Impact)
    All configuration endpoints now expect smart_account_address at the top level of the request body.     Affected endpoints:
    • /api/v0/smart_account/transaction/threshold/update
    • /api/v0/smart_account/transaction/signers/add
    • /api/v0/smart_account/transaction/signers/remove
    • /api/v0/smart_account/transaction/spending_limit/create
    • /api/v0/smart_account/transaction/spending_limit/update
    • /api/v0/smart_account/transaction/spending_limit/use
    Before: 
    {
  "meta": {
    "smart_account_settings_address": "AbCd...XyZ"
  },
  "threshold": 2,
  "transaction_signers": ["Signer1", "Signer2"]
}
    After: 
    {
  "smart_account_address": "AbCd...XyZ",
  "threshold": 2,
  "transaction_signers": ["Signer1", "Signer2"]
}
  • Create Smart Account Response (High Impact)
    The /api/v0/smart_account/transaction/create endpoint now provides a streamlined experience:
    • No transaction submission required
    • No fee handling needed
    • Instant account creation
    Before: 
    {
  "smart_account_address": "AbCd...XyZ",
  "transaction": "base64...",  // Required manual transaction submission
  "fee": {
    "amount": "1000",
    "amount_decimal": "0.000001",
    "currency": "sol"
  }
}
    After: 
    {
  "smart_account_address": "AbCd...XyZ"  // Ready to use immediately
}

​
Migration Guide

  1. Update Request Bodies (High Priority)
    • Move smart_account_address to the top level
    • Remove all nested metadata structures
    • Example for updating threshold: 
      // Old way
const oldRequest = {
  meta: {
    smart_account_settings_address: settingsAddr,
  },
  threshold: 2,
};

// New way
const newRequest = {
  smart_account_address: accountAddr,
  threshold: 2,
};
  2. Update Create Smart Account Integration (High Priority) - Remove transaction submission logic - Remove fee handling code - Account is ready to use immediately after creation - Only expect the smart account address in response