The Lens team is excited to introduce Momoka—a groundbreaking solution to scale decentralized social for mass consumer adoption.
The biggest challenge facing decentralized social today is giving people full control of their content, but with the ease of use they expect from traditional social networks.
Momoka, an Optimistic L3, provides significantly increased throughput and reduced costs without sacrificing user sovereignty; allowing us to realize our vision of scaling Lens to the world.
We firmly believe that user experience must come first for decentralized social to succeed. Momoka is a natural result of this belief, joining our other innovations in abstracting away blockchain complexities and making Lens feel familiar and easy to use.
Blockchain Enables Digital Ownership
Lens Protocol supports user ownership and control over their digital identity and social graph. In other words, the protocol relies on blockchain technology to secure the ownership of a social profile that can be attached to any external identity (canonical Lens namespace, ENS, DIDs or verifiable credentials).
Similarly to profile ownership, users control their relationships themselves. With Lens, user profiles and relationships are not merely numbers in a privately-hosted database but are owned by the users and portable from one application to another. This is by design.
As a Lens user you might have experienced the sense of owning your profile when navigating from one Lens app such as Orb to another one, such as Buttrfly — all without recreating your social network. While still in beta, Lens has over 116,000 users to-date — from thought leaders and creators to web3 enthusiasts — who own their social presence guaranteed by the open source Lens technology stack.
By using blockchain technology, Lens guarantees user ownership and removes control from platforms, giving full control of social networking properties to users themselves. No other technology is capable of achieving these guarantees.
We have also seen the rise of NFTs that capture the value of digital goods and digital consumption into a verified experience. NFTs have thus far had a successful journey from art to music content. Lens turns any user-generated content — written text, music or video, etc. — into an NFT that can be shared directly with the user-base. This empowers creators to monetize, if they choose. As of today, while still in closed beta, Lens users have created and collected over 3.4M NFTs and the average monetizing profile has earned around $50 in paid collects.
Without the blockchain, monetization and exciting new features such as the ability to split fees between Lens users and other programmable monetization, would not be possible. Blockchain solves one of the most important challenges of financial networking, the double spending issue and verified computing. For example, within Lens, a user/creator can set smart contract- based rules to allow only certain followers to collect a rare photo. This content can be “token-gated,” with purchasing requirements set by the creator.
While tokenizing content into NFTs might be an incredible way to allow followers to collect content and enable digital consumption, turning user-generated content into NFTs does come with costs associated with blockchain security and guarantee for these transactions. It is therefore important for content creators to establish whether it’s suitable to tokenize a given piece of content. Some content may not need this level of security and guarantee the blockchain provides.
Scaling Beyond Blockspace
Data availability (DA) layers are used to avoid storing data on-chain, reducing cost by simply pointing the on-chain resources into an existing data availability location (storage). Data availability layers are a convenient way to expand information linked to on-chain properties such as an NFT. Similarly, while content on Lens might include an actual on-chain transaction, the content data itself is linked into a data availability location such as Arweave, a decentralized and permanent storage network with over 100 nodes in operation and being increasingly adopted by various NFT projects including Sound.xyz and Mirror. Lens Protocol is data storage agnostic; nothing stops an application from pointing content to a cloud location to provide additional data privacy where such use-case may be suitable.
Another solution, Bundlr, enables Arweave’s scalability, providing data availability guarantees, enabling the use of Ethereum Virtual Machine (EVM)-supported wallets to save DA logic, and rapidly publishing data to Arweave. DA layers can be used to store Lens-native actions such as posts, comments, mirrors, likes, and much more. Arweave itself requires a one-time payment for data storage and is backed by mathematical and hardware history guarantees and a payment that can be paid in the future by applications that benefit from the data availability. This model is similar to cloud infrastructure, which is paid for maintaining the online social infrastructure.
Blockchains were designed for trustless transactional systems. EVM is secured by its networking and the data on-chain is immutable and verifiable at any time, ensuring trust. However, storing data on-chain is expensive, and EVM machines can only process a limited number of transactions per block based on maximum gas limits a block is configured to handle. Polygon PoS is a shared block space with 2-second block times. Therefore, some latency is unavoidable and maximum gas limits per block make scaling challenging for high-demand social media actions. However, Polygon PoS still remains a great solution to secure blockchain-based Lens artifacts such as profile and user network ownership. In fact, a lot of the user-generated content tokenization could be minted on zkEVM rollup (for highly secure computation) while using the Ethereum network as a finality layer.
For context, high-demand social experiences peak at 25,000 TPS. While Lens Protocol may not require the same level of capacity today, it is critical that we consider scalability to enable Lens to provide the social layer for web3 and support any social networking use-case. With Momoka, Lens scalability is no longer limited by blockspace.
At Lens, we believe that the web3 social infrastructure stack should be granular and purpose-built, depending on the type of networking artifacts it supports. For top-value artifacts such as user profiles, higher security is valuable. With more casual networking artifacts such as comments, a lighter, DA infrastructure layers could be a viable solution. Additionally, the end-user consumer experience directs this stack from one use-case to another.
The Lens-Native Hyperscaling Solution
Momoka is an Optimistic L3 scaling solution that processes Polygon transactions off-chain to achieve hyperscale and to reduce transaction costs. While it’s important to use the blockchain to provide user ownership and control, Momoka adds a new solution for social networking that enables Lens to provide greater scalability. Momoka does not compress transactions into an L1 similar to L2 solutions, instead it sends transactions to data availability layers to optimize the cost and achieve higher scalability needed for social media networking, avoiding the limitations of blockspace or blocktime configurations.
Momoka is open-source software that anyone can run as a node in real-time to operate a trustless transaction submitter and verifier to validate Lens data availability publications and related actions. Ideally running a sole verifier is sufficient to achieve certainty. The long-term goal is to expand Momoka to work as a full network agreement infrastructure where a publication can be submitted and validated by multiple Momoka nodes to increase the validity of a publication.
Momoka is built in a way that it does not have any dependencies on connectivity layers such as the Lens API; node operators can operate the node completely independently, meaning that you can always prove the validity of content even if the Lens API or any third party access points to Lens Protocol cease to exist. Momoka also supports indexing - meaning that with Momoka, node operators can stream and index Lens data without any third party retaining and enlarging the Lens permissionless data infrastructure.
Starting today, to run a Momoka node and contribute to the Lens ecosystem, go to this section to start validating Lens data availability transactions.
How Does Momoka Work?
Lens Protocol is currently deployed on Polygon, an EVM-based network. All actions—such as posts, comments, mirrors, follows, and collects are transactions that are constructed, signed, and sent to be stored on the EVM machine. Unlike the EVM process, Momoka constructs the transaction, requires a signature from a wallet (that would pass the state on-chain) but does not send and broadcast the actual transaction on-chain.
Instead, the transaction signature and typed data are used to create DA metadata as a transaction. This transaction is then transmitted to a DA layer containing information such as the block number and block hash when such a transaction was created upon, signed typed data, transaction signature, and other crucial details. This data is structured in a way that can be fully verified with only an archive node.
EVM machines function as large state machines. The EVM JSON-RPC methods allow transactions to be simulated using eth_call, which determines the outcome of a transaction (with certain limits) without actually sending it. You can specify a block number to run the simulation and use the signed typed data transaction with the typed data. This can be done with every withSig method on Lens Protocol smart contracts. With simply a Polygon node, anyone can verify that the data on the DA layer is accurate and would have been valid at that point in time and compliant with Lens Protocol smart-contract rules.
Momoka allows the Lens ecosystem to scale to higher TPS, which is currently unattainable while running on an EVM chain, and providing a cost-effective and low-latency solution. This can be achieved without compromising the core values of user ownership and control over their profile and social graph. At the same time, the indexing process remains familiar for app developers. Using Momoka is optional; those who prefer can continue to store everything on Polygon. However, if a publication doesn't require the power of a trustless execution layer, there's no need to use the EVM state.
Momoka enables node operators to verify that a particular action would have been executed on-chain in compliance with the Lens protocol smart contract rules (or validated against any other smart contract rules), while at the same time storing the transaction itself in a data availability layer for validation purposes.
Momoka involves performing the same signing actions as would be performed on an EVM chain, but without actually sending the transaction on chain and consuming the gas required to execute the transaction in the EVM state. Instead, a data availability transaction is created based on a Momoka recipe and exported onto a DA layer, complete with proofs and required information. The solution enables anyone to cross-check the data, providing guaranteed proof that the action must have been performed by a user with the capability of creating the transaction signature and submitting it. The transaction itself is demonstrated by a simulation. This approach allows Lens to scale while maintaining the ownership and trust provided by the blockchain, where and where needed, depending on the use case and type of content.
Because data is stored on a decentralized layer, no centralized entity controls the content. Users retain ownership of their publications and if any part of Lens Ecosystem were to dismiss, the data would remain verifiable, accessible, and usable by anyone. This demonstrates the power of decentralization, ensuring that users' data commits cannot be tampered.
Roles in The Momoka Garden
Submitters 🗳
Submitters are responsible for validating and constructing the DA metadata and submitting it to Arweave. After generating proofs with the DA submission, the data is uploaded to Arweave via Bundlr, with an instantaneous response. The submitter must provide proofs that anyone can contest. Verifier software listens for DA publications sent from whitelisted submitter addresses and verifies their validity.
To maintain trust, submitters are held accountable for their actions and face potential penalties for misconduct, verified by a network agreement. Initially, the submitter whitelist will consist of a single address operated by Lens core team. As the approach is proven, the system will be expanded to allow anyone to become a submitter, with incentives for good behavior and penalties for bad actors. If submitters have nothing to lose, they could flood the system with invalid submissions, overwhelming verifiers, and causing delays.
During the beta phase, the Lens team will be responsible for correcting any errors. Bug bounties are planned for the post-beta period. Ultimately, our goal is to have multiple submitters contributing to the system very soon after the beta launch.
Verifiers ✅
Verifiers are tasked with monitoring DA publications from submitters and confirming their validity. They must follow specific criteria when evaluating incoming publications, with the primary goal of ensuring submitters are truthful. Anyone can run a verifier using open-source software with a few commands. The verifier utilizes LevelDB for quick storage of results. The code has the capability to use a forked archive node with Foundry's anvil for local machine execution. However, for optimal speed, it is recommended that an archive node be used for now. All that's needed to run a verifier is an archive node.
Timestamps ⏳
You might be concerned that a submitter could deceive you about which block to submit on, but that's where Bundlr timestamp proofs come into play. In addition, each signature has a deadline that corresponds to the timestamp of a mined block, rendering the signature invalid if sent. Bundlr enables you to request a timestamp proof that returns the current timestamp while storing it, allowing anyone to verify their timestamp. This becomes our source of truth for determining the appropriate block number to use; we should use the block number closest to the timestamp generated by Bundlr. It's important to note that latency will inevitably occur due to node software, so if it selects a block number and upon verification, it is one behind, we consider this an acceptable threshold.
Backwards Compatibility
Signless
Great user experience is essential for Lens users. DA publications work with the dispatcher, which can post, mirror, or comment on users' behalf. If enabled, it will pass state checks. The Lens Protocol contract logic states that if the dispatcher signs on behalf of the user, it will result in a valid transaction. Users who don't want to trust the dispatcher can still sign the typed data with their wallet and submit it through the submitter. This process is similar to the current flow, but the transaction is sent to a Momoka submitter instead of a Polygon node.
Gasless
DA operations don't require gas, making them free to use. A client still needs to upload the contentURI to a resolvable location. The submitter pays for storage of DA metadata on Arweave via Bundlr, which is significantly lower cost than executable EVM transactions (up to 1000x lower cost).
Collects
Collecting user-generated content as NFTs has been a crucial monetization layer across the Lens Protocol. While Momoka transactions are not on-chain transactions, the creator or the consumer of the content can lazy mint content on behalf of the creator in cases where these parameters are set by the creator to enable tokenization. This would mean that any content can be tokenized, where there is the intent. We are expecting integrators to make lazy minting on Polygon a feature as well as to roll out this feature on Momoka.
Momoka Explorer
To make it easier to find any transaction made with Momoka, we built the Momoka Explorer (momoka.lens.xyz) to track and find Momoka transactions and to monitor the throughput speed of Momoka. You can find all the specifics of the transaction and all the relevant data.
Momoka Explorer allows you to also verify the transaction through your own node as well.
Our vision for Lens is to be the flexible social layer stack for web3. Many of the vexing challenges decentralized social networking have are related to providing sufficient guarantees to support users ownership and freedom from walled gardens and enabling extremely high throughput that social networking requires and consumers expect. It’s a problem that web3 must solve.
By introducing Momoka into the Lens stack, builders have more options to support web3 users and unique use cases to support differentiated consumer experiences. Feel free to post your thoughts on Lens with hashtag #Momoka. We would love to hear from you.
Momoka Roadmap
Momoka beta is live now. Anyone can use a Momoka node validator to prove and validate transactions. Currently, supported transactions include publishing publications, comments and mirrors. In the near future, we will support the ability to post data availability comments into on-chain publications and vice versa, while now they are limited to either or.
In the future, Momoka transactions can be performed as a network agreement, meaning that multiple nodes must verify a transaction to ensure its validity and peers can contest each other’s verifications. The network agreement can be accompanied with incentives and slashing mechanisms to maintain the validity of the agreement — if the community is eager to explore this idea.
Since Momoka is open-source software, anyone can contribute and help to improve it. Our team will keep improving the source code and adding features as we learn more about how Momoka works at hyperscale.
Momoka is designed as a node network that can be used as a general-purpose data scaling solution. Momoka could be used by other use cases outside of social networking. We would love to hear your ideas and get your feedback on how Momoka could help your project to scale for mass adoption.
Since our team is building in public, feel free to look into the code repository here to learn more about the Momoka technical implementation and feel free to commit to the code to help us improve scaling for web3 social.
