Identity and Pseudonymity Sunday — June 21 2026 Weekly Update

TL;DR — This Week

• Nostr signer hardening: Signet v1.11.0 shipped a critical NIP-17 admin-command signature bypass fix. Attackers with only public info (signer pubkey, admin npub, admin relay) could forge panic / resumeall / alive kill-switch commands. Operators must upgrade promptly.
• Amber v6.2.1: Battery-drain fix from relay reconnects / websocket pings, NIP-46 logout method support, dead-relay pruning, Material 3 settings UI.
• Clave 1.0 (build 102) submitted to iOS App Store. Push-woken background signing — sign with the app closed, BIP-340 Schnorr verification over canonical NIP-01 serialization + replay-freshness guard. Most mature iOS NIP-46 signer yet.
• Amethyst v1.12.0: 170+ PRs. NIP-60 Cashu wallet + NIP-61 nutzap rendering, CLINK on-chain zap driver (Common Lightning Interface for Nostr Keys), private notes via NIP-17 gift-wrap, full Tor self-heal cluster (Arti v2.3.0 + watchdog + 60s bootstrap timeout + self-heal-when-circuits-dead). KMP iOS migration Phase 1 & 2 unblocks iOS CI for quartz and commons modules.
• Mostro Core v0.13.0 ships Protocol v2 — replaces relay-routed order communication with NIP-44 gift-wrapped direct messages on kind 14 events. Trade conversation no longer leaks to every relay.
• Chama v3.5.0 (six releases in a week): holder-only Shamir shares, arbiter substitution, full trade-room UI, money-path hardening across five bug classes.
• NIP-17 key-decoupling proposal (fiatjaf)(https://github.com/nostr-protocol/nips): fiatjaf opened a contested NIP-17 key-decoupling proposal that re-opens the bunker-vs-Marmot architectural argument. Worth tracking.
• NIP-F4 podcasts merged after 27 months of debate. Long-form audio over Nostr now has a spec.
• Farcaster → Neynar (settled): The January 21 2026 acquisition is now fully integrated. Co-founders Varun Srinivasan and Dan Romero have left. Neynar owns protocol, app, and Clanker. The cryptographic identity remains onchain (OP Mainnet FIDs) but the protocol company is now a single point of stewardship.
• Worldcoin / World ID 2.x: The biometric proof-of-personhood track continues to ship. Hardware orb updates, World ID 2.0 SDK adoption, regulatory pressure in multiple jurisdictions — see Proof of Personhood and Sybil Resistance.
• Proof of Personhood paper landscape: IACR eprint 2026/333 (Cryptographic Framework for PoP) remains the most rigorous formal treatment. Idena synchronous validation rounds, BrightID social-graph verification, and Polkadot's ZK-PoP roadmap all continue to mature in parallel.

The freedom-tech takeaway: the Nostr signer is becoming a load-bearing component of the entire identity stack — Signet's NIP-17 bypass shows that an attacker with only public info could forge admin commands, and Clave's push-woken background signing is the architectural answer (separate process, push-woken, app closed). The trade stack is migrating from relay-routed order books to NIP-44 gift-wrapped direct messages, which means trade reputation now requires a Nostr key, not just a relay-pinned account. The combination of NIP-60/61 (Cashu + nutzaps) in Amethyst and CLINK on-chain zap verification is the first time a single Nostr client has unified the four money-legs (Lightning, on-chain, Cashu, NWC) into one payment card. The most consequential non-protocol story is still Neynar-Farcaster: the social-graph protocol remains decentralized, but the stewardship is now centralized in a single company.

The Week in Detail

Nostr signer hardening: Signet admin-command bypass, Amber battery drain, NIP-46 logout method

This week's most consequential single fix is in Signet v1.11.0 (referenced in Nostr Compass #27). The vulnerability is worth understanding because it shows the kind of subtle identity-system failure mode that the 2026 custody stack must defend against.

The bug: the NIP-17 gift-wrap admin-command path checked only the unsigned inner rumor's claimed author, never verifying the signed seal. Because NIP-44 conversation keys are symmetric, an attacker with only public information (the signer's pubkey, the admin npub, the admin relay) could forge kill-switch commands — panic, resumeall, alive — and feed them to an admin client. The fix is to call verifyEvent on the seal and bind the rumor author to the seal signature.

