Decentralization

The Stellar Passkey Kit is engineered so that no part of it can become a single point of control or failure between an end-user and their on-chain account. This document explains where that property holds, where it does not, and what the deliberate boundary choices are.

The kit is a library, not infrastructure

@stellar-passkey/core, @stellar-passkey/ui, and the forked @creit.tech/stellar-wallets-kit PasskeyModule are all client-side TypeScript/Lit code that ships to the user's browser. No long-running server is operated by the project, and the kit's runtime functionality does not depend on any such server existing. If every machine maintained by the maintainers vanished tomorrow, every installed copy of the kit would continue to work, sign transactions, and recover wallets exactly as it does today.

Where the keys live

The private half of the user's P-256 keypair is generated by the device authenticator (Apple Secure Enclave, Microsoft TPM, Android StrongBox, hardware security key) and is non-extractable by design. The kit never sees it, never asks for it, and cannot transmit it. Likewise, biometric templates (fingerprint, face geometry) never leave the secure element. The only material the SDK handles is the public half of the keypair (65 bytes, SEC-1 uncompressed) plus per-ceremony WebAuthn assertion bytes — neither of which is sensitive after issuance.

Where the account lives

Each user's wallet is an on-chain Soroban smart-account contract that the user controls. There is no shared custodial wallet, no multi-tenant database row, and no "kit account" the user shares with other users. The contract's address is deterministic from (deployer, salt, walletWasmHash); the user can recover it from on-chain ("sw_v1","add", credentialId) events without consulting any project-operated service.

Optional, opt-in off-chain coordination

Two off-chain helpers are opt-in and not operated by this project:

1. Soroban RPC — talking to Stellar testnet/mainnet. The kit defaults to https://soroban-testnet.stellar.org; consumers may substitute any compliant RPC (self-hosted, third-party, future community providers). This is a network requirement of the Stellar chain itself, not a centralization of the kit.
2. Launchtube-style fee sponsorship — the DeployerCallbacks shim lets the consumer wire a fee-sponsoring relay so users can create wallets without holding XLM. The kit ships zero default sponsor; it is purely a seam.

Neither helper holds user credentials, neither can sign for the user, and neither is mandatory.

Non-goals

The kit explicitly does not attempt to decentralize the things that are not the kit's job: the underlying Stellar consensus (Federated Byzantine Agreement), the WebAuthn attestation chain (each authenticator manufacturer maintains its own roots), or the Cloudflare CDN serving the docs and reference demo. Those are inherited trust-anchors of the broader ecosystem; the kit's contribution to decentralization is to add nothing new to that list.