Skip to main content
July 23, 2026 · Kaan Kacar, Developer Advocate

​
Stellar Quest Is Back

Before the guests, some news from the developer ecosystem — starting with a sentence I haven’t been able to say for a while: Stellar Quest is live again. If you’ve been around long enough, you know Stellar Quest was once the most widely shared link between builders in this ecosystem. It’s been broken for some time, mostly because third-party services it depended on sunset their operations (including the one that powered the interactive code lessons). That’s fixed now — it’s live, it’s working, and you can use it to get a genuinely hands-on feel for building on Stellar. Is a click-through learning platform the best use of a developer’s time in the post-AI age? That’s for you — and for our ambassadors — to decide. What I can say is this: building with AI is insanely easy, and the only thing separating you from AI slop is actually knowing the ecosystem you’re building in. You don’t have to write the code by hand anymore, but you do have to know what an account is, what a trustline is, what a SEP-41 token is. Stellar Quest is one way to earn that knowledge. Expect a refined version in the coming weeks, shaped by whatever our ambassadors ask for. On the AI side of the same coin: skills.stellar.org keeps growing. It’s our skills website, but it’s also your skills website — there’s a community section with 17 community skills built by non-SDF people (one of my favorites: a Scout-style skill for researching the ecosystem and SCF before you build), next to 7 official skills, with three more official ones visible in the open-source repo if you go looking. Adding your own is a pull request away — there’s an example skill-card entry in the repo showing exactly how to submit. Building on Stellar with AI gets easier every day; Stellar Quest is there when you want to slow down and actually learn.

​
Guest: Hypertron — Private Payments and Operations for Businesses

This week’s guest was Hypertron (hypertron.space), a programmable operating layer for B2B payments and operations on Stellar — think payments, treasury, and compliance workflows for a business, with privacy as an opt-in layer on top. Sweta and Soumik, the two co-founders, joined from India at 11:47 p.m. their time (self-declared night owls, so it’s fine). Some backstory: the two met in college, ran an agency and freelanced together, and fell into web3 in late 2023 through hackathons — ETHIndia was the first big one. Since then Sweta has worked at a Solana-based company, on early NFT projects on Base, and currently also does security work at Hacken; Soumik has worked for a prediction market on Solana and a payments company. This one was personal for me too: I first met them at a Rise In hackathon in Bangalore about two years ago, on my second day ever in India. I mostly remember the biryanis. Why Stellar? Their answer was better than the usual one. Stellar targets institutional clients and has always been a public blockchain by design — which they think is the right default. Traditional finance is private by default with auditability on request; public blockchains are transparent by default. Hypertron’s whole thesis is to add privacy on top of the public chain, without giving up the verifiability that makes a public chain valuable in the first place. The problem is concrete: once a business runs payroll and vendor payments in stablecoins, anyone — a client, a competitor, a very motivated employee — can trace its treasury. Wallets get poisoned, payments get tracked. That’s the gap they’re filling.

​
The Application Layer

Soumik demoed the product side. There’s a sandbox on hypertron.space so you can poke around before connecting anything, and sign-in is gated behind an invite code they shared live on the stream. You connect with a Stellar wallet (Freighter in the demo) and land in a workspace — and you can manage several, one per business. Creating one is a guided onboarding: pick the business type (protocol, DAO, agency, freelancer), and the modules adapt — an agency doing dev work doesn’t need heavy compliance tooling, a DAO very much does. You choose the operations you want (payments, treasury, risk reports, compliance), invite teammates, wire in integrations like Slack for transaction notifications or Gmail/Notion/Google Drive for the paperwork around employees and invoices, and set your geography so the risk and compliance reports (delivered daily to Telegram or WhatsApp) actually match your market. The payments demo was the simple, satisfying kind: create a payment of 10 XLM with a description, get a payment link, open it from a second wallet, pay — settled near-instantly, tracked in the dashboard. XLM and USDC are supported today, with more assets planned. For real integrations there’s a developer portal with API keys, docs, and an SDK, plus an MCP in the works so you can wire Hypertron into your app from an AI tool in minutes. To make it tangible, Soumik built a demo app that day: a Pokémon NFT marketplace with Hypertron checkout. Buy an NFT, get redirected to the payment link, pay, and a webhook bounces you back to the marketplace with the NFT already in your account. The stablecoin payment stack and APIs are live now, with the full v1 targeted about two weeks out. On monetization: honest answer, still being figured out — likely pay-per-use across the smaller features rather than a cut of payments alone. One of those features is bridging: a business already operating on Ethereum, Solana, or Avalanche can move its treasury over to Stellar specifically to use the privacy payments. That’s a fun acquisition channel if it works.

