Rhinestone

• Name: Rhinestone
• URL: https://www.rhinestone.dev/
• Category: smart-account tooling / delegated-permission modules / routed execution middleware
• Tags: ethereum-ecosystem
• Summary: Rhinestone is a smart-account toolkit with a routed-execution layer attached. Useful note, but not a category anchor. The account side matters; the sharper question is which permissions remain onchain and which routing, solver, deposit, and fallback decisions get pushed into Rhinestone’s hosted middleware.
• What it does:
  • Provides a smart-wallet SDK for deploying and managing modular smart accounts with passkeys, multisig, recovery flows, and session-key-style automation
  • Exposes an intent engine called Warp that routes cross-chain transactions through a solver / relayer market and hides manual bridging from the end user
  • Supports API-first usage for teams that want routing without taking the full wallet SDK
  • Offers deposit infrastructure, a deposit widget, portfolio endpoints, chain/token discovery endpoints, and orchestration/status APIs in the public docs surface
  • Publishes audit references and repositories for modules such as registry, safe7579, core modules, nexus, and Smart Sessions
• Key claims:
  • Rhinestone describes itself as a smart wallet SDK plus cross-chain intent API, with one integration for wallet deployment and transaction routing across supported chains
  • Warp docs claim fast destination-side execution with asynchronous origin-chain settlement afterward
  • The docs stress ERC-7579 compatibility, signer-agnostic integrations, and API-first access to routing
  • Smart Sessions materials frame delegated permissions as a path to one-click UX and automated transactions under granular policy controls
  • Supported-chains docs show broad EVM coverage, which makes the operational-routing layer more important than the wallet-SDK veneer suggests
• Whitepaper: No classic whitepaper or litepaper was found during this pass. The main source of truth appears to be the official docs portal, supported-chains/resources pages, and linked audit-report materials; see ../whitepapers/rhinestone-primary-sources-2026-04-22.md.
• Sources:
  • https://www.rhinestone.dev/
  • https://docs.rhinestone.dev/home/introduction/what-is-rhinestone
  • https://docs.rhinestone.dev/home/introduction/rhinestone-intents
  • https://docs.rhinestone.dev/smart-wallet/smart-sessions/overview
  • https://docs.rhinestone.dev/home/resources/supported-chains
  • https://docs.rhinestone.dev/home/resources/audit-reports
  • https://docs.rhinestone.dev/llms.txt

Internal linkages

• Best upward comparison points: biconomy, safe, and alchemy.

Governance / control risk

• The account side is only half the story.

• The other half is who controls routing, reachable solvers and relayers, deposit handling, fallback paths, and how much visibility the developer gets after signature.

• That is the useful cut: not SDK vs API, but which parts are contract-enforced and which still sit inside Rhinestone’s hosted execution layer.

• In practice this reads more like routed execution middleware than a new wallet substrate.

• Last reviewed: 2026-05-30 UTC