Add Stellar Developer Meeting notes for 2026-06-25 & 2026-07-02

meeting-notes/2026-06-25.mdx

@@ -0,0 +1,54 @@
+---
+title: "2026-06-25"
+authors: kaankacar
+tags: [developer]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="xqBgocb6bCM" />
+
+## Another Doozy of a Week
+
+Before the guests, a quick bit of ecosystem context for why this week felt busy. Per the on-chain data, **Stellar's RWA market cap just crossed $3 billion** — you can see it for yourself on the Dune dashboards. And the ideal Stellar developer meeting, in my book, is one with as many guests as possible, because the conversation I keep having with projects is that they want a real way _into_ the ecosystem. Contributing is one way; introducing yourself on this call is another. This week we had two guests and, with a bit of luck, a new viewer record.
+
+We also had four days left to submit to the **Real World ZK hackathon on DoraHacks** — more on that from our second guest below.
+
+## Guest: Gaian — Stablecoin Rails for Southeast Asia
+
+Our first guest was **Gaian** (gaian.network), a stablecoin payment infrastructure for the APAC region. In one sentence: it's an API that connects crypto wallets to local banking rails using **USDC on Stellar**, moving value between stablecoins and local currencies like the Vietnamese dong to power merchant payments, on/off ramps, and cross-border transfers that settle straight into real bank accounts. Imagine paying for a coffee in Hanoi straight from your Freighter, Albedo, or Beans wallet — that's the promise. Kelvin walked us through it live from Vietnam (at 1 a.m. his time).
+
+Gaian isn't new — the team has been at it for over a year and pivoted twice; what they demoed is the **v2** of the API. They're live across APAC (Vietnam, the Philippines, part of Thailand) plus Brazil and Peru, and in Vietnam and the Philippines they operate as the **anchor themselves**, working directly with the top banks.
+
+### How the Flow Works
+
+There are several actors but only one payment. A consumer holding USDC talks to a wallet; the wallet talks to the Gaian API; Gaian uses the blockchain as the settlement layer and a partner PSP in the destination country to land fiat in the merchant's bank account. Crucially, **the merchant sees no blockchain at all** — they just receive fiat.
+
+### Authentication
+
+The v2 API authenticates every request with an **HMAC signature**. You get an API key and secret from the self-service dashboard, build a canonical message out of the timestamp, method, path, query, and body, HMAC it with your secret, and base64-encode the result. Every request must carry that signature and timestamp.
+
+### The Order Lifecycle
+
+There are two halves — onboarding a user, then placing an order:
+
+1. **Onboarding.** Create a user (`POST /v2/users`), associate a wallet address to that user (the address is just a string — the wallet provider controls it), then generate a **KYC URL** for the user (providers vary by country) and poll their status by ID or wallet address until it's approved.
+2. **Payment.** Ask Gaian for a code by passing the scanned **QR string**, the fiat amount, and the user's wallet address. Gaian returns a code ID, the fiat amount, the total (including the bank's processing fee), the exchange rate, and the decoded bank details. Then **place the order** with that code ID — Gaian returns an order ID, a status label, the settlement wallet address, and the token address (USDC today). The wallet **signs and broadcasts** the USDC transfer to the settlement wallet (not an API call), and finally notifies Gaian with the transaction hash so Gaian can verify it on-chain and mark the order settled (there's no automatic chain listener yet). There's also a **prefund** flow where a wallet pre-funds stablecoin with Gaian.
+
+### The Demo
+
+Kelvin ran the whole thing live from a Bruno collection and a demo wallet, paying ~21,000 VND (under a dollar, with a small minimum bank fee) to a real Vietnamese bank account. The first code expired mid-explanation — a hazard of a good demo — and re-verifying settled it. The real headline: the **self-service dashboard** means any viewer can sign up, grab API keys, and integrate Gaian's payment capability into their own wallet without ever talking to sales, up to a ~$4,000 cap before KYB is required.
+
+Gaian went **live on Stellar** the previous Friday, and for now it's mainnet-only — going fast to production rather than testnet-first. The one thing I asked for repeatedly (and will keep pestering them about) is a **self-service sandbox on testnet**, so we can amplify Gaian as an anchor to builders across the Philippines and Vietnam.
+
+## The Real World ZK Hackathon
+
+Our second guest was **Jeremy** (also known as J Romero), the ecosystem partner running the **Real World ZK hackathon** on DoraHacks. The scope is deliberately wide open: anything that touches zero knowledge on Stellar qualifies — privacy pools, private payments, confidential tokens, verifiable computation, even ZK games.
+
+The news he dropped live: for the first time ever, they **extended the deadline** by about a week, so it lands just before the US holiday (giving builders more time and keeping judging off the judges' holiday plates). The prize pool is **$10,000 in XLM** across five places ($5,000 for first down to $750 for fifth), plus a random $100 in XLM for someone who fills out the feedback survey. Requirements are light — an open-source repo and a short demo video.
+
+Everything runs on **DoraHacks** (search "Stellar"), but the real hub is the dedicated **Telegram group** (1,000+ people), where ecosystem ZK teams — Nethermind, Boundless, OpenZeppelin, Aztec — hang out to help. A prolific builder who's won three prior Stellar hackathons (including the ZK Gaming one) is helping as a mentor this round. There's also a resources tab on the hackathon page you can point your AI at, and office hours were being scheduled. Jeremy's parting advice: don't let AI name your project (three teams showed up with identical AI-generated names), and build the thing _you're_ passionate about — Stellar has always been about local builders shipping local solutions.
+
+## Closing
+
+I also gave a shout to the **Pulso hackathon** in São Paulo (on DoraHacks), whose prize includes a fully sponsored trip to the Stellar Summit, with live pitches across Argentina, Brazil, and Colombia. I'd planned to close with a live `stellar-build` session — using the Justin and Nicole personas to show off the new self-running loop and spin up a ZK project idea — but at 75 minutes and seven cups of coffee deep, I saved it for next week. Next week we also have another guest, so please be there.

meeting-notes/2026-07-02.mdx

@@ -0,0 +1,61 @@
+---
+title: "2026-07-02"
+authors: kaankacar
+tags: [developer]
+---
+
+import YouTube from "@site/src/components/YouTube";
+
+<YouTube ID="N7PtAJaELzA" />
+
+## A Week About Privacy
+
+This week wasn't about AI — it was about your second-favorite subject: **privacy**. Per the Electric Capital developer report there are now more than **2,000 developers building on Stellar** in a given week, and hopefully you're one of them.
+
+Two reasons privacy was the theme. First, there was exactly **one day left** to submit to the Real World ZK hackathon on DoraHacks — the best possible time to be building with zero knowledge. Second, an hour before the call we published the **developer preview of confidential tokens** on Stellar, which pairs naturally with this week's guest. So the plan was: guest first, then a plain-English tour of confidential tokens.
+
+## Guest: Zarf — Private Token Distribution by Email
+
+Our guest was **Zarf** (zarf.to), a Turkish project that lets you distribute tokens to an **email address** rather than a wallet address. Recipients claim with a familiar "sign in with Google" button, and their browser quietly proves they own that email using a zero-knowledge proof — so the recipient's wallet is never linked to a person, and nothing on-chain says who received what. This was a special one for me personally: **Yaman**, one of the founders, is the first person I ever met in web3, at my first hackathon a bit over four years ago.
+
+Yaman introduced Zarf alongside **Dennis**, who has spent three to four years in the ZK space (previously an exploration engineer at O1 Labs on the Mina protocol, and before that in web2 cyber security). The team builds things that are only possible with zero-knowledge proofs, and got excited about Stellar once the protocol gained **native, cheap ZK-proof verification** — with the heavy elliptic-curve math implemented as protocol-level precompiles, verifying a proof on Stellar became genuinely inexpensive.
+
+### The Problem
+
+When you send tokens on a blockchain, the recipient's wallet is always exposed. In token distributions and private sales, anyone can watch who claimed what — a strong signal for whales-watching and an easy way to get doxxed. Zarf's origin was a hackathon project at Devconnect in Buenos Aires: a proof-of-attendance tool that let you _prove_ you'd attended an event via an email you received, then mint it as a POAP-style NFT. That grew into the more general idea of using an identity you already have — a Google account — for private, programmable token distributions.
+
+### How It Works
+
+The primitive underneath Zarf is **ZK JWT** — zero-knowledge proofs over the JSON Web Token that Google signs when you log in. When you sign in with Google, Google digitally signs your JWT; inside the circuit, Zarf verifies that signature against Google's published public keys, confirms the key really belongs to Google, and parses your email — all in zero knowledge. That proof then lets you **claim from any wallet you like**, and different claims can come from totally unlinked wallets (wallet A for one batch, wallet B for the next), even a single-use stealth address.
+
+Dennis was careful to distinguish ZK JWT from **ZK email**: ZK email proves the signature of an email's _sender_, while ZK JWT is specifically for authentication and identity. They prefer ZK JWT because the UX is far better — no forwarding emails or uploading `.eml` files; you just open the page and log in with Google, and the proof is generated behind the scenes.
+
+The best framing we landed on: Zarf is a **privacy-focused version of the Stellar disbursement platform** — instead of handing over a CSV of wallet addresses, you hand over emails, and people claim from whatever wallet they want, so nobody can track balances or link an identity to a wallet.
+
+### The Architecture
+
+A few implementation details worth capturing:
+
+- **Proof system.** Zarf uses **Noir** rather than Circom. Noir brings faster proof generation and, importantly, **no per-circuit trusted setup ceremony** (it relies on a universal setup instead).
+- **Four contracts.** A factory, a vesting contract, a verifier contract (invoked on every claim to check the proof), and a **JWK registry** that holds Google's public keys.
+- **The Google key-rotation challenge.** Google rotates the public keys that sign JWTs roughly every two weeks (not exactly, and not all at once). Zarf runs a **Cloudflare worker** that fetches the current keys and writes them on-chain so verification stays valid. This is the biggest open problem; the team is exploring more trustless approaches (e.g. zkTLS to prove the certificate URL directly) and even offering a shared Google-certificate registry as a public good for the whole ecosystem.
+- **The privacy model.** To break the email↔wallet link, Zarf parses your email from the JWT, generates a secret **pin code**, hashes the pin, hashes your email, and places the hashed identity in a **Merkle tree**. At claim time the circuit verifies the Google-signed JWT, derives your unique identifier, walks the Merkle proof to the root, and compares that root against the distributor's on-chain vesting contract. The pin prevents anyone who merely knows your email from brute-forcing to find you in the tree.
+
+### The Demo
+
+Yaman created a live token distribution on testnet — upload an email list, auto-build the Merkle tree, set a vesting schedule, deploy — then tried to claim. Proof generation and some caching got in the way and the claim didn't land cleanly on the call (it had worked in rehearsal). As I like to say: you're not really a builder if your demo works every time. It's a fine reminder of exactly why beta testers matter — better to get roasted in private than in front of 250 live viewers. Zarf is **SCF cohort 42**, heading to mainnet after its audit (likely within the week), and looking for beta testers via zarf.to and X (@zarf).
+
+## Confidential Tokens: The Other Half of Privacy
+
+After the guests left, I did a "so what?" walkthrough of the **confidential token rails** we previewed that day, built by OpenZeppelin — because Zarf and confidential tokens solve two _different_ privacy problems and it's worth seeing the contrast:
+
+- **Zarf hides identity.** The email↔wallet link is never revealed. But once a claim lands, the recipient's wallet, the amount, and the claim event are all still public on-chain — fine in many cases, problematic in others.
+- **Confidential tokens hide amounts.** Instead of storing a plaintext balance, the token stores each balance as an **encrypted commitment**. Transfers move encrypted amounts and carry a zero-knowledge proof that the transfer is _valid_ (the sender had enough, the amount is a positive integer, inputs equal outputs) **without revealing any of the amounts**. Only the holder — and optionally an **auditor** who holds a decryption key — can read the balance, which is how you'd add a compliance layer.
+
+The mental model is a handful of methods: **register, deposit, merge, transfer, withdraw**. To participate at all you first **register** (a one-time zero-knowledge proof generated locally in the browser). You then **deposit** public tokens into your encrypted balance, **merge** received amounts so they become spendable, and **transfer** confidentially. Confidential tokens behave like SEP-41 tokens, so in theory they compose — but they're best at **additive accounting** (adding and subtracting amounts), and not the right tool for multiplication, price discovery, or deep public composability, where time-sensitive proof generation gets in the way. This is a confidential _token_, not a dark pool that hides the operation itself.
+
+To make it concrete I vibe-coded a tiny **confidential wallet** for the meeting — two accounts, Alice and Bob — that walks through registering, depositing public XLM into an encrypted balance, merging, and then transferring confidentially so nobody can see how much moved. It reuses OpenZeppelin's confidential-token contract from the developer preview, so I was cutting corners, but it makes the flow tangible. The GitHub link is in the stream, and the real source of truth is the developer preview itself.
+
+## Closing
+
+With ~20 hours left on the Real World ZK hackathon deadline and a strong turnout of hackers, there was still time to ship something small and submit. Next week's guest is Hyperron. Thanks for watching — see you then.

routes.txt

@@ -907,6 +907,8 @@
 /meetings/2026/05/21
 /meetings/2026/06/11
 /meetings/2026/06/18
+/meetings/2026/06/25
+/meetings/2026/07/02
 /meetings/archive
 /meetings/authors
 /meetings/authors/carstenjacobsen
@@ -919,6 +921,7 @@
 /meetings/page/4
 /meetings/page/5
 /meetings/page/6
+/meetings/page/7
 /meetings/tags
 /meetings/tags/developer
 /meetings/tags/developer/page/2