Developing 'Private Social Networks' with Onchain Keys

Creating private social networks with on-chain keys is an exciting idea that brings together blockchain tech and social interaction. By leveraging on-chain keys, we can boost both privacy and security on social platforms. Let’s dive deeper into how this all works and what it could mean for the future of social media.

What Are Onchain Keys?

Onchain keys are cryptographic keys that live on a blockchain, giving you a solid way to manage and verify your identity. Unlike the typical social networks that depend on centralized servers--which can be pretty prone to hacks--on-chain keys take a more decentralized route. This means your data stays safe and is only accessible to people you decide to share it with.

Why Private Social Networks?

With all the buzz around data privacy and security, it’s no surprise that a lot of folks are on the hunt for alternatives to the big-name social media platforms. Private social networks are stepping in to give users a chance to connect and chat without worrying about their data being misused. Here are some reasons why these networks are becoming so popular:

• Enhanced Privacy: Keep your personal info right where you want it--away from any centralized database.
• Control Over Data: You get to decide who sees your stuff and how it gets shared.
• Decentralization: This cuts down the chances of censorship and boosts freedom of speech.

Building a Private Social Network

Creating a private social network using on-chain keys is all about following some essential steps:

1. Choose a Blockchain: First things first, pick a blockchain that lets you build decentralized apps. A great go-to is Ethereum--it’s super popular because of its powerful smart contract features.
2. Develop Smart Contracts: Smart contracts are super handy for managing user registration, posts, and interactions. Think of them as the backbone of the network, making sure every transaction stays secure and transparent.
3. Create a User Interface: Having a user-friendly interface is super important. It should be easy to use, letting folks navigate and interact within the network without any hassle.
4. Implement Onchain Key Management: This is where the fun really begins! It's super important to give users secure access to their keys while also helping them understand how to manage those keys effectively.
5. Launch and Iterate: Now that you've got everything set up, it’s time to launch your network! Get out there and gather user feedback, then keep tweaking and improving the platform as you go.

Challenges to Consider

While the concept of private social networks is super intriguing, there are definitely some challenges to consider:

• User Adoption: Getting folks to move away from familiar platforms can be a real challenge.
• Scalability: It’s super important to make sure the network can support more users as it grows, all while keeping performance top-notch.
• Education: People are going to need to get the hang of using on-chain keys, which might mean we have to offer some extra resources and support.

Conclusion

Creating private social networks using onchain keys is a fresh and exciting approach to ensuring a safer and more privacy-oriented online experience. As we explore the ever-changing world of social media, these networks could be exactly what many users have been searching for. If you're keen on diving into the nitty-gritty of how to set this up, take a look at more resources here.

Let’s dive into this exciting new chapter of social networking!

• Your roadmap mentions “invite-only communities with E2EE, SSO, and compliant archiving,” but honestly, it seems like your tech stack is struggling to keep up with the latest innovations like passkeys, key rotation, and group encryption for both web and mobile.
• The product managers are really hoping for those Apple/Android-native login options (hello, passkeys!), the legal team is pushing hard for selective retention, security is all about making sure those key ceremonies are auditable, and the growth team is keen on pseudonymous posting while avoiding the hassle of fake accounts. On top of that, your wallet team is stuck in a debate about whether to stick with seed phrases or switch to embedded wallets.
• As each week rolls by, moderation challenges are piling up, invite churn is on the rise, and the board is left scratching their heads, wondering why “private social” is nothing more than a slide in the presentation and hasn’t turned into a real product yet.
• As you work on revamping your authentication system, you might find yourself racing against deadlines. You start off by getting things sorted for WebAuthn, and then you realize you have to redo a lot of it for "onchain" since your L2 doesn’t natively support P‑256 signatures. Luckily, EIP‑7951 comes to the rescue with a neat P‑256 precompile that includes verification semantics and a straightforward gas schedule (P256VERIFY at 0x100; around 6,900 gas). Just make sure to plan for this early on, otherwise, you might end up shipping some fragile shims that you'll need to scrap later. Take a look at it here.
• Just a heads up, your group messaging feature might roll out without any forward secrecy or post-compromise security. What this means is that your “private” rooms could end up being exposed if even just one admin gets phished. To boost your security, you might want to consider adopting MLS (that’s the RFC 9420 protocol and RFC 9750 architecture). It’s the modern standard and is already being integrated into RCS for millions of devices--so your users are definitely going to expect it. If you want to dive deeper into the details, check it out here.
• Watch out for “Anonymous mode” - it could end up being a spam magnet. If you’re not using ZK proof-of-membership (shoutout to Semaphore v4) and nullifier-scoped rate limits, you might have to revert to full identity checks. That could really damage trust and engagement. If you want to dive deeper, you can find more details here.
• Quick note: your invite flows might accidentally show off your graph. With ERC‑5564 stealth addresses and the ERC‑6538 registry, you've got some cool options for sending private, non-interactive, scannable invites. If you skip these solutions, you could unintentionally spill the beans on who invited whom right from the start. Check it all out here.

