Cowrie Research

magic

3 min read

Magic

  • Name: Magic
  • URL: https://magic.link/
  • Category: wallet-and-auth infrastructure company / embedded-wallet operator / authentication-and-server-wallet workflow platform
  • Tags: ethereum-ecosystem solana-ecosystem bitcoin-ecosystem
  • Summary: Magic belongs as an entity note, not a protocol note. The useful cut is that a named company operates a hosted auth-and-wallet control plane spanning passwordless login, DID-token issuance, embedded-wallet creation, server-wallet policy, recovery handling, and custody-mode packaging. The practical leverage lives in the company-run authentication and wallet workflow rather than in any standalone onchain account primitive.
  • What it does:
    • Provides embedded-wallet infrastructure with passwordless onboarding flows including email, SMS, social login, and other identity-linked sign-in methods
    • Issues DID-token-based authentication artifacts that applications can use for authorization between client and server
    • Offers server-side wallet products for backend-managed wallet creation and transaction flows
    • Packages multichain wallet support across EVM chains, Solana, and Bitcoin-adjacent flows inside one hosted developer platform
    • Ships SDKs, docs, and operational guidance that make Magic part of the live auth, session, and signing workflow rather than a thin front-end convenience layer
  • Key claims:
    • Magic positions itself as both embedded-wallet infrastructure and server-side wallet management, which makes it more than a narrow login SDK
    • Official materials describe passwordless auth, embedded-wallet onboarding, and DID-token-based authentication as first-class product surfaces
    • The Core API docs say server-side wallet management uses AWS Nitro TEE security plus key sharding
    • The docs explicitly note that deployments can land in either custodial or non-custodial territory depending on encryption context and shard handling, which is a strong reason to preserve the operating-entity boundary rather than flatten everything into a generic wallet note
    • Public docs and GitHub materials show Magic shipping a broad integration surface across client SDKs, server tooling, and documentation rather than only a consumer wallet app
  • Whitepaper: No classic standalone whitepaper or litepaper is the important artifact here. The strongest primary materials are Magic’s official docs, the specific server-wallet and DID-token documentation pages, and the public SDK / documentation repositories; see ../whitepapers/magic-primary-sources-2026-04-26.md.
  • Sources:

Internal linkages

  • Project-layer alias: magic.
  • Keep the comparison set on the stronger hosted auth-and-signing operator reads: privy and turnkey.
  • Useful adjacent wallet-session packaging read: reown.

Protocol / company boundary

  • There is no especially useful standalone Magic protocol boundary doing the analytical work here.
  • The important surface is the company-run auth, wallet, and server-signing workflow: login issuance, DID-token semantics, key-management mode, recovery handling, and custody packaging.
  • That is why this note belongs in companies/: the useful question is who operates the authentication and wallet-control plane that downstream apps trust, not whether Magic is a neutral protocol primitive.

Control surface

  • Practical leverage sits in login issuance, DID-token verification semantics, server-wallet policy, custody-mode configuration, recovery workflow, SDK defaults, and which user actions applications are willing to trust based on Magic-authenticated sessions.

  • The sticky dependency is not only key storage. It is the combined auth-and-wallet workflow that decides how identities become sessions, how sessions become signing authority, and how recovery or server-managed operations are handled when something goes wrong.

  • Read Magic as a company-run authentication and wallet operator surface, not as a durable account substrate.

  • Last reviewed: 2026-08-08 UTC

Graph View

Backlinks