​
The Privacy Stack

Sweta took the second half, and this is where it gets interesting for protocol nerds. Their framing: privacy isn’t a rule, it’s a spectrum, and it doesn’t start with a circuit — it starts with the question what needs to be hidden. They’ve built a private-payments evaluation framework around six leakage dimensions: sender, receiver, amount, timing, linkability, and metadata. Confidential tokens, for contrast, hide the amount but leave sender and receiver public. Hypertron’s target is linkability — nobody should be able to learn who pays whom — while keeping compliance deliberately open through viewing keys, so an auditor with the right key can still see what regulators need to see. Their privacy matrix today: sender, receiver, amount, and linkability covered; timing still partial (that’s a batching-and-delay problem); compliance intentionally left open. In the app it’ll surface as an opt-in privacy button on otherwise normal transparent payments. The architecture, in one breath: proofs are generated locally (the provers never leave your device), a relayer sponsors fees and submits, commitments land as leaves in an on-chain Merkle tree, and nullifiers handle spend-tracking. Four contracts ship the whole thing — commitments, nullifier, verifier, and a transfer contract that orchestrates shielding, sending, and unshielding with a single integration point for the merchant app. What I liked most is that they’re packaging it twice. For protocol builders there are composable Rust crates — Merkle trees, nullifiers, proof verification, disclosure mechanisms — so you can assemble your own privacy design instead of rebuilding from scratch: relayers plus a ZK pool if you care about sender privacy, confidential tokens for payroll, a mixture with auditing for treasury settlements, pooling-batching-delay for anonymous donations. For application builders there’s an npm package with a compiled WASM prover, so you generate proofs without ever touching the cryptography. Everything leans on the primitives the protocol now ships natively — the BLS12-381 pairings that landed in Protocol 22 and the Poseidon hashing from January’s X-Ray (Protocol 25) upgrade — rather than porting verifier and hashing libraries in. That’s also their differentiation pitch against Nethermind’s SPP shielded pool: shielded pools go back to Zcash in 2016, and Hypertron’s angle is composing the on-protocol primitives instead of shipping a ported stack. When I asked why BLS12-381 over BN254 (the more common choice for shielded pools), the answer was refreshingly honest: not entirely sure yet, the goal is fast verifiable circuits. Pools are per-asset — XLM first, more later. The CLI demo walked the real flow: query the last indexed Merkle root, compute a Poseidon commitment from secret inputs, run the deposit — commitment on-chain, proof generated and submitted, transaction shielded. Then the private-transfer proof failed on an indexing error, live, in front of 200+ people. As regular viewers know the rule by now: you’re not a real builder if your demo works every time.

​
The Fine Print

My PSA from the stream, repeated here for the record: Hypertron is a project in development, running on testnet. These things should happen — that’s the point of showing them — but it’s not a live business yet, so don’t route your company’s treasury anywhere just yet. The open-sourced v2 of the contracts was days away at recording, and viewers were already asking about integration pricing live on the stream, which is honestly the best kind of validation a pre-launch project can get. Follow them at x.com/hypertron_HQ.

​
Closing

X-Ray has been live for about six months now, and privacy on Stellar still fascinates me — we’ve gone from protocol primitives to confidential tokens to shielded pools, and now to teams like Hypertron trying to be the B2B application layer on top of all of it. A private payments product for businesses is a whole different level of hard, and I’d love to see more projects emerge in this lane. We crossed 250 live viewers by the end — thank you for that. Next week I’m planning a session on the cross-chain interop options available to Stellar builders, plus another guest. See you then.