We focus on four main areas at once: Identity, Groups, Content, and Compliance. Once we've got that down, we roll out a go-to-market strategy with clear metrics to keep track of our progress.

1) Identity and login: WebAuthn passkeys, onchain-verifiable

• Why now: Passkeys are really shaking things up--they're leading to way better sign-in success rates and way less waiting time (we’re talking about a 93% success rate and around 73% faster logins). This means more folks are breezing through your invite funnel and signing up. On top of that, when you mix that awesome user experience with on-chain verifiability, your apps, bots, and contracts start to share the same trust vibes. For more details, check out the FIDO Alliance site.
• How we roll this out:
  • We’re all about using WebAuthn/Passkeys (P‑256) as our go-to credential. When it’s time to verify signatures on L2, we tap into the P‑256 precompile (EIP‑7951). This lets us avoid the hassle of custodial seed phrases while still offering that solid hardware-backed authentication you get with Secure Enclave, Android Keystore, and FIDO2 keys. We’ve also mapped out the P256VERIFY interface (that’s a 160-byte input and a 32-byte “1” for a success signal) and we make sure to enforce r/s and point bounds right at the precompile level. For the nitty-gritty details, just swing by EIP-7951.
  • For those of you with existing EOAs, we’re adding some cool one-time “smart” capabilities thanks to EIP‑7702 (tx type 4). This means even the old-school addresses can batch actions or get gas sponsorship without forcing users to switch their wallets. It’s a handy upgrade to the 4337 stacks that doesn’t replace anything. If you’re curious and want to dive deeper, check out EIP-7702.
  • Plus, we’re kicking things off with counterfactual signers right from the start with ERC‑6492. This lets you verify signatures for accounts that are still in the pipeline, making those invite flows super smooth and speedy. For more info, you can find everything you need at EIP-6492.
• Outcomes you can measure:
  • You can expect a boost in conversions by around 20-30% at the “Join” stage, all thanks to the success rates of passkeys. And when it comes to sign-in times? We're cutting them down from about 31 seconds to a speedy 8.5 seconds! Plus, there's a noticeable drop in help-desk tickets for password resets. If you want to dig deeper into the findings, check out the study over at FIDO Alliance.

2) Group Security: MLS for E2EE + Onchain Signer Governance

• Baseline: We're rolling with IETF MLS for setting up group keys (you can dive into RFC 9420 for the protocol details and check out RFC 9750 for the architecture). This approach gives us both forward secrecy and post-compromise security, which is pretty great. It's a solid pick, especially since it aligns with the crypto that RCS is using. Plus, it’s already been tested with larger groups, so we know it can handle the load!
• Onchain Anchors (Not Payloads):
  • We’ll keep track of group metadata commitments--like MLS epoch, roster hash, and cipher suite--on an L2. This means you get a verifiable state without having to jam any ciphertext onchain.
  • We're in control of who can post using delegated signers tied to an identity registry:
    • Example: Let’s borrow a concept from Farcaster. They use a custody address on OP Mainnet to manage Ed25519 signer keys that are registered onchain in a Key Registry. Apps interact through these delegated signers, and the custody can easily change or revoke signers whenever needed. We can adapt this method for your network, whether it's a smart account or an enterprise KMS. For more details, take a look at the Farcaster Signers Documentation.
• Practical Controls:
  • We’ve got these short-lived poster keys that last anywhere from 7 to 30 days. They’re tied to device trust and automatically refresh every time the MLS epoch changes.
  • On top of that, we’re introducing role-based write scopes, such as channels, caps, and rate limits. These will be verified within your smart account module or through code that gets the thumbs up from 7702 during transactions.

3) Private invitations and discoverability--without graph leakage

