Skip to main content

2026-08-20

· 10 min read
Kaan Kacar
Kaan Kacar
Developer Advocate

Why Wallets, Why Now​

This week was a coding session rather than a project spotlight: six wallet infrastructures, one demo app, and a running list of gotchas for each. The topic came straight out of the Builder Summit in Brazil, where I spent a week with the local builders and our partners at NearX. Watching what people shipped reminded me of a pattern I had been noticing in Turkey and had assumed was a local quirk. It is not. Worldwide, when builders ship something on Stellar — at a hackathon or in an SCF application — they reach for the Stellar Wallets Kit almost by reflex, because a modal full of extension wallets feels like building on EVM.

The kit is great and I am not here to talk you out of it. But a site that demands "connect your wallet" the second you land on it is a bit of a red flag, and extension wallets are the default in Web3 only because nobody questioned it. I would love to see more experiments with C-addresses, smart accounts, and passkeys, and above all with social login — connect with Google or an email code and you are in. So I built a small gallery app that wires the same flow (show the wallet anatomy, fund with Friendbot, swap XLM to test USDC through Soroswap's router contracts, sign a payment) through each of six kits, and walked through what each one does under the hood. The code is public: kaankacar/stellar-wallet-gallery. If you want the whole thing as a single skill, tell me — skills.stellar.org was at 29 community skills alongside the official ones as of this call, and I am happy to add another.

One housekeeping item before the code: testnet upgrades to Protocol 28 next week, around this same time on Thursday. The chain keeps running, but do not pin your project config to Protocol 27, and maybe take a 30-minute break instead of testing right through the upgrade window. Better safe than sorry.

Stellar Wallets Kit: The One You Already Use​

Nothing new here, so I kept it short. The kit bundles the extension and hardware wallets — Freighter, Albedo, xBull, LOBSTR, Hana, Rabet, Ledger, Hot Wallet, Bitget, and friends — behind one modal, needs no API keys, and only ever talks to classic G-accounts. The flow is the one you know: the dApp loads the source account's sequence number from Horizon, builds a classic transaction, hands the XDR to the wallet, the wallet asks you to approve, the signed XDR comes back, and the app submits it to Horizon or RPC.

Two gotchas worth saying out loud:

  • Set the network explicitly. If you leave out the network: testnet line when you initialize the kit, your Freighter or Hana wallet connects on mainnet by default. Check that line before you test, whether you wrote the code yourself or an agent wrote it for you.
  • Use v2, and check that you actually are. For the newer builders: there is a v1 and a v2, and yes, we know the payments example in our own documentation still uses v1. We are fixing that; you should be on v2 today.

The default modules work with zero config. Only Trezor and WalletConnect need app credentials, so either add those or drop the two modules and ship with the defaults.

Blux: Pretty, Customizable, and a Little Rough​

Blux has a special place in my heart — it is a Turkish project, SCF-funded about a year ago, and it is a connect kit that onboards users through extension wallets and email, phone, Google, or passkeys. The dashboard at dashboard.blux.cc is genuinely lovely: accent colors, backgrounds, fonts, borders, your own logo, and you can trim the login options down to just Google or just email if that is all your app wants. I live-demoed my own app ID and secret on stream, so that got rotated right after the call. Learn from me.

Under the hood Blux still creates a classic G-account with an Ed25519 key pair. When you log in with email, SMS, or Google, Blux manages that key. That is the trade-off every social-login product makes, and Matias in chat asked the fair question: what happens if Blux disappears tomorrow and they are the custodian? I did not have an answer, and I would love to have the Blux team on a future call to give one.

The gotchas I hit:

  • Social login is off by default. Email, SMS, Google, and passkey have to be enabled explicitly in the config, or you have just installed another wallet kit.
  • The login modal has no close button, and the signing overlay locks page scroll, so you cannot dismiss it or move around the app without a refresh.
  • Soroban transactions through the overlay resolved maybe half the time in my testing. I have not dug into why.
  • Blux is React only, the provider must not be mounted without a real app ID (the ID is validated server-side on every auth call), avoid React strict mode, and the npm README is stale.

The workaround that made the demo work: set showWalletUIs to false and let the swap go through silently. One XLM in, 2.48 test USDC out, no overlay. Matias summarized the whole section better than I did: pretty colors and customization are not a trade-off for bad UX. Agreed, and the colors are still pretty. Blux team, if you are reading this, consider it an audit with love.

Privy: Social Login Done Properly, With One Caveat​

You know Privy from EVM. What fewer people know is that it supports Stellar: embedded wallets powering 120 million-plus accounts, with email and social login out of the box. Stellar is a Tier 2 chain in Privy's model. Tier 1 is raw cryptographic signing (Bitcoin and the other Ed25519 chains), Tier 2 adds wallet abstractions, and Tier 3 is full end-to-end client support (Ethereum, Solana). Tier 2 is exactly what we need: Privy signs, but your app builds the transaction.

The flow is elegant. The login opens Privy's modal, an email code creates a wallet inside Privy's key infrastructure, your app builds the XDR and sends only the raw transaction hash to Privy, Privy signs it and returns a hex signature, the dApp converts it to base64, attaches it, and the Stellar SDK verifies it client-side before accepting it. The key never touches the browser's JavaScript, the app only ever sees the address and the signature, and by the time Horizon or RPC sees the envelope it is a perfectly ordinary classic payment. The key does live in Privy's infra, but it is exportable by the user at any time, which is a working mitigation.

Gotchas:

  • If you come from Privy on EVM or Solana you are used to the createOnLogin config. On Stellar (and every other Tier 2 chain) you call createWallet with chainType: "stellar" instead. Get that right and you are good.
  • You still need an app ID from dashboard.privy.io or nothing works.
  • Second-hand, unverified, filed under gossip: two builders told me Privy gets slow once you are scaling to tens of thousands of users. I have not seen it myself. If you have that problem, congratulations on the problem, and go experiment with the other kits.

Para: MPC, Finally​

Para is the newest of the four I demoed on Stellar, and the reason I love it is one acronym: MPC, multi-party computation. With Blux and Privy your social-login key lives in their infrastructure. With Para the key is born as two shares — one in your session, one on Para's network — and the full key never exists anywhere. Signing is a ceremony: the app sends the transaction to Para's MPC network, the two shares compute a signature together without either side ever seeing the whole key, and the fully signed envelope comes back for the dApp to submit. In a world where every conversation is ZK and fully homomorphic encryption, seeing good old MPC in production is refreshing. It was the first cryptographic idea I understood as a new Web3 developer, so I am biased.

Setup: create a project at developer.getpara.com, copy the beta API key, done. The free plan covers 1,200 monthly active users and 30 REST requests per minute, which is more than enough to evaluate it. From the user's side it looks like Privy — phone or email, no seed phrase, no overlay on the swap — and the createWallet call is the same shape.

Gotchas, in order of severity:

  • Same mainnet trap as the wallets kit: if you do not pass the network passphrase into the Para signer hook, it defaults to the public network.
  • Para's SDK currently pins stellar-sdk 14.6.1 while my project is on 16. As long as only XDR strings cross the boundary it does not matter, but it could.
  • The SDK lazily imports ethers even when you only use Stellar. You never touch EVM, you still download it.
  • I could not find an export option for your share of the key. In principle you should be able to take your share and do the computation locally; check developer.getpara.com for the current answer.

Matias made the point that a wallet relying on a backend is a bad wallet, and it is the honest trade-off of this whole meeting. In Web3 you can own everything — the seed phrase, the key, the money — but the onboarding will never feel like signing in with Google. Every kit above picks a different spot on that line. Pick yours knowingly.

One Thing Every Social-Login Kit Shares​

When you connect Freighter, you bring an account that already exists. When Blux, Privy, or Para create a G-account from scratch for a Google or email login, that account is unfunded, even on testnet. Hit Friendbot before you do anything else, or you will drown in errors that look unrelated. Most of you know this; with over 170 viewers on the call and a lot of new Stellar builders in the ecosystem, it was worth saying.

Passkey Kit vs. Smart Account Kit​

I ran out of time for a deep dive, so here is the differential. Both give you C-addresses (smart accounts) instead of G-accounts. Passkey Kit is ours and it is hackable: build any kind of transaction, run your own relayer, customize everything. Smart Account Kit sits on OpenZeppelin's audited smart-account contracts and gives you multi-signer auth, policies, and the rest out of the box, maintained upstream. More control, Passkey Kit; more batteries included, Smart Account Kit. If you want a dedicated workshop on either, ask in the Stellar Developers Discord.

Closing​

Adrian in chat brought up Cavos, another embedded-wallet layer with Stellar support that I had not seen yet. We will give it a proper look in a future meeting. We ended around 200 viewers, I promised to drop the gallery repo in the comments, and I meant it when I said I want more of these strictly-coding sessions — comparing infrastructures side by side instead of only showcasing projects. If there is a comparison you want next, say so. See you next week.