Add Stellar Developer Meeting notes for 2026-07-16 through 2026-08-13 - #2751
Conversation
There was a problem hiding this comment.
Pull request overview
Adds five missing July–August 2026 Stellar Developer Meeting notes and corresponding generated routes.
Changes:
- Adds recordings and summaries for Raven, Hypertron, CCTP, confidential tokens, and Builder Summit winners.
- Updates meeting routes.
- Requires corrections to confidential-token auditor and event-recovery guidance.
Recommendation: NEEDS-CHANGES — address the three technical inaccuracies in 2026-08-06.mdx.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
meetings/2026-07-16.mdx |
Adds Stellar Raven meeting notes. |
meetings/2026-07-23.mdx |
Adds Hypertron and Stellar Quest notes. |
meetings/2026-07-30.mdx |
Adds CCTP demonstration notes. |
meetings/2026-08-06.mdx |
Adds confidential-token Q&A notes. |
meetings/2026-08-13.mdx |
Adds Builder Summit winner notes. |
routes.txt |
Registers the five meeting routes. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
|
|
||
| Alex layered the intent on top: there's **selective disclosure**, which is user-initiated ("I can prove this payment happened to whoever I choose"), and there's compelled revelation through the auditor key. The intention is _not_ that someone sits watching the pool — the auditor key should sit unused inside an **MPC or TEE custody setup** (think Utila or Fireblocks, not a Freighter wallet) and only answer scoped requests when a regulator compels one. A single auditor address does not mean a single person; put real key management on it. Alex would be shocked if you didn't. | ||
|
|
||
| Then the fun one. Alberto of **Trustless Work** (the escrow project) showed me a confidential-marketplace experiment that day — an escrow contract between Alice and Bob — and asked whether one auditor holding four keys across four "auditor channels" was the simplest compliant setup. The panel's honest answer: the question doesn't quite map onto the design. To Alex's understanding there's one global auditor key per confidential token contract, "channel" is an overloaded word Jay wanted more context on, and the escrow case probably wants selective disclosure rather than extra auditors — to be continued on Discord once the project ships. |
There was a problem hiding this comment.
Verified against the OZ implementation (auditor registry contract, per-account auditor_id bound at registration, registry reusable across tokens) and fixed in a954d08 — the panel's on-call answer is kept as reported, with the current-model correction added inline.
|
|
||
| ## Wallet Hygiene: Retention Windows and Replay | ||
|
|
||
| Jay's practical corollary for wallet builders: receiving requires **no action from the receiver** — incoming amounts accumulate homomorphically into your receivable balance as encrypted events, and your wallet learns what you hold by replaying those events, decrypting, and storing the openings. Stellar RPC's default retention is **seven days**; events are never _lost_ (you can always replay the chain), but pick an RPC with the retention you need and refresh periodically. Spending is self-healing — every spend forces you to open your balance and generate a proof — so it's the long gaps _after_ your last spend you have to sweep for. |
There was a problem hiding this comment.
Confirmed against INDEXER.md ('deployments MUST treat wallet-local state as unrecoverable after the RPC window' without a conforming archive). Replaced the 'events are never lost' framing with the durable-archive requirement in a954d08.
|
|
||
| Can you use confidential tokens from a smart wallet — passkeys, C-addresses? Yes; Alex has already seen a passkey demo inside a confidential-token-capable wallet. Jay's explanation of why it works: **authentication and token holding are decoupled**. The smart wallet is an authentication mechanism; the account holder is just a regular token holder underneath. Encryption keys are derived from your account's secret — secret key, then spending key, then viewing key, and so on. | ||
|
|
||
| Registration was the follow-up: to participate you **register** with a specific token contract — the key derivation commits to that contract, involves a proof, and registers your auditor viewing key along with it. Per Jay, both sender and recipient need to be registered; you can't fire tokens at an address that has never generated its keys. Alex noted the registration step is the deliberate price of a design ask — log in with your existing address and derive everything from it, instead of manually managing separate view and spending keys like the original implementation did. |
There was a problem hiding this comment.
Confirmed — registration stores the account's public spending/viewing keys plus the chosen auditor_id, and auditor keys live in the separate registry. Reworded in a954d08.
|
Preview is available here: |
|
Preview is available here: |
Closes #2749
What this does
Adds the five missing Stellar Developer Meeting notes for the meetings already published on YouTube:
meetings/2026-07-16.mdx— Stellar Raven introduction (Zv_scYurQMI)meetings/2026-07-23.mdx— Stellar Quest relaunch + guest Hypertron (0RpAMlqRmkY)meetings/2026-07-30.mdx— CCTP & cross-chain USDC demo with Elliot (57fB8A5vhj0)meetings/2026-08-06.mdx— Confidential Tokens Q&A from Stellar House Brazil (7nta-uFWiRY)meetings/2026-08-13.mdx— Stellar Builder Summit São Paulo winners (SesCqhylBYw)Notes for the 07/09 and 07/17 protocol discussions (held on Discord, recordings not yet on YouTube) are tracked separately in #2750.