• We're excited to roll out ERC-5564 stealth addresses! This means that when you invite someone, you can create a one-time, unlinkable address just for that recipient, all based on their public stealth meta-address. Recipients can easily scan these addresses using view tags, while keeping their spending keys safe and sound. For tracking everything, we're using ERC-6538 registry entries for each “entity,” which are set up with EIP-712/EIP-1271 signatures. The coolest part? Your invite ledger stays auditable, but outsiders won’t be able to connect the dots between recipients. Check it out here: (eips.ethereum.org)
• This method pairs really well with MLS pre-shared secrets. Each invite will come with a stealth spending right (that's on-chain) and an encrypted MLS Welcome (off-chain). What this means is that we can provide instant end-to-end encryption right when someone joins.

4) Anonymous-but-accountable posting with ZK membership

• Have a look at Semaphore v4! It allows users to “prove membership once per scope” while keeping their identities under wraps. Those nifty nullifiers ensure that no one can double-post, and moderators can effortlessly rate-limit by scope without revealing anyone’s identity. Plus, for voting and sensitive surveys, we’re introducing MACI, which means you can benefit from receipt-free anti-collusion governance. Check it out here: (docs.semaphore.pse.dev)
• Quick engineering note: We only check proofs on-chain for decisions that genuinely need to be finalized there. For everything else, we handle verification off-chain to speed things up, and we mix in periodic commitments to keep everything in check.

5) Storage, DA, and performance: keeping secrets offchain while proofs stay onchain

• Alright, let’s break it down: message payloads and media don’t actually get stored on the blockchain. Only authenticated commitments and some key metadata make it through.
• Now, about those rollup costs: we bundle channel/epoch commitments into EIP‑4844 blobs. And if you’re planning to scale up, PeerDAS (EIP‑7594) has your back by sampling availability instead of making you download every single blob. This way, you can keep those data availability costs down without sacrificing integrity. Take a look here: (eips.ethereum.org)
• Here are some architecture options we've rolled out:
  • Encrypted object storage solutions like S3, GCS, or Azure using MLS-rotated content keys, along with hash commitments on L2.
  • You can also go with IPFS, Ceramic, or Arweave for public discoverability while keeping the binary fully encrypted from end to end.
  • And don’t forget about the threshold re-encryption (PRE) option, which helps you keep compliance archives safe without exposing live keys.