What this means for identity architecture:

1. Public info alone is enough to forge some commands in any symmetric-key system. The seal/rumor model of NIP-17 is sound, but the separation of seal verification from rumor verification is a recurring footgun. Any future NIP-17-style spec needs to mandate seal verification as a precondition for rumor processing.
2. Admin commands are a richer attack surface than user commands. Most NIP implementations focus on the user-side verification path; admin paths often have weaker verification. For ungovernable infrastructure, this is a flag: any NIP-17 client handling admin or operator commands must verify the seal before any rumor is processed.
3. The Signet fix ships in 24 hours because the project's author (Quentin Hayot) treats NIP-17 as security-critical and verifies the seal in the new code path. This is the kind of fast response that an active single-implementer team can deliver; for production users running multiple Nostr signers, the practical advice is to pin a specific Signet version and audit the bump.

Concurrent signer hardening:

• Amber v6.2.1 — reduces battery drain from relay reconnects / websocket pings, drops dead relays from the subscription pool, adds NIP-46 logout method support (PR #2373), parses event kind 39701 (public web bookmark), rebuilds Settings with Material 3 grouped cards, fixes a navigation crash on the permissions screen and a per-account DB connection leak. The battery fix is the kind of operational quality-of-life that converts Amber from "best Android signer" to "battery-acceptable daily driver."
• NIP-46 logout method is now a formal PR #2373 in the nips repo, supported by Amber v6.2.1 and Clave 1.0. This is the "kill the remote signer session" primitive that every serious NIP-46 client should implement. Until this PR, the only way to revoke a remote signer session was to rotate the connection secret, which required a fresh pairing flow. logout lets a client terminate its session without a new pairing.
• NIP-46 connect-metadata extension (PR #2381) also shipped via Clave 1.0. This adds metadata to NIP-46 connect requests so a client can advertise its name, URL, icon, and per-event-kind permissions during the pairing flow. The result: a UX where the user sees a friendly "Damus wants to post on your behalf — allow?" prompt rather than an opaque base64 event blob. For ungovernable system design, this is the missing piece for NIP-46 adoption outside the developer community.

For ungovernable system design: the 2026 Nostr signer stack is hardening from "developer primitive" to "consumer product". Signet fixes subtle protocol-level bugs, Amber fixes battery-drain UX, Clave ships consumer-grade iOS pairing with named-app prompts, and the logout method gives users a kill-switch they can actually understand. The remaining gap is cross-signer federation: a user should be able to seamlessly move between Amber (Android), Clave (iOS), and a future desktop signer without re-pairing.

Clave 1.0 (build 102): iOS NIP-46 signer with push-woken background signing

Clave 1.0 is the first iOS NIP-46 remote signer to reach App Store submission with the architectural pattern the 2026 custody stack has been converging toward. The headline feature is push-woken background signing — the app can receive a signing request while closed, decrypt, check permissions, sign, and respond without the user opening the app.

The deeper architecture:

• Key in iPhone Keychain. Hardware-backed on supported devices, software-backed on older ones.
• BIP-340 Schnorr verification over canonical NIP-01 event-serialization, with a replay-freshness guard. The freshness guard is critical: without it, a captured signed event could be replayed against any service that accepts the same event ID.
• Updated NIP-44 encryption with kind-scoped permissions and three sensitivity tiers. This is the kind of fine-grained authorization that the bunker pattern always needed but rarely shipped.
• Multi-account pairing — a single Clave can serve as the signer for multiple Nostr identities on the same device.
• Per-app trust levels (Full/Medium/Low) with per-event-kind overrides. A "Full" trust for Damus, "Medium" for read-only clients, "Low" for experimental ones.
• Activity log per signature — every signing event is locally logged so the user can audit what was signed on their behalf.
• Bring-your-own push proxy (MIT-licensed) — operators of self-hosted signer stacks can run their own push proxy rather than depending on Apple's APNs or a third-party push service.
• Interop matrix at docs/nip46-compatibility.md — explicit documentation of which NIP-46 features Clave supports, partial supports, or doesn't support. The level of interop documentation is unusually mature for a NIP-46 client.

For ungovernable system design: Clave is the most production-ready iOS NIP-46 signer yet. The push-woken background signing closes the most common NIP-46 complaint (you have to open the app to sign), and the per-app trust levels are the answer to the "every client gets the full key" problem. If you are building a Nostr-compatible app and need an iOS signer partner, Clave is the default recommendation as of June 2026.

Amethyst v1.12.0: Cashu + nutzaps + CLINK + Tor self-heal + KMP iOS migration

Amethyst v1.12.0 is the most consequential Nostr client release of 2026. The PR count alone (170+) is unusual; the content is what matters.

The unified payment card (PRs #3191, #3185, #3115, #3075):

For the first time, a single Nostr client has all four money legs in one surface:

• NIP-57 zaps (Lightning via NWC)
• On-chain Bitcoin (CLINK driver)
• NIP-60 Cashu (ecash mints)
• NIP-47 NWC (remote Lightning wallet connection)

The unified card means a user can see their total balance, choose a payment rail per recipient, and not think about which rail they are using. Per-mint balance view (PR #3115) means a multi-mint Cashu user can see per-mint holdings. The UX problem this solves is the inverse of the privacy problem: the friction of choosing a payment rail was a real adoption barrier.

CLINK on-chain zap driver (PRs #3039, #3177, #3182, #3030):

CLINK — Common Lightning Interface for Nostr Keys — is a new abstraction that lets a Nostr client request an on-chain Bitcoin zap without bundling a Lightning node. The verification state machine ensures the on-chain payment is confirmed before the zap is accepted, the reverify driver handles reorgs, and the minimum on-chain zap amount prevents dust spam.

For pseudonymous identity: on-chain zaps are a reputation signal that Lightning zaps cannot match. A Lightning zap costs cents and is anonymous by default. An on-chain zap costs dollars and is permanently on-chain, with the sender's Bitcoin address (or the change address) visible. An on-chain zap is a more credible signal of "this content was worth paying real money for" — but it is also more correlated. CLINK preserves the on-chain payment but keeps the Nostr-side attribution to a public key, so the Bitcoin address and the Nostr public key are linked through the zap event but not through the chain itself. This is the right trade-off for pseudonymous reputation: payment goes on-chain, attribution goes through Nostr.

Private notes via NIP-17 (PR #3201):

Kind-1 replies to p-tagged users are now gift-wrapped into sealed group replies. The implication: when Alice replies to Bob's note, the reply is no longer publicly visible as "Alice replied to Bob" — it is wrapped in a NIP-17 gift-wrap so only the recipient sees it. For pseudonymous identity, this is the difference between public engagement (which builds social graph reputation) and private correspondence (which doesn't). Previously, the only way to reply privately was NIP-04 DM (deprecated) or NIP-44 DM. Now kind-1 replies themselves can be private. This is the killer feature for at-risk pseudonyms — a journalist can reply to a source's public post without revealing that they did so.

Tor self-heal cluster (PRs #3053, #3223, #3224, #3231):

• Arti v2.3.0 + watchdog + integration tests (PR #3053)
• Gates Tor-routed relay dials until Tor is ready (PR #3223)
• 60-second bootstrap timeout (PR #3224)
• Self-heals when Tor is Active but all circuits are dead (PR #3231)

The last one is the operational gold: it handles the case where Arti's circuit pool dies (e.g., all guards unreachable) and the user is silently stuck on a dead Tor. Before this fix, the user had to manually restart Amethyst. Now the watchdog detects the dead circuit state and triggers a re-bootstrap.

KMP iOS migration Phase 1 & 2 (PRs #3047, #3050):

Kotlin Multiplatform iOS migration unblocks iOS CI for the quartz and commons modules. This is the engineering groundwork for a future iOS Amethyst client. The KMP strategy is significant because it means Nostr client code can be shared between Android (already shipped) and iOS (in development) without forking.

For ungovernable system design: Amethyst v1.12.0 is the strongest single-client proof that Nostr is a viable primary identity + payment stack. The unified payment card eliminates a major UX barrier, NIP-17 private notes enable pseudonymous correspondence at the kind-1 layer, and the Tor self-heal cluster makes at-risk pseudonyms operationally viable. If you are building any product that touches Nostr identity, the Amethyst client is now the reference implementation.

Mostro Core v0.13.0 — Protocol v2 cuts the relay middleman

Mostro Core v0.13.0 ships Protocol v2, the most architecturally significant change in the project's history. The change: trade-specific actions no longer flow through relay-routed order books; they are wrapped per NIP-44 in direct messages on kind 14 events, bound to per-trade keys.

The privacy consequence: a Mostro trade conversation no longer leaks to every relay that the trade is happening on. Before v2, anyone running a Mostro relay could see the order book activity of every user on the relay. After v2, only the encrypted envelopes are visible; the trade content is sealed between the buyer, seller, and (in case of dispute) the arbiter.

The replay-resistance consequence: v2 introduces a v2 identity proof bound to the trade key, which closes replay risks where an attacker could re-publish a captured trade message to disrupt an in-flight trade. The v2 identity proof is signed by the user's Nostr key but scoped to the specific trade; replaying it on a different trade fails the binding check.

Mostro v0.17.5: Anti-abuse bond is now optional + operator-configurable. Small bond locked at order time, returned on successful completion, forfeited on stalling / no-show / grief. The bond amount is operator-configurable so different markets can tune the trade-off between friction and abuse.

Mostro Mobile v1.2.8 and v1.2.9 (referenced in Compass #27): 17 features for Protocol v2 support, including bootstrap relay discovery, maker anti-abuse bond Phase 5, order cancellation in notification history, and surfaces the bond policy from the node info event before order creation.

For ungovernable system design: Mostro v2 is the architectural template for any P2P marketplace that wants Nostr identity without relay-routed trade visibility. The combination of NIP-44 direct messages, per-trade key binding, and v2 identity proofs gives users strong trade privacy while preserving the cryptographic identity and reputation that Nostr enables. The anti-abuse bond closes the griefing-attack vector that pure cryptographic reputation systems struggle with.

Chama v3.5.0: Standalone P2P escrow in one week (continued)

Chama is the other P2P escrow client shipping on Nostr, differentiated by Fedimint-backed 2-of-3 Shamir secret sharing. Compass #26 documented the v2.0.0 → v3.1.0 release cascade; Compass #27 documents the v3.2.0 → v3.5.0 follow-on.

The most consequential architectural shift was in v2.0.0 (June 9, 2026): the escrow LOCK format changed so each 2-of-3 Shamir share is encrypted only to its holder (sharePolicy: holder-only-v1). This closes a path where one party with their share plus the federation-held share could complete a trade without consent. Pre-2.0 clients fail loudly with "can't find your share" — no funds are lost because the pre-2.0 client cannot construct a valid LOCK with the new format.

v3.0.0 is the standalone-app milestone — no coordinating community required. End-to-end trade notifications fire only on actionable state transitions (counterparty locked, payout ready, dispute ruling needed, settled/expired), with fire-once dedup. Windows and Linux desktop bundles ship; macOS dmg held back pending signing.

The June 17 follow-ons (v3.2 → v3.5):

• v3.2.0: Color-coded action prompts per seat (buyer / seller / arbiter)
• v3.3.0: Tightened two consensus rules in the trade engine
• v3.3.1: Localized prices and payment methods to community currency
• v3.4.0: Five hardening fixes to the money path (hiccup / race / closed-tab resistance)
• v3.5.0: Two client-side guardrails around the arbiter role

Chama now joins Mostro and Shopstr as a Nostr-native marketplace. The three are differentiated by:

For ungovernable system design: the Nostr P2P trade stack now has three independent, production-grade clients with three different escrow architectures. This is the diversity that the 2024 Nostr ecosystem lacked, and it is the precondition for any user being able to choose a trade model without depending on a single project's roadmap. The trade-off: more code to audit, more UX patterns to learn, and three different reputation systems that don't currently share data.

Nostr Compass #25 (June 3) and #26 (June 10) — NIP-F4 podcasts, NIP-17 key-decoupling debate, Marmot v2 "Dark Matter"

Beyond the headline releases above, two ongoing NIP-level debates are worth tracking:

NIP-F4 podcasts (merged after 27 months of debate, per Compass #25): long-form audio over Nostr now has a spec. The 27-month debate was about the trade-off between storing audio files on Blossom (decentralized) versus centralized podcast hosts, and the metadata model for episodes, series, and subscriptions. The merged spec settles the metadata model and recommends Blossom for audio storage, but allows centralized hosts as a fallback for creators who don't want to run their own Blossom server.

fiatjaf's NIP-17 key-decoupling proposal (opened in Compass #25): fiatjaf, the original author of the NIP-17 gift-wrap spec, opened a proposal that would decouple the Nostr identity key from the gift-wrap conversation key. Currently, NIP-17 conversation keys are derived from the recipient's npub, so the npub is the conversation key. The proposal would let users have separate conversation keys, isolating gift-wrap metadata from their primary identity.

The architectural argument: the current NIP-17 model binds metadata exposure to npub choice. If Alice DMs Bob using NIP-17, the relay sees "Alice sent a gift-wrapped event to Bob's pubkey." The content is sealed, but the social graph is exposed. fiatjaf's proposal would let Alice send a gift-wrapped event to a derived conversation key that is not Bob's primary pubkey, so the relay sees "Alice sent a gift-wrapped event to some pubkey" without knowing it's Bob.

The contested aspect: this proposal re-opens the bunker-vs-Marmot architectural argument. The Marmot position is that MLS group keys (with their own key agreement) should handle all multi-party communication, and NIP-17 should focus on simple 1:1 DMs. The bunker position is that NIP-17 is the simpler primitive and should be made more capable. fiatjaf's key-decoupling proposal is the bunker's answer to the Marmot critique — NIP-17 becomes capable enough that Marmot is not strictly needed for many use cases.

For ungovernable system design: watch this debate carefully. If the key-decoupling proposal is adopted, NIP-17 becomes the privacy-preserving messaging primitive of choice, and Marmot's role narrows to large-group MLS. If it's rejected, Marmot becomes the default for any group messaging use case, and NIP-17 is restricted to simple 1:1 DMs. Either outcome shapes the protocol layer below identity; the choice matters for any app building on Nostr messaging.

Farcaster → Neynar acquisition: settled, but worth a retrospective

Compass #27 is the first Nostr-side publication to fully cover the Neynar-Farcaster transfer, but the acquisition itself was announced January 21 2026. The key facts:

• Neynar (the primary Farcaster infrastructure company, providing the API layer that powers most Farcaster apps) acquired Farcaster from Merkle Manufactory.
• Jack (co-founder) and parts of the Clanker team joined Neynar.
• Dan Romero and Varun Srinivasan (co-founders) stepped away from day-to-day involvement.
• The transfer included: protocol contracts, code repositories, the Farcaster app, and the Clanker project.

For ungovernable system design: Farcaster's identity model (FIDs on OP Mainnet, username = ENS or Farcaster ID) remains cryptographically decentralized, but the protocol is now stewarded by a single company. This is a real distinction: the chain-level identity cannot be revoked by Neynar, but the protocol-level decisions (which NIPs to support, which features to ship, which direction Frames evolve) are now Neynar's.

Compare and contrast with Nostr's model:

The two protocols are not the same, and they serve different threat models. Nostr's censorship resistance comes from "many relays, no single operator can stop you." Farcaster's comes from "your FID is onchain and portable; Neynar can change the app but not your identity." Both are valid; the Neynar-Farcaster transfer just makes the difference starker.

The Nostr ecosystem's response to the Neynar-Farcaster transfer has been a quiet but real acceleration of the "Nostr as the censorship-resistant default" framing. This is partly technical (Nostr's relay-rotation model is more censorship-resistant than Farcaster's hub model) and partly narrative (a Nostr ecosystem that emphasizes protocol-level decentralization benefits when a competitor centralizes).

Proof of Personhood: Worldcoin/World ID, Rarimo, and the IACR framework

The proof-of-personhood (PoP) landscape continues to mature in parallel with the Nostr identity stack. The three main tracks are:

1. Biometric (Worldcoin / World ID 2.x): The Orb device captures an iris scan, generates a privacy-preserving iris code, and issues a World ID 2.0 credential onchain. The credential proves "this person is a unique human" without revealing identity. Hardware orb updates have shipped through Q1-Q2 2026, and the World ID 2.0 SDK has been adopted by multiple consumer apps for age verification, anti-bot enforcement, and fair airdrops. Trade-off: requires trusting the Orb device and the World ID issuer; the ZK proof is sound but the trust assumption is on the issuance chain.
2. ZK + government ID (Rarimo, Anon Aadhaar, Semaphore): A government-issued credential is converted into a ZK proof that proves "I hold a valid credential" without revealing the credential. Rarimo's ZK Rollup (launched March 2025 with $2.5M from Vitalik Buterin) and Anon Aadhaar (covering ~1.4B Indians) are the production deployments. Trade-off: pseudonymity is limited by the government ID's natural identity; the ZK proof preserves privacy within the credential, but the credential itself is identity-linked at issuance.
3. Social graph (BrightID, Idena): Verification through a web of trust — BrightID via verified humans, Idena via synchronous validation sessions where users solve CAPTCHAs together. Trade-off: relies on existing verified humans, which makes the system gameable through social-engineering attacks.

The IACR eprint 2026/333 — A Cryptographic Framework for Proof of Personhood — provides the most rigorous formal treatment. The paper defines two credential types: Personhood Credentials (PHCs) issued by trusted authorities attesting to uniqueness and basic attributes, and Verifiable Relationship Credentials (VRCs) issued peer-to-peer to capture reputation and real-world interactions. The paper's security definitions — Sybil-resistance, authenticated personhood, and unlinkability across contexts — are the formal baseline for evaluating any PoP system.

For ungovernable system design: no single PoP system is the right default. The choice depends on the use case:

• For Sybil-resistant airdrops or fair launches: World ID 2.0 is the most production-ready, with the largest verified-human pool.
• For privacy-preserving access to government services: Rarimo or Anon Aadhaar is the right fit, with the trade-off of trusting the government ID issuer.
• For censorship-resistant governance in pseudonymous communities: BrightID (social graph) or Idena (synchronous validation) is more appropriate.
• For maximum-assurance formal analysis: the IACR 2026/333 framework is the reference.

See Proof of Personhood and Sybil Resistance for the full deep-dive on each system, the trade-offs, and the 2026 deployment landscape.

Cross-cutting themes

The Nostr signer is now a security-critical dependency

The Signet v1.11.0 admin-command bypass is the most concrete proof yet that the Nostr signer stack is security-critical infrastructure, not a developer convenience. The attack surface includes:

• NIP-46 remote signer sessions — if the bunker is compromised, every connected client's events are signed by the attacker
• NIP-17 gift-wrap admin commands — if the seal verification is skipped, public info alone is enough to forge commands (as Signet showed)
• NIP-44 conversation keys — symmetric-key derivation means any leak of the derivation path exposes the conversation
• NIP-60 Cashu mints — if the wallet's signing key is compromised, the user loses all ecash at every mint
• NIP-47 NWC connections — if the NWC secret is leaked, the attacker can drain the connected Lightning wallet

The right architectural response is what Clave 1.0 is shipping: hardware-backed key storage, push-woken background signing, per-app trust levels, and explicit interop documentation. The wrong response is "trust the client developer to get it right" — which is what most Nostr users have been doing since 2023.

The P2P trade stack is migrating to NIP-44 direct messages

Both Mostro v2 and Chama v3.x have moved trade-specific communication off relay-routed order books and onto NIP-44 gift-wrapped direct messages. The architectural significance:

• Trade reputation is now bound to Nostr identity, not to relay-pinned accounts. A trader who builds reputation on one relay can take it to any other relay that speaks the same NIP-44 protocol.
• Trade conversation privacy is now cryptographically enforced, not relay-policy-dependent. A relay operator cannot see what is being traded, only that encrypted envelopes are flowing.
• Trade anti-abuse (bonds, arbiter substitution) is now cryptographic, not operator-configurable. Mostro's anti-abuse bond is enforced by the protocol, not by a relay administrator.

The pattern generalizes: any use case where a relay-routed message would leak metadata (marketplace, dating, professional networking) should migrate to NIP-44 direct transport. The Nostr relay becomes a discovery + storage layer; the actual communication happens peer-to-peer over NIP-44.

The unified payment card: the end of "which rail do I use"

Amethyst v1.12.0's unified payment card consolidates Lightning (NIP-57), on-chain Bitcoin (CLINK), Cashu ecash (NIP-60), and NWC (NIP-47) into one surface. This is the answer to the "Nostr has too many payment rails" complaint that has dogged the ecosystem since 2023.

The deeper significance for identity: a unified payment surface means reputation signals are comparable. A user who zaps with Lightning is doing a different economic action than a user who zaps with on-chain Bitcoin, but the social layer (the Nostr event) is the same. A client can show "Alice has received 100 zaps totaling 0.05 BTC" without the user needing to know which rail each zap used. For pseudonymous reputation, this is a meaningful step: the user gets credit for economic activity regardless of the rail, and the client can decide how to weight each rail in its reputation calculation.

The Neynar-Farcaster transfer: a stress test for protocol-vs-company

The most consequential non-Nostr identity story of 2026 is the Neynar-Farcaster transfer. The cryptographic identity layer (FIDs on OP Mainnet) remains decentralized, but the protocol stewardship is now centralized. The reaction from the Nostr ecosystem is a quiet acceleration of the "protocol-level decentralization matters" narrative.

For ungovernable system design: the lesson is that protocol decentralization is a long-term architectural commitment, not a launch-time claim. Farcaster launched with a decentralized identity model, but the protocol company and the app company were the same entity. When that entity changed hands, the protocol stewardship changed with it. Nostr's model — separate protocol, separate clients, separate relays — is more resilient to single-company risk, but only because no single company has ever owned all the pieces. If any single Nostr implementation becomes the de facto default and is then acquired or shut down, the ecosystem would face the same stress test that Farcaster is now navigating.

What to watch in the next 7-14 days

1. Amber v6.3 (likely late June 2026): The v6.2.1 fixes are good, but the broader question is whether Amber ships full CLINK on-chain zap support and Tor self-heal parity with Amethyst. If yes, the Android signer stack catches up to the Amethyst wallet stack.
2. NIP-17 key-decoupling proposal (open, awaiting fiatjaf's next draft): If the key-decoupling proposal gains traction, expect the NIP-17 vs Marmot debate to dominate the next 4-6 weeks of NIP discussion.
3. NIP-F4 podcasts production deployments (likely late June - July 2026): The spec is merged; expect podcast clients to ship support and Blossom to see the first wave of podcast-episode uploads.
4. Marmot v2 "Dark Matter" production-readiness (TBD): The v2 draft is in internal review per Compass #26. The v1 deployed Rust protocol implementation (MDK) is the production path until v2 ships.
5. Mostro v0.18.0 (likely late June - July 2026): Mobile client is at v1.2.9 with Protocol v2 support; expect a desktop client refresh in the next 2-4 weeks.
6. Neynar-Farcaster product roadmap announcement (TBD): Neynar said they would share a "builder-centric vision" in the near future. Watch the Neynar blog and the Farcaster protocol GitHub for the announcement.
7. World ID 2.0 SDK milestone (TBD): The SDK has been adopted by multiple consumer apps; expect the first billion-user-facing app integration announcement in Q3 2026.
8. IACR eprint 2026/333 follow-up work (TBD): The Cryptographic Framework for PoP paper is a foundational reference; expect follow-up papers applying the framework to specific PoP constructions.

Evidence at a glance (June 14-21 2026)

Open research questions (updated)

1. Can fiatjaf's NIP-17 key-decoupling proposal gain consensus? The bunker-vs-Marmot debate is the most consequential NIP-17 architectural decision since the spec merged. Watch the nostr-protocol/nips repo for the next draft.
2. Will Clave 1.0's push-woken background signing become the iOS NIP-46 pattern? If other iOS signers (Nostur, others) adopt the same pattern, the iOS signer stack will have architectural parity with Android.
3. Can Mostro v2 and Chama v3 interop? Both use NIP-44 direct messages; both are P2P Nostr marketplaces. If their trade protocols converge, a single Nostr identity could be used across both clients.
4. How does the Neynar-Farcaster integration affect the broader social-graph market? The Nostr ecosystem has been quietly celebrating the transfer as a validation of the protocol-level decentralization model. If the transfer leads to Nostr adoption from former Farcaster users, the social-graph competition becomes interesting.
5. Can CLINK on-chain zaps become a credible reputation signal? The minimum zap amount and the on-chain confirmation requirement make CLINK zaps more expensive than Lightning zaps, which makes them harder to Sybil. But the on-chain footprint also makes them more correlatable. The trade-off is real.
6. Will the IACR 2026/333 framework gain adoption? If real PoP deployments start publishing formal security analyses against the 2026/333 definitions, the framework becomes a procurement requirement. If it remains purely academic, the practical PoP market continues with ad-hoc security claims.
7. Can the unified payment card (Lightning + on-chain + Cashu + NWC) generalize beyond Amethyst? If other Nostr clients adopt the same payment-rail consolidation, the user experience across the ecosystem converges. If only Amethyst ships it, the client becomes the de facto monopoly on unified payment UX.

Primary sources (this week)

Releases and announcements

• Nostr Compass #27 (June 17 2026) — the primary source for this week's headlines
• Nostr Compass #26 (June 10 2026) — Marmot v2 Dark Matter, Chama v3.0/v3.1, Coracle Hosting
• Nostr Compass #25 (June 3 2026) — Amber 6.2.0 NIP-44 v3, NIP-F4 merged, fiatjaf's NIP-17 key-decoupling proposal
• Amethyst v1.12.0 release notes (GitHub) — 170+ PRs across NIP-60, NIP-61, CLINK, NIP-17, Tor self-heal
• Amber v6.2.1 release — battery drain fix, NIP-46 logout support
• Clave 1.0 (build 102) App Store submission — push-woken background signing
• Mostro Core v0.13.0 Protocol v2 — NIP-44 direct messages for trade
• Chama v3.2 - v3.5 — six releases in one week
• Signet v1.11.0 critical NIP-17 fix — admin-command signature bypass fix
• Neynar acquires Farcaster (Jan 21 2026) — primary announcement
• Dan Romero tweet on the transfer — co-founder statement

NIPs and protocol specs

• NIP-17 gift-wrap — the spec at the center of the key-decoupling debate
• NIP-44 versioned encryption — the basis for Mostro v2's direct-message transport
• NIP-46 remote signing — the bunker spec, now with logout method (PR #2373)
• NIP-60 Cashu wallets — ecash wallet spec
• NIP-61 nutzaps — Cashu-based zap spec
• NIP-85 trusted assertions — WoT reputation oracle spec
• NIP-39 external identities — external identity claim events

Papers and analysis

• A Cryptographic Framework for Proof of Personhood — IACR eprint 2026/333 — formal PHC + VRC framework
• FROST: Flexible Round-Optimized Schnorr Threshold Signatures — eprint 2020/852 — the threshold signature basis for Frostr
• Hermine: Lattice-based FROST-like Threshold Signatures — eprint 2026/419 — the post-quantum counterpart
• World ID 2.0 documentation — Worldcoin's primary source on proof of personhood
• Neynar-Farcaster analysis (Yahoo Finance) — independent reporting on the transfer
• Farcaster Frames v2 protocol discussion — the Frames evolution

Repositories and project pages

• Nostr signers: Signet, Amber, Clave
• Nostr clients: Amethyst, Primal, Coracle
• P2P trade: Mostro Core, Chama, Shopstr
• Messaging: Marmot Protocol, White Noise, MDK
• Trust and reputation: wot-scoring, nostr-wot, nostr-wot extension
• Identity primitives: did:nostr, HTTP Schnorr Auth, FROSTR-ORG/bifrost, FROSTR-ORG/igloo-server
• Proof of personhood: Worldcoin, Rarimo, Anon Aadhaar, Semaphore, BrightID, Idena
• Farcaster: Farcaster protocol, Neynar