6) Compliance, Procurement, and Business Continuity (The Deal-Breakers You Can't Overlook)

• RTO/RPO: We’re all set with directory recovery and signer rotations to make sure we can tackle any device loss or SOC events smoothly. Custody might chill in HSM/KMS, and as for those poster keys? No worries--they're disposable and get rotated automatically on a regular basis.
• DSAR and Data Minimization: We keep your Personally Identifiable Information (PII) securely stored offchain, locked up tight with MLS group keys and device passkeys. Our moderation crew only checks out the content when it's really needed based on our policies; otherwise, we focus on showing “membership/eligibility” without revealing any personal details.
• Archiving: You can easily export to WORM storage, and we make sure to keep those capture keys secure under our legal hold policies. On top of that, we’ve got a reliable mapping from MLS epochs to retention events that’s recorded on-chain and fully auditable.

Who This Article Is For--and the Keywords You’re Actually Looking For

• Target Audience: If you're leading Product or Security at any of the following, this is for you:
  • Collaboration suites launching exclusive invite-only communities
  • Consumer social apps looking to include “private circles”
  • B2B platforms building partner networks with end-to-end encryption (E2EE)
• Your Required Keywords: Here’s the lowdown on what you should focus on (keeping it straightforward and to the point):
  • WebAuthn P‑256 wallets
  • EIP‑7951 P256VERIFY
  • EIP‑7702 delegated code
  • ERC‑6492 counterfactual signatures
  • ERC‑5564 stealth addresses + view tags
  • ERC‑6538 meta‑address registry
  • MLS RFC 9420/9750
  • Farcaster custody + delegated signers on OP Mainnet
  • Semaphore v4 nullifiers
  • MACI for receipt‑free votes
  • EIP‑4844 blobs
  • EIP‑7594 PeerDAS
• Goal: This network is designed for founders to invite partners privately. Every post is end-to-end encrypted (E2EE), there's an anonymous Q&A feature for verified groups, and you won’t have to worry about any seed phrases.
• Flow:
  1. First off, a founder sets up a stealth meta-address using ERC-6538. Then, 7Block Labs jumps in to add the registry entry, complete with an EIP-712 signature from their custody account. You can check it out here.
  2. Next, the inviter runs generateStealthAddress() with the recipient’s meta-address. They create an announcer event (which has a view tag) and toss in a short-lived MLS Welcome, encrypted with the stealth address’s key. The recipient’s wallet picks up the view tag and whips up the spend key right on their device. Want more details? You can find them here.
  3. Recipients log in using passkeys, and their devices register a delegated poster key (Ed25519) on the group’s Key Registry. If someone misplaces their device, no worries--custody automatically rotates the signer, updates the group MLS epoch, and clients rekey themselves smoothly. For the nitty-gritty, check it out here.
  4. When it comes to “Ask Me Anything” threads, users can post with a Semaphore proof that’s tied to the threadId. The app makes sure that each identity can only post once per thread, all while keeping the poster's identity hidden. Curious for more? Dive into the details here.
• Why it Works:
  • We’ve got no graph leakage (shoutout to stealth and view tags), instant E2EE (thanks to the MLS Welcome), no seeds needed (we're using passkeys and P-256 precompile), and we enjoy spam resistance without compromising privacy (cheers to Semaphore!).
• Goal: We want to make it super easy for partners to log in with enterprise SSO, guarantee that all content is protected with end-to-end encryption (E2EE), let the legal team archive stuff whenever they need to, and maintain solid performance as we grow.
• Flow:
  1. When employees log in through your Identity Provider (IdP) with OIDC, the first time they visit the app, it hands them a platform-bound passkey. This step links the device’s P‑256 public key on L2 (or connects it to a smart account) and keeps an on-chain authorization for session code execution via EIP‑7702. This is super handy for tasks like batch “post + pin + tip.” (eip.info)

1. MLS handles the channel keys, so admins can easily revoke access and change epochs whenever necessary, making sure devices keep updating without a hitch.
2. The compliance connector takes the chosen channels and re-encrypts them into archival keys (off-chain PRE). It indexes those MLS epochs based on retention SLAs. And here’s the cool part: only the commitment hashes are stored on L2, ensuring everything stays secure when it's time for audits.
3. Each quarter, we've got this rotation trigger. Signer TTLs run out, devices need to be renewed, and our audit log does a great job of tracking those (epoch, rosterHash, signerId) tuples for every write grant. Plus, you can easily verify everything against the L2 anchor.

• Goal: Enable companion apps and bots to post on behalf of a user without needing access to their keys.
• Flow:
  1. The user's custody, whether it's an EOA or a smart account, can add a delegated poster signer. From there, the app can post through hubs that ensure the signatures match the keys registered on-chain (this method has proven effective in Farcaster). The neat part? Users have the ability to revoke access for that app-specific signer whenever they feel like it. (docs.neynar.com)

1. For those temporary "pop-up" rooms, the app creates MLS subgroups. The poster keys they utilize are pretty limited and will automatically expire once the room wraps up.

Emerging Best Practices We’ve Road-Tested (2025-2026)

• Identity:
  • Consider using passkeys as your go-to choice instead of seed phrases for everyday transactions. Connect your device keys to L2 verifiers (EIP‑7951) to make the verification process smooth and budget-friendly. You can expect to spend about ~6,900 gas for each verification. Money phrase: “Passwordless UX with onchain verifiability.” (eips.ethereum.org)
  • Make sure to use EIP‑7702 smartly: it’s great for batching multiple calls for tasks like “posting + reactions + following” all in one go. Plus, it allows paymasters to pick up the gas fees for those bigger actions. Check it out here: (eip.info)
• Groups:
  • Consider making MLS your primary option; switch it up whenever there are admin changes and at regular intervals. Don't forget to expose the epoch in your APIs and keep a record of the (groupId, epoch, rosterHash, cipherSuite) commitment on L2 for replay detection and audits. (datatracker.ietf.org)
• Privacy and Invites:
  • Consider using ERC‑5564 and ERC‑6538 to better handle invites and scans. Make sure to use view tags often to help reduce those client scanning costs. If HR or legal needs to give the green light beforehand, it’s smarter to publish organization-wide meta‑addresses under an “entity” entry rather than doing it for each user. Money phrase: “Private invitations without social-graph leakage.” (eips.ethereum.org)
• Anonymous Posting:
  • Restrict Semaphore nullifiers to just the channel or thread level--not the whole tenant. Set strict rate limits based on the scope to avoid those pesky Sybil floods. Also, make sure to check proofs offchain and then commit the aggregates onchain. (docs.semaphore.pse.dev)
• DA and Cost Control:
  • Merge write events and epoch shifts into EIP‑4844 blobs. If you’re anticipating super high throughput, think about using PeerDAS (EIP‑7594) on mainnet/L2 to help manage bandwidth. Money phrase: “Auditable state, negligible DA cost.” (eips.ethereum.org)

GTM: Metrics We're Aiming to Improve (and How We'll Forecast Them)

• Top-of-Funnel Conversion
  • We’ve discovered that using passkeys really improves sign-in success--about 93%! Plus, they make the whole authentication process much quicker, taking around 8.5 seconds instead of the usual 31 seconds with traditional methods. We’re thinking this could lead to a solid 20-30% increase in successful invites. During your pilot, we’ll run some A/B tests, comparing the passkeys-first approach with the old password-first method. You can check out more details here: (fidoalliance.org).
• Content Velocity with Safety
  • Thanks to delegated poster keys that we can revoke and customize, we've noticed a great increase in our daily posts while keeping everything safe from any misuse. We’re actively tracking signer churn and monitoring how fast we can revoke access (MTTD/MTTR), all inspired by Farcaster’s custody/signer model using L2 anchors. Curious to learn more? Check it out here: (docs.neynar.com).
• Privacy-Preserving Engagement
  • We’ve rolled out “anonymous questions” powered by Semaphore, and guess what? It’s boosting participation while cutting down on the hassle of multi-account spam. We’re keeping an eye on unique-nullifier counts for every thread and tracking verification failure rates over time. Want to dive deeper? Check it out here: (docs.semaphore.pse.dev).
• Infra Cost and Reliability
  • We're diving into the DA cost for every 10,000 messages using 4844 blobs versus calldata. This includes looking at blob inclusion SLOs and our sensitivity to reorgs. We're also ensuring that PeerDAS readiness is included in the runbook for networks that choose to opt in. If you're curious and want to read more, check it out here: (eips.ethereum.org).

Specifications Snapshot (What We Ship, Quickly)

• Identity and Wallet
  • Primary Auth: We’ve got your back with WebAuthn passkeys (P‑256) to ensure your access is secure.
  • Onchain Verification: Dive into EIP‑7951 for P256VERIFY; EIP‑7702 for batched or sponsored calls; and if counterfactual contract signers are your thing, check out ERC‑6492 (eips.ethereum.org).
• Groups and Permissions
  • E2EE: We're rolling out MLS (RFC 9420) using a setup that aligns with RFC 9750. On top of that, we've introduced short-lived poster keys that are tied to devices and on-chain group state commitments (datatracker.ietf.org).
• Privacy and Invitations
  • Stealth Addresses: We’re using ERC‑5564 for those non-interactive view tags, and we’ve got a meta-address registry sorted out thanks to ERC‑6538. Plus, we’re supporting EIP‑712/EIP‑1271 too--check it out here.
• Anonymous Posting
  • ZK Membership: Check out Semaphore v4 for zero-knowledge membership. Plus, if you're into it, there's optional voting without receipts using MACI. You can find all the details here.
• Data Availability & Cost
  • Commitments: We're gearing up to include EIP‑4844 blobs for a more robust setup down the line. Also, keep an eye out for EIP‑7594 PeerDAS on the networks that support it, once it's rolled out (eips.ethereum.org).

How We Collaborate with Your Team (And Where Each Service Comes In)

• Architecture and Build:
  • Our crew is all about building, rolling out, and securing the foundations of your project with our specialized web3 development services and custom blockchain development services. We get into the nitty-gritty of everything from MLS integration to those intricate signer registries and EIP‑7702 flows.
  • Got a need for smart contracts? No problem! Our talented smart contract development team is here to whip up modules for invites, signer governance, and proof verification.
• Security and Audit:
  • Before your project makes its big debut, we dive into extensive threat modeling, craft essential ceremonies, and carry out detailed code reviews as part of our security audit services.
• Integration and Rollout:
  • We’re all about connecting the dots with IdP/SSO, KMS/HSM, and data-layer wiring, drawing on our know-how in blockchain integration.
  • Got a network that stretches across L2s or appchains? No worries! Our cross‑chain solutions development crew is here to make sure everything works together seamlessly and that your data stays consistent.
• Front-End and App Layer:
  • We’re here to help you kick off your MVP client with our dApp development service. We want your users to feel that “consumer-grade” vibe from the very start!
• Go-To-Market Acceleration:
  • If your team is getting ready to raise some capital or kick off a launch, we can help by putting together a compliance-ready demo and a robust KPI model with our fundraising advisory.

Brief, In-Depth Details You Can Hand to Engineering Today

• Passkeys on L2: With EIP‑7951, we can now easily verify passkey signatures using the format (r,s + Qx,Qy). Each verification will set you back about 6,900 in gas costs. If you’re following NIST semantics, make sure to throw in a malleability check at the app layer. To enhance user experience with those quick one-tap actions, think about pairing this up with EIP‑7702 for batched operations like “post + tip + notify.” You can check it out here.
• Delegated Posting (Farcaster-style): This feature is super cool! You can have either an EOA or a smart account approve Ed25519 poster keys. Hubs will accept posts signed by these registered keys, making the whole process smooth. Plus, you can easily handle revocation and rotation right on-chain. This way, you get a secure “Login with X + Post from Y app” experience without dealing with a ton of keys. If you want to dive deeper, check out more details here.
• Private Invites at Scale: Looking to send out invites without all the hassle? You can easily publish stealth meta-addresses for different organizations or users (take a look at ERC‑6538). Plus, use the ERC‑5564 Announcer to send invites with view tags. Recipients can just scan them in a flash--no more awkward handshakes required! This means you can distribute invites privately while also ensuring they're delivered. Want to know more? Check it out here.
• Anonymous Q&A That Can’t Be Exploited: With Semaphore v4, we’re tying proofs to specific thread scopes to stop any kind of reuse. Plus, you can set rate limits for each scope to keep identities under wraps. If you're looking for tally systems that resist bribery, check out MACI. Find out more here.
• DA Cost Planning: Consider posting just your commitments and key events to the chain, and then bundling them into EIP‑4844 blobs. As you ramp up your throughput, PeerDAS can assist nodes in sampling availability, which helps keep your infrastructure costs and sync times in check. For more info, check it out here.

Why 7Block Labs

• We're all in on linking Solidity, ZK, and MLS to bring you the best of the best in procurement-grade results. That means you’ll get all the key ceremonies, BCP/RTO strategies, compliance integrations, and executive-level metrics dashboards you need. You’re going to love our “consumer UX, enterprise control, provable privacy” approach--it's way more than just adding a wallet to a chat app.

Personalized CTA

Hey there! If you're the Head of Product or Security and you've got a Q2-Q3 2026 milestone focused on "private communities with E2EE and passkeys," I’d love to chat! How about booking a 45-minute Architecture Review with our core team this week? We’ll really get into it--mapping your IdP, choosing your L2 (and checking out the EIP‑7951 availability), designing your MLS + delegated-signer setup, and crafting a solid 30-day pilot plan. We’ll nail down KPIs like join-rate lift, DA cost per 10k messages, and revocation MTTR. Just drop us a reply with “MLS-Onchain, ” and your target launch date. Let’s make that deadline happen!

References (select standards and sources cited inline)

• EIP‑7951 P‑256 precompile (verification semantics, gas): Check it out on eips.ethereum.org.
• EIP‑7702 delegated code for EOAs: For more details, swing by eip.info.
• ERC‑6492 counterfactual signature validation: You can find all the info on eips.ethereum.org.
• ERC‑5564 stealth addresses (view tags; announcer): Get the scoop over at eips.ethereum.org.
• ERC‑6538 stealth meta‑address registry: All the details are waiting for you on eips.ethereum.org.
• MLS protocol (RFC 9420) and architecture (RFC 9750); RCS adoption: For the nitty-gritty, check out IETF’s site: datatracker.ietf.org.
• Farcaster custody + delegated signers on OP Mainnet: Explore Neynar docs, the dTech explainer, or join the Farcaster protocol discussion here: docs.neynar.com.
• Passkey business impact (success rate, login time): The FIDO Alliance Passkey Index (2025) shares some cool insights: fidoalliance.org.
• EIP‑4844 blobs and EIP‑7594 PeerDAS for DA scaling: Find more info on eips.ethereum.org.