Understanding opcodes gives you deeper insight into gas costs, optimization opportunities, security considerations, and how contracts truly behave on-chain. This article breaks down what opcodes are, why they exist, how they are used, examples of inline assembly in Solidity, and touches on formal verification.

What Are Opcodes?

Opcodes are the primitive instructions of the Ethereum Virtual Machine. Each opcode is a single byte (0x00 to 0xff), defining a specific operation the EVM can perform.

The EVM is a stack-based virtual machine: most opcodes pop operands from a 1024-item stack, perform an operation, and push results back.
Opcodes interact with memory, storage, the program counter, and the outside world (calls, blockchain data, etc.).

The full opcode reference is available at evm.codes, an interactive playground where you can explore every opcode, its gas cost, and stack effects. I strongly recommend to have a look at that.

Why Does the EVM Need Opcodes?

The EVM must run deterministically on thousands of nodes worldwide, without relying on any operating system or external dependencies.
A simple, well-defined instruction set (the opcodes indeed) achieves this.

Opcodes enable:

• Deterministic execution → Every node reaches the same result.

• Gas metering → Each opcode has a precise gas cost, preventing infinite loops and DoS attacks.

• Turing completeness → Combined with jumps and stack operations, the instruction set can compute anything computable.

• Security and auditability → Low-level operations are easier to formally reason about than high-level code.

Thus, High-level languages like Solidity compile to bytecode (an encoded list of opcodes essentially!) to ensure compatibility across the entire network.

But Wait, What's the Stack on the EVM?

The stack refers to the EVM primary data structure. It's a last-in-first-out (LIFO) array limited to 1024 slots, each holding a 256-bit (32-byte) word.
Almost every EVM opcode operates directly on this stack, instructions do:

pop the required number of items from the top -->
perform the operation -->
push the result back.

Solidity's high-level code abstracts this away, so developers rarely interact with the stack directly, but the compiler translates all expressions, function calls, and variable operations into stack manipulations.
Understanding the stack is crucial for gas optimization and for writing efficient inline assembly, where you explicitly manage stack items to achieve lower-level control or tighter gas usage.

Contract Deployment Example

When you deploy a contract, the transaction sends init code (constructor + deployment logic). This init code typically ends by returning the runtime bytecode (the permanent contract code).

A classic pattern uses these opcodes:

1. Set up free memory pointer (PUSH1 0x80, PUSH1 0x40, MSTORE).

2. Compute runtime code offset and size.

3. CODECOPY: copy the runtime bytecode (appended after the init code) to memory starting at offset 0.

4. RETURN: return the copied bytes as the deployed code.

A minimal deployment bytecode often looks like (in hex):

6080604052...6000803e610xxx56fe

Breaking it down:

• PUSH1 0x80 / PUSH1 0x40 / MSTORE --> standard memory setup.

• Later: CODECOPY (0x39) copies runtime code.

• RETURN (0xf3) finalizes deployment.

This pattern is generated automatically by the Solidity compiler for most contracts.

Example of Assembly in Solidity

Solidity allows inline assembly for fine-grained control, gas savings, or operations not available in high-level syntax.

Here’s a simple function that adds two numbers entirely in assembly:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.26;

contract AssemblyExample {
    function add(uint256 a, uint256 b) public pure returns (uint256 result) {
        assembly {
            // Load free memory pointer
            let freeMem := mload(0x40)
            
            // Perform addition
            result := add(a, b)
            
            // Store result in memory
            mstore(freeMem, result)
            
            // Return 32 bytes from freeMem
            return(freeMem, 0x20)
        }
    }
}

Another common use: efficient hashing of dynamic data:

function keccak256Hash(bytes memory data) public pure returns (bytes32) {
    bytes32 hash;
    assembly {
        hash := keccak256(add(data, 0x20), mload(data))
    }
    return hash;
}

Assembly bypasses some Solidity safety checks, so use it carefully!

Huff: Writing EVM Bytecode at the Edge of Optimization

Huff is an extremely low-level programming language for the Ethereum Virtual Machine that allows developers to write smart contracts almost directly in opcodes, with only minimal syntactic sugar in the form of macros.
Unlike Solidity, which compiles to bytecode through layers of abstraction, or even Solidity’s inline assembly, which still operates within Yul’s structured constraints, Huff gives near-total control over the stack, memory, and opcode sequence.

It has no built-in types, no safety checks, and no high-level constructs; everything is explicit.
This makes it possible to produce the most gas-efficient contracts on Ethereum, often beating hand-optimized Yul assembly by a few percent.
Huff is particularly popular in the Foundry ecosystem and has been used to implement highly optimized libraries, minimal proxies, and even entire DeFi primitives.

However, the trade-off is important: the language is notoriously difficult to read, audit, and debug, and a single misplaced opcode can create catastrophic bugs.
Huff is therefore reserved for extreme optimization scenarios or educational purposes rather than general-purpose contract development.

Reference: Formal Verification

Formal verification is the process of using mathematical proofs to guarantee that a smart contract behaves correctly under all possible conditions, rather than merely testing specific cases.
Because Solidity code ultimately compiles to EVM bytecode, the most rigorous verification approaches target the opcodes directly; where the exact semantics of each instruction are defined without the abstractions or optimizations introduced by the high-level compiler.

I strongly recommend following the Solidity Assembly & Formal Verification Course from Cyfrin Updraft.

Conclusion

Opcodes are the DNA of every Ethereum smart contract. While most developers work comfortably in high-level Solidity, understanding opcodes unlocks advanced optimization, deeper security audits, and appreciation for the elegant simplicity of the EVM.

Be careful tho! Using assembly or huff can lead to unexpected errors. be sure to use these way to write code very carefully, and balance your needs. Always ask yourself if you really need to use that to ship mainnet contracts.
Personally I prefer readability vs efficiency if the marginal improvement of contract efficiency is low. But hey, there are crazy and skilled solidity dev out there.

Whether you're minimizing gas, writing libraries, or diving into formal verification, spending time with opcodes pays off.
Start exploring at evm.codes, try disassembling your own contracts and see the magic underneath.

Never Stop Building please, comment and subscribe. Thanks! 🙏

What Is Precision Loss?

Precision loss in Solidity refers to the inaccuracy or truncation of numerical values during computations, particularly when dealing with division or representations of fractional numbers.
Unlike languages with built-in floating-point support, Solidity uses integers for all arithmetic. This means any operation that would produce a fractional result gets rounded down to the nearest whole number, discarding the decimal part.

For example, consider a simple division:

uint256 a = 5;
uint256 b = 2;
uint256 result = a / b;  // result = 2 (solidity truncates 2.5 to 2)

Here, the expected mathematical result is 2.5, but Solidity outputs 2, losing 0.5 in precision. This isn't a bug. It's how integer arithmetic works. It can accumulate errors in financial calculations, such as token distributions or interest accruals.

Precision loss isn't limited to division; it can also occur in overflows, underflows, or when scaling numbers to simulate decimals (like using 18 decimal places for ERC-20 tokens).

Why Does It Happen?

Solidity's design prioritizes security and predictability over flexibility. Floating-point numbers are avoided because they can introduce non-determinism (due to hardware variations in IEEE 754 implementations) and potential exploits in consensus-based systems. Instead, all operations are performed with fixed-size integers, where:

• Division is floor division: Any remainder is discarded. For instance, 7 / 3 = 2 (remainder 1 is lost).

• No native decimals: To represent fractions, developers must use scaling factors (multiply by 10^decimals), but improper handling leads to truncation.

• Overflow/Underflow risks: In versions before Solidity 0.8.0, unchecked arithmetic could wrap around uint8(255) + 1 = 0, exacerbating precision issues. Post version 0.8.0, operations revert on overflow by default.

The root cause is the absence of fractional representation. Numbers are treated as whole units, so operations like averaging or percentage calculations inherently lose detail unless mitigated.

Numerical example: Suppose you're calculating 10% of 123 tokens. Naively:

uint256 amount = 123;
uint256 percentage = 10;
uint256 result = (amount * percentage) / 100;  // (1230) / 100 = 12 (loses 0.3, actual 12.3)

The true value is 12.3, but you get 12, a 2.4% error relative to the expected amount.

Common Scenarios and Ways to Avoid Them

Precision loss often surfaces any contract handling value distributions. Below are typical cases with code examples, followed by avoidance strategies.

Scenario 1: Token Distribution or Airdrops

In an airdrop, you might divide a total supply among users. Truncation can leave tokens undistributed.

Example Code (with Loss):

contract Airdrop {
    function distribute(uint256 totalTokens, uint256 numUsers) public pure returns (uint256 tokensPerUser) {
        return totalTokens / numUsers;  // E.g., 1000 / 3 = 333 (loses 1 token, actual ~333.333 each)
    }
}

For 1000 tokens and 3 users: Each gets 333, totaling 999, 1 token lost forever.

Avoidance: Use Remainder Handling or Scaling: Distribute the base amount and handle remainders separately (like send to a treasury). Or scale up before dividing:

contract SafeAirdrop {
    function distribute(uint256 totalTokens, uint256 numUsers) public pure returns (uint256 tokensPerUser, uint256 remainder) {
        tokensPerUser = totalTokens / numUsers;
        remainder = totalTokens % numUsers;  // Capture lost part (e.g., 1000 % 3 = 1)
        // In practice, add logic to distribute remainder
    }
}

This ensures accountability for every token.

Scenario 2: Interest Calculations in Lending Protocols

Calculating compound interest or yields often involves fractions.

Example Code (with Loss):

contract Lending {
    function calculateInterest(uint256 principal, uint256 rate) public pure returns (uint256) {
        return (principal * rate) / 100;  // E.g., 1000 * 5 / 100 = 50 (fine), but 1000 * 4 / 100 = 40 (actual 40)
        // Issue amplifies with smaller rates: 1000 * 1 / 100 = 10 (fine), but uneven principals like 999 * 1 / 100 = 9 (loses 0.99)
    }
}

For 999 principal at 1%: Expected ~9.99, but gets 9.

Avoidance: Multiply by Scaling Factor First Use a higher precision denominator (e.g., basis points: 10000 for 0.01% granularity).

contract SafeLending {
    uint256 constant BASIS_POINTS = 10000;
    
    function calculateInterest(uint256 principal, uint256 rateInBasis) public pure returns (uint256) {
        return (principal * rateInBasis) / BASIS_POINTS;  // E.g., 999 * 100 / 10000 = 9 (for 1%), but for finer: 999 * 99 / 10000 ≈ 9 (still truncates, but closer)
    }
}

For even better precision, use libraries like ABDKMath64x64 for fixed-point arithmetic, which simulates floats with 64-bit integers.

Scenario 3: Exchange Rate Conversions

Swapping assets (e.g., ETH to tokens) using oracles can truncate values.

Example Code (with Loss):

contract Exchange {
    function convert(uint256 ethAmount, uint256 rate) public pure returns (uint256 tokenAmount) {
        return ethAmount * rate / 1e18;  // Assuming rate is scaled; e.g., 1 ETH = 2000 tokens, but if rate=2000e18, division truncates fractions
    }
}

If ethAmount=1 (1 wei), small fractions vanish.

Avoidance: Order Operations Carefully Always multiply before dividing to minimize loss:

contract SafeExchange {
    function convert(uint256 ethAmount, uint256 rateNumerator, uint256 rateDenominator) public pure returns (uint256) {
        return (ethAmount * rateNumerator) / rateDenominator;  // Multiply first to preserve scale
    }
}

Check for overflow using SafeMath (from OpenZeppelin) in pre 0.8.0 Solidity:

import "@openzeppelin/contracts/math/SafeMath.sol";

contract WithSafeMath {
    using SafeMath for uint256;
    
    function safeOp(uint256 a, uint256 b) public pure returns (uint256) {
        return a.mul(b).div(100);  // Safe mul/div
    }
}

How to Make Sure It's Not Happening

To prevent precision loss from slipping into production:

• Unit Testing: Write tests asserting expected outputs, including edge cases (e.g., small/large numbers). Fuzz testing is much needed here!

  // In a test file
  function testDivision() public {
      uint256 result = 5 / 2;
      assertEq(result, 2);  // Expected truncation
      // But for safe version: assertEq(safeDivide(5, 2), 2); // Add custom checks
  }

• Static Analysis: Tools like Slither or MythX can flag potential integer overflows or truncations.

• Fuzz Testing: Use Echidna to input random values and check invariants (like total distributed == total supply).

• Audits and Simulations: Run simulations with real numbers. For example, simulate 1000 iterations of interest accrual and verify cumulative loss < threshold.

• Libraries and Best Practices: Always use OpenZeppelin's SafeMath or Math utilities. Monitor for reverts on overflow in Solidity >=0.8.0.

• Monitoring: In deployed contracts, emit events for calculations and monitor off-chain for discrepancies.

• Ask AI bro: Asking AI is a first approach to quickly scope if there are integer and precision loss issues

• Check Solodit: Go to the checklist and filter by "precision" keyword. It will give you all the know common bugs (and ways to fix) when working with numbers.

By integrating these into your CI/CD pipeline, you can catch issues early.

Conclusion

Precision loss in Solidity is a subtle yet critical issue stemming from its integer-only arithmetic, which prioritizes blockchain safety but demands careful handling from developers.
It commonly arises in distributions, financial computations, and conversions, but can be mitigated through operation ordering, scaling factors, remainder management, and robust libraries. Proactively testing and auditing your code ensures reliability, preventing costly errors in immutable smart contracts.
As DeFi and Web3 evolve, mastering these nuances is essential for building trustless, accurate systems.
Remember, on the blockchain, every wei counts. If you're developing a contract, start with thorough math proofs and end with comprehensive tests to safeguard against precision pitfalls.

Farcaster co-founder Dan Romero Announced on January 21, 2026:

Neynar is acquiring Farcaster. Over the next few weeks, we’ll transfer ownership of the protocol contracts and code repositories, the Farcaster app, and Clanker to Neynar. They will run and maintain everything going forward.The Merkle team, including founders Dan Romero and Varun Srinivasan, are stepping back from day-to-day ops to chase new adventures. Neynar steps in as the new steward, promising to maintain the protocol, run the client, and keep pushing the ecosystem forward.

Why this acquisition makes sense (but still stings)

Neynar has been deeply embedded in Farcaster for years. They're the fastest way to build miniapps, clients, AI agents, and more. Hundreds of projects, like Rodeo or all the miniapps built by @Builders Garden , rely on their tools.

Acquiring the protocol isn't just a buyout; it's vertical integration. Neynar was already the plumbing; now they're owning the house too.

Farcaster hit a $1B valuation peak after raising big from Paradigm, a16z, and others, but growth stalled. The social-first dream didn't deliver sustainable traction. The wallet pivot tried to flip it to "come for the tool (trading/wallet), stay for the network," blending SocialFi with speculation. Clanker added fuel by making token launches dead simple via casts.

But drama ensued: builders felt sidelined, key people like Cassie proposed radical decentralizations (multi-chain IDs, open consensus, shared curation), and the trader focus alienated some OGs. Now, with founders exiting and Neynar in charge, it signals a reset.

What changes for builders vs. traders?

Neynar's DNA is builder-first. They've built their entire business around making Farcaster easy to build on like APIs, analytics, push notifications, quick-launch tools for mini-apps. Unlike the recent Merkle era's heavy trader push.

@rish says that the vision is to "Enable builders to go from idea to recurring revenue, supported by a builder-first network." and that's for sure good news for builders.

This could be the swing back toward empowering creators, devs, and independent clients. The protocol stays open and permissionless, but with Neynar running the show, expect more focus on infra improvements, easier onboarding for builders, and less emphasis on turning the app into Base App 2.0.

Of course, Clanker stays. Token launches aren't going anywhere. SocialFi isn't dead. But the tone might shift from speculation-first to innovation-first.

The big question now

After the wallet pivot chased traders and sparked builder exodus... will Farcaster switch back to support builders instead of traders?

What do you think? reply below or cast your take.
Is this the revival Farcaster needs, or just another chapter in the drama?

Dan Romero, Farcaster founder, made headlines with a bold strategic pivot, announcing a substantial change in the Farcaster client: it will become a wallet first social app.

From a Twitter-like social network, Farcaster's app is set to evolve into a wallet and trading platform, leveraging its existing social features.

He and co-founder Varun Srinivasan, after over five years of development and a $1 billion valuation, announced that the social-first approach hadn't achieved sustainable product-market fit.

Coupled with the October acquisition of Clanker, an AI token launchpad, this has positioned Farcaster as a contender in the SocialFi space, blending social elements with finance.

This move has sparked mixed reactions: excitement over potential growth and revenue, but concerns about abandoning its decentralized social roots.

This article dives into Farcaster's journey, the pivot's details, controversies, and what it means for users and the ecosystem.

What is Farcaster?

Farcaster, launched in 2020, aims to create an at-scale decentralized social networking protocol used by 1 billion people daily.

Unlike other centralized platforms like X, Farcaster emphasizes "sufficient decentralization" a pragmatic approach that balances decentralization with usability.

The protocol includes core elements like casts (posts), follows, reactions, identities, and now wallets, all permissionless for developers to build upon.

Farcaster is the protocol, allowing anyone to build clients (apps) on top of it. Originally, it was just the protocol, with Warpcast as the official client developed by the team. Now, 'Farcaster' refers to both the protocol and the official client, built by the company Merkle Manufactory.

A Farcaster Historical Breakpoint

During the last week, a huge mess happened on Farcaster, so huge that someone decided to dismiss all his 40+ Farcaster miniapps.

Why?

Dan Romero posted this cast which probably will mark a decisive breakpoint in history of Farcaster:

TLDR: no sustainable growth with the social-network-first client so they are switching to build a wallet.

They realized that the wallet is the ultimate mean of traction for the protocol.

He mentions that Merkle will adopt a "come for the tool, stay for the network" strategy to acquire more users.

Dan and Varun aim to develop a compelling tool, likely marketed as a wallet, to encourage downloads of the Farcaster app. They will rely on its built-in social features to drive long-term user retention.

In the same direction of this shift from decentralized social to wallet first app, a few posts by Varun and team during the last month outline the trend of Merkle to go in that direction:

• end of creators rewards - no change to dev rewards for miniapps yet

• other new features already in current version of wallet, like the possibility to comment a swap you made

• some possible native functionalities on the roadmap of the farcaster wallet: limit orders, HL perps, private wallet copytrading and... an appcoin launcher?

And Farcaster team also pushing other clients, as shown in this cast:

As I'll talk about in the article, Farcaster shift is aimed to point more in the direction of giving the users a mean to trade & speculate, built for traders. Dan published, some months ago, some words on his personal website about that, quoting:

in crypto you need speculation, in order to make revenues.

Farcaster Dramas

Cassiegeddon

Community looks very disappointed from this pivot.

Cassie, previously a member of Farcaster team, expressed her dissent on the new shift:

Already against the incentive model of crypto+social networks, she publicly express dissent regarding the pivot, emphasizing that the issue isn't the wallet's quality but the broader cultural shift away from Farcaster's original decentralized social focus and the lack of clarity of the team.

What did she do? 3 proposals (I love the pragmatism of this girl):

These three proposals from Cassie aren't just technical tweaks. They're screaming a clear message about Farcaster's current state.

Proposal #256: Opportunity For Another Chain

Snapchain (the blockchain layer behind Farcaster identities) is too dependent on Base. If one corporate-backed chain dominates, it threatens the "sufficiently decentralized" promise, one company could potentially censor or control parts of the protocol.

Solution: Let Farcaster support multiple chains for storing and resolving FIDs (user IDs) and fnames (usernames), making identities truly pluggable and resistant to single-point control.

Proposal #257: Opportunity For Another Consensus

This proposal is around the governance & consensus model. Currently Farcaster relies on Proof of Authority (PoA) which is a consensus mechanism where trusted, pre-approved validators validate transactions and essentially govern the protocol.

Farcaster has five consensus set member owned by the same company, and the proposal aims to decentralize that.

Solution: Open up validator spots to the community or switch to a more open consensus model (modern PoW or PoS) so no single entity holds the keys.

Proposal #258: Opportunity For Another Curator

This is proposal address a hidden challenge in growing decentralized social platforms: creating good feeds (the "For You" or following feed that keeps people scrolling).

Building a good feed is expensive and complex. Right now, every client team has to build their own from scratch, which slows innovation and hurts client diversity.

Solution: Make curation a core protocol feature, let anyone create and share public feeds (algorithmic, manual, personalized) that any client can use. This lowers barriers for new clients and turns curation into a shared strength.

What are these proposal are really saying?
Farcaster protocol is not "sufficiently decentralized" yet; there's still too much trust placed in Merkle and Base, and building a real alternative client remains hard and costly.

Cassie - many others agree with her - says: You're pivoting the official client to a wallet, that's your call, and fine. But at least give the rest of us the tools to build meaningfully on the protocol without being completely dependent on your decisions, Base, or Merkle's infrastructure.

Zingergeddon

In the same period, @zinger joined the Merkle team to drive trader outreach and growth.

From what I've gathered from Zinger's social media, he has a background in startups and product growth, and he's clearly passionate about trading, particularly memecoins. His Farcaster profile is filled with discussions on tokens and market trends.

As Farcaster pivots from a social network aimed at attracting builders to a wallet-centric app, the team now needs to onboard traders, and Merkle requires someone fluent in their language to facilitate that process.

Zinger's hiring was not without controversy. If you're like an old Italian nonna from a small village, craving gossip and pointless arguments, grab your popcorn and read here, here and here . I won't dive deep into it, as it's not crucial for understanding Farcaster's future, but it highlights community reactions to the strategy shift.

What Happens To My Miniapps???

In my opinion, they very likely will stay: they will maintain the infra to have miniapps on farcaster but it won't be the main focus of Farcaster client from now on.

Builder rewards were already dismissed, and now you get some incentive if your miniapp is between the first 100.

Will they remove these kind of incentives? Will they remove support for miniapps? comment and tell what you think about that.

If you ask me to imagine the new Farcaster wallet, I would just get the Base App, with a miniapp section, change colors and font, then add some features like integrated Clanker and here you have the new Farcaster Wallet.

What Clanker Acquisition means in this context?

Farcaster acquired Clanker.

Clanker is a platform to make tokens fair launch. You can do so using the app, by tagging @clanker on a farcaster cast, through the API or the SDK. It makes it very easy to launch a token.

This move puts Farcaster on the same playing field as Base App + Zora.
Base App relies on Farcaster protocol for the social feed and on Zora to "coin content". Every post on Base App is mintable on Zora and others can buy it as a form of support.

If Farcaster wants to compete in the same SocialFi space, what was missing? A seamless way to tokenize everything. With Clanker, they've filled that gap decisively, diving much deeper into SocialFi and positioning themselves as a direct Base App rival.

As Base App uses Zora to make content coins, Farcaster uses Clanker to make appcoins. Here an example of appcoin, the presale of $HOUSE

What Farcaster users fears?

Some users are disappointed, after the pivot announcement. Why?

• Why build yet another wallet when dozens already exist, with far more experience and users?

• People worry Farcaster will turn into a "casino," with most volume from low-cap memecoins that inevitably rug or go to zero.

• Sure, data shows the wallet driving recent traction, but if it's mostly speculative trading of low-value tokens destined to crash, is that really sustainable growth?

• How can we build a new client on Farcaster protocol if this is yet very tied to Base and Merkle and the stack to build on top of it is still not-mature?

In my opinion, Farcaster users have historically been builders. The work builders did on farcaster is amazing, and the success of miniapps is defined expecially by the social-first nature of Farcaster. If the platform changes focus, then building on farcaster won't feel as rewarding as before.

Alternatives for Users: Clients and Ecosystem Options

Dan Romero said it clearly. If you don't like the direction Farcaster client is going,

change - the f**ing - client

Which are other clients?

Base App: The biggest client so far. Run by the Base team, it's projected to have a lot of success on the wallet scene. It integrates miniapps, content coins and it is probably the inspiration Merkle team got, when reasoning on the change of shift.

Cura: Mobile first Farcaster client. It is focused on channels and you have a rank in each channel (I rank 3rd in /ETHRome channel). The more you post the more you climb the leaderboard of the channel. If you are the channel owner, you can airdrop any ERC20 to channel contributors.

Zapper: Client focused on tokens. The feed also displays what users are buying or selling.

Uno: It's in closed beta - ngl, I couldn't get a lot of info on what it is. I asked in this cast.

Recaster: Simple client to post and schedule casts on Farcaster.

Herocast: Twitter-like client. You can do pretty much everything you do on farcaster, schedule posts and analyze your engagement. It's early stage and it costs $1 to get in.

Firefly: A Farcaster client which embeds miniapps, prediction markets and a sections where users can post articles.

Degen: Client built by $DEGEN team. It has a channel based feed and it's focused on the "tipping" use case. Currenly launched as a Farcaster miniapp.

Tunecaster: Client focused on music. The feed contains songs you can listen from the client itself. You have a section with trending music, a section with users playlists. To cast on this client you need to go to the /music channel on Farcaster and post there a music video/song/playlist.

other clients in this post from Dan.

Conclusion: Balancing Growth and Decentralization

Farcaster is pivoting!

Let's tell It clearly: Farcaster will be a wallet with a social network integrated. It will be focused to make traders and speculators happy, there will be more technical trading features as Varun prophetizes on this post.

Dismissing your miniapps feels like a bit of an overreaction. With the wallet pivot potentially bringing in more users, your miniapp could actually get a more exposure… or maybe not!

If you're a miniapp developer who loves DeFi, you're actually in a great position now. The new target users aren't just builders anymore, but also traders and speculators.

If DeFi isn't your thing yet but you're a miniapp builder, now's probably the time to dive in, if you want to keep building successfully on Farcaster.

If you don't like this shift you can go to another client or build a new one yourself: While the Farcaster client will change, the protocol will remain untouched, or even improved.
I know, this last point is controversial. Currently there are no clients at the same level of Farcaster, so Dan says "go to another client if you don't like this" but man, others clients are too early. Where do I go? Where do I have fun?
I think you'll still be able to have fun on Farcaster, in a different way.

You'll likely still be able to have fun on Farcaster. just in a different way. The feed will lean more toward trading, token launches, and DeFi energy, but the core social tools aren't disappearing. It'll evolve with a new crowd.

Additionally, if you're a builder, it may be just about time to fill the gap left by Farcaster and build a new super cool sufficiently decentralized social network on top of Farcaster protocol.

And for last: Base team said there is an important announcement on 17th December for the Base app. Do you think it's something somehow related to this Farcaster Pivot?

What do you think about this pivot? Are you optimistic, skeptical, feeling a bit betrayed… or something else entirely?

referenced casts

1. https://farcaster.xyz/dwr/0x408cdcfd

2. https://farcaster.xyz/v/0xf48818f9

About the Author

My name is Fabrizio and I do developer engagement at @urbe.eth. I am a softer engineer with passion and experience in Blockchain.
I'm loving writing articles about more disparate topics. If you like it, comment and spread the voice.

More on me on my website: fabri-dev.vercel.app

Stolen arms from smart contract development

with going to crypto conferences, talks and workshops and getting bored after 5 minutes because the speaker doesn't know how to speak in public. The speaker is usually great at what he/she does but probably not great at explaining it.

YES! You're probably thinking (and you're right, baby) that maybe I'm too dumb to understand what the speaker is saying or, most likely, I have the attention span of a goldfish.

I'm confident that part of the audience is having the same experience as me, and I'm sure that there are people with an even lower attention span than mine.

I'm writing this post to give some tips to make your talk or workshop engaging, so people actually like it and understand the complex concepts you're talking about.

If you think you suck at giving workshops or public speaking, then this article can be helpful. If you think you're already a god, please read this post and comment: give me your advice and tips, as I'm here to learn as well.

A Bit on My Experience

I am a software engineer specialized in blockchain with a strong passion for explaining what I'm passionate about to others.
With Urbe I do Developer Engagement; I lead IRL Bootcamps on Ethereum since 2022. I've led 14 editions of the bootcamp and mentored more than 500 builders in more than 3 continents.

Sharing what I know

If you're leading workshops or presentations, the key is to prioritize fun.
People learn best when they're engaged, so here are some practical tips to make your sessions stick - drawn from real-world experience in blockchain education.

Voice & Clarity Matter

Too often, I've attended a talk where the speaker talked without breathing, eating his own words, with a very-hard-to-understand English pronunciation. Your voice is your primary tool: treat it like one.

• Use a microphone even for small groups. It ensures everyone hears clearly and you don't need to scream.

• Speak with enthusiasm. The tone, pace, and rhythm are important to keep the audience listening. Keep a high volume! Make the audience feel you're excited about the topic you're talking about.

• Try to keep a simple vocabulary, if possible. It makes it easy for you and the message lands more directly.

• One thing at a time. Start a thought → finish it → Pause → Move on to the next concept → repeat. Maintain order and follow a mental map. This will contribute to improving the clarity of the speech.

• Do not ramble. Think about what you're going to say and then say it. Don't think about it while you're saying it. The message will be much clearer and more direct.

• Breathe! When we are nervous, we forget to breathe and we skip words or letters. We end up in apnea. We talk too fast and no one understands. It's okay, sometimes it can happen. If you realize you mispronounced a word or you said a sentence that does not make sense, rephrase, re-say the words you meant to say. Take your time. Pause more.

• Work on your strong accent if you have one. I'm Italian and I'm not interested in sounding like an English gentleman. I just want my accent to not make the discussion impossible to follow.
  Think about a strong French or Indian accent. I understand zero when hearing people with that kind of accent. I have a lot of French and Indian friends and I love them, and that's why I constantly tell them to repeat what they said.
  I can do it with them but I cannot during a workshop. If you're French, Indian, Chinese, or any other non-native English-speaking nationality, don't take it personally.
  I probably love you, it's just advice!
  I know, that point is a big pain. The only way to solve it is to make conversations with people who have a better accent than yours or, if you want to be a pro, get some English classes.

More guidance on how to speak clearly by Vinh Giang:

Set the Stage before Diving In

Before launching into content, build rapport. Ask questions to learn about your audience: "Who's new to Solidity? Why did you sign up today, what excites you about blockchain?" This reveals their levels (beginner vs. intermediate) and motivations, letting you tailor the session.

For instance, once I thought I was going to have a blockchain session with software engineering students - the organizer said so - just to discover that people were studying business and data science.
If I didn't ask "What are you guys studying?" I could have talked about complex programming patterns or even the EVM, causing the people to say "WTF is he even talking about?" and probably leave after 1 hour. Knowing that, I could drive the workshop toward a more interesting line for them, explain blockchain use cases, and make them build an app using AI tools (shootout to v0).

Another time, I asked the attendants questions to get their general level and they were so advanced we ended up working on complex DeFi protocols. Imagine giving them a workshop on conditional statements in Solidity or loops, it would have been pretty boring.

This is the beauty of doing this job. It doesn't matter if the topic will always be the same. The workshop will always be different depending on the attendants.

Ask Questions

It's very important that if you're doing a talk or a workshop, you interact with attendants before, while, and after you are doing the workshop.

Example - asking questions: Asking before the lab starts:

• "What's your name? Where are you from? What's your background?"

• "What brings you here? What are you interested in?"

Asking while talking:

• "Raise your hands if you never heard about xyz"

• "Who likes abc? Who ever tried to do efg?"

• Even a simple "Does what I just said make sense?"

Asking after the workshop is done:

• "Did you like the talk?" is the question I always ask. I also ask if there was something specific they didn't like. Criticism is the only way I can improve.

Try to engage as much as possible. I try to ask a question every 5 minutes I'm talking. If they don't answer the question I asked, I don't go on. I need them to answer. If they don't, it means they are not following.

Do Is Better Than Just Listen

The more interactive → the more fun → the more attendants retain. Try to think about something they need to do. For workshops like the ones I do (on blockchain) it's easy: Just let them build something. Prepare a small project idea with some milestones.
Generally, I make them do a mini-app on Farcaster that uses a smart contract deployed on chain.

To prepare this, you need to have enough hours or you need to prepare a starter template so the attendants can do the task in a few minutes.

A good idea is to divide them into small teams. This will foster collaboration and will make the attendants become friends (or hopefully lovers).

You need to be willing to help them, unblock them if they get stuck (very often installing dependencies on different OSs) and pair program with them. Personally, it is the most exciting part of the job.

What if you don't have enough time? Be creative. Maybe prepare a game. Maybe use an app like Hoot!, where you can create a quiz on the topic you're talking about and let the attendants play at the end of the workshop. You can even put a prize on the quiz, so people are actually incentivized to follow.

Don't Overload These Slide

Keep slides simple and readable. Use big, bold text and limit words per slide to key phrases. Visuals over walls of text.

Remember: If you go there and you just read the slides, you could have just sent the slides and they could read without coming to your talk.

Pro tip: Add memes to your presentation. I show this when my attendees create their first wallet:

Minor Tips

• Build your style. For instance, my style is relaxed, usually informal, and very funny. I like making jokes all the time. I sometimes put music (good music) as a background to build up the atmosphere.

• Dress in a way that makes you feel comfortable and good looking. This will boost your confidence.

• Time your session: Practice to fit within limits, leaving buffer for Q&A.

• Tech check: If you do practical/technical sessions, do it yourself first to see what potential blockers the attendants can encounter.

Wrapping It Up: Turn Boring into Addictive

There you have it, simple, battle-tested tips to transform your workshops from yawn-fests into can't-miss events.
Whether it's nailing your delivery, getting to know your crowd, keeping things interactive with builds or quizzes (shoutout to Hoot! for making that easy), or sprinkling in memes and music, the secret sauce is making learning feel like play. People won't just remember the tech; they'll crave more sessions like yours.

Next time you're prepping a talk, pick one or two of these to try. Start small, iterate based on feedback, and watch your audience light up. If you're in the blockchain world, dive into urbe.eth's bootcamps for real-world inspo; we've seen hundreds of builders get hooked. What's your favorite hack for keeping things engaging?
Drop it in the comments.

Let's level up together and make every workshop unforgettable! 🚀

That’s the story of a developer trying to build a project in a 3-day hackathon with crazy, often unheard-of tech. It’s the story of a chill guy trying to build something that makes sense while winning some money and not losing his mental health. I want to describe the different phases of a hackathon and the moods I’m sure every dev’s felt at least once.

Before The Hackathon

This phase happens usually 1 month to 1 week before the hackathon. It starts when you’re scrolling your Crypto X timeline and see a big number representing the prize. And you think, “Bro, that will be easy. Few people will participate, like maybe one, two hundreds?” - 1.2k people will take part in the event- “I’m gonna win the first prize”.
Spoiler, you won’t.

In this article, I’ll describe a typical IRL (in-person) hackathon.

Signing Up for the Hackathon - Hype

“OMG!” you think. “Finally, I’ve got the perfect excuse to visit city X. I’ll low-key complete the project early before the submission deadline. I’ll prep early, submit by dinner, and then roam the city the next day!”

While you underestimate the workload needed to submit the project (it’s your 20th hackathon and you keep doing it!), you start asking your dev friends if they want to join your team.

Usually, you make a team with the first people saying yes because you need people that don’t lose time thinking. You need self-confident and efficient developers. Personally, I like a team of 3, but usually you can have a team of up to 5 people.

Here’s 7 web3 Web3 Gremlins you might team up with::

• Burned 10x dev:
  Very good with many languages, backend, and frontend. Able to make the project alone but they would never do it; they are extremely lazy. These coders have lost faith in tech and blockchain. They say the majority of things in the space are scams. They cry every night before sleeping.

• Stoned backend:
  To be able to perform, these rare devs need a fat joint. They are very skilled in smart contracts, low-level Linux, Kubernetes, and system admin. Very well-versed in managing keys across different machines, but if they lack a joint, they probably can’t do anything. These programmers can’t create a proper system design because they start tripping on crazy innovative tech only they know.

• Ninja frontend:
  They are the worst enemies of UI designers because they’re really the ones who need to put UI guys’ crazy designs in place. Very skilled and focused on details, probably they don’t lift much at the gym and usually eat vegan food.

• Jolly dev:
  They’re a 10x dev with zero self-confidence. They think they’re not too good at writing code, but in reality, they can solve any problem you have. Somehow, they always have the correct answer about why something isn’t working. They always make stupid jokes to mask their inner indecision and suffer from deep impostor syndrome. They follow the team in any decision because, after all, everything is feasible (maybe).

• The Labrador devrel:
  Angry when they’re hungry. They love blockchain and live in a magic world. They have a “Labrador” attitude, transmitting very positive vibes. They are good at programming but better at having fun ideas. Genuinely confident in the future, they talk a lot and help you until the last hour of the hackathon. They will rock the project pitch.

• Narcisist UX/UI designer:
  Artists. No one cares what they do but they’re probably a good friend to a team member. They want to have a voice in every design system choice. They want to prevail over devs and would do anything to show they’re artists and devs are just stupid workers, replaceable by AI.

• Playboy project manager:
  They just talk the talk and never walk. More useless than the UI/UX designer. They pitch the project in a way devs don’t really like because they’re not able to get the real point of the project. They drive an expensive car, and their intimate life is very active.

You team up with some of these characters. Now things are getting serious! You look for hacker houses to crash at; you hardly find one. Then you book a house near the venue. If it’s a rich country, you nearly die over the prices. Since you know you’ll spend a ton - and you split it with teammates - you think, “Yeah, I’ll grab the house with the pool to chill after hacking” - you won’t have time - “I’ll win cash, so it’s basically free.” You feel like a genius - no idea yet, but it’ll be crazy, innovative, and fully on-chain.

Can’t wait to hop on the plane to City X. You’re a bit stressed about your body shape - hackathons mean fatty food, endless snacks, and no time to move, just sitting 2-3 days straight. But you’re like, “This time it’s different. I’ll bring my girlfriend’s pink portable yoga mat, work out early before the venue. No junk food or booze.” Man, these plans sound perfect! You’re sure - even after failing this a million times - that you’re mature now, ready for an epic hackathon, coming back chill and in shape - spoiler, nope, not happening.

Brainstorming for ideas

In this phase, you alternate between creative feelings and absolute dumbness. This phase usually starts 3 days before the hackathon and can last until the hackathon begins. Sometimes, you don’t have a clear idea until the end of the hackathon, when you realize you didn’t understand anything about your own project and probably misunderstood the scope of the hackathon - no one will ever know what these Frankenstein projects are; good luck deciphering that mess.

You feel a bit anxious, and you start thinking about what you can build, trying to integrate and combine sponsors’ tech. There are a wide blend of sponsors you can use, each promising the easiest developer experience and shilling the solution to world hunger with their decentralized tech, but in reality, the docs page returns a 404, and most of the protocols are in test mode.

You lack a good idea. If you’re a new dev, you don’t know what to build because you lack experience and don’t really get what web3 is for. If you’re more experienced, you’ve probably built tons of things and have a vague feeling that web3 is for nothing really - you’re still not sure about that. It feels like web3 could have a use case, but nothing really makes sense as of today, and all the stuff you see others building is kinda lame. You feel the need to build something you’ve never built.

Anxiety about not knowing what to build grows, and you start asking your teammates until you have a call to analyze sponsors and brainstorm ideas:

1. Memecoin launcher - Buy one, hate yourself:
   Built on a new crazy L2 (no different from the hundreds of others), you can launch a new kind of memecoin: “insult-coin.” The name needs to be some sort of insult to remind you that you made a big mistake buying that shitcoin.

2. Token bridge - For the ones who like strong emotions:
   You can’t select the destination chain, and it uses verifiable randomness to pick a chain ID. Good luck, go get your tokens on a random chain.

3. Wallet idea - Fit and broke:
   A wallet where you need to do 5 push-ups every $10 transaction you make. Uses an off-chain verifiable agent to check the push-ups.

4. AI agent battles - AI chicken fight:
   You make an arena where AI agents fight each other and other people can bet. You need to actually train the model “Matrix” style. No idea how to do it, but a sponsor has this functionality. Docs will surely be easy to follow (that’s sarcasm).

5. Verifiable web3 cakes - Edible and blockchain-approved:
   Basically, you can give people a cake and verify it through a TLS signature. OK - not sure if I’m understanding this right or if there’s a hidden meaning here.

You realize those ideas are absurd and none make any sense at all.
You slam your laptop shut. “We’ll go to the venue and talk to devrels. They’ll suggest something for us to build.” Hopefully not that garbage.

Hackathon start

You get to the giant venue in City X - probably an ancient church or the first-ever stock exchange - and the funny thing is, all this grandeur and art is about to host some of the most brutal tech and innovation disasters. Teenagers mixed with 45+ year-olds are ready to build the next worthless crypto project no one will use.

You skip packing - swag’s free but you arrive late, and now they’ve only got S and M t-shirts. You grab a few, but you’re 1.85 meters tall and 95 kg - these things are tiny, like the calldata space in a smart contract call. You’ve got no choice but to wear one the next day and feel like a “sausage”.

We ask devrels for suggestions and try to tie in 2 or more sponsors for a shot at cash, until finally we get the Idea! We’ll build a simple, privacy-first portfolio manager with an intuitive UI and Account Abstraction!

Day 1 - Chill

During the first day of the hackathon, you’re definitely in chill mode. You enjoy the venue and the food! They have all sorts of things: chocolate-based snacks, buttered cookies, bags of chips. Free coffee at all hours and energy drinks. Lunch and dinner usually offer the same stuff throughout the event - usually some attempt at local food, but with over a thousand hackathon participants, making good food for that many is tough! Result: toilets are super busy sometimes, and you seriously consider sneaking into the women’s restroom since those are probably kinda empty and clean (sorry-not-sorry).

You start working and go with the project design to align everyone on what needs doing. You split the workload with your mates, and it’s usually never really fair. The problem is one of your teammates is a visionary. He’s locked in with a new kind of zk. Except for the core engineers at the labs creating this tech, no one understands what the hell it is. Your teammate decides to force it into the project, and you agree because, hey, you’re a team of pros here to innovate.

Your task is to write the smart contracts, a strategic gig since you’ve done it tons of times (it’s your actual job), and when you’re done, you can help others with more stuff, maybe integrating extra sponsor tech. Night rolls in, and you realize nothing’s really done so far because you and the team wasted time eating and chatting with randoms, like, “Hey man, what are you building?” Maybe you need to rethink the strategy and ditch some sponsor tech to actually deliver. It’s late. After a free midnight snack, hamburgers and fries, you decide it’s time to sleep. The next day, you want to wake up early, do some sports, and get back to the venue early ‘cause morning’s the most productive time of day.

Day 2 - Increasing Panic

11:00 in the morning. You overslept. You actually woke up at 9:00, but you didn’t care and shut off the alarm. No time for quick yoga or proper breakfast. You wake your mates, still dreaming about zk-powered AI agents. You throw on one of the tiny t-shirts from the venue and head out “like a sausage.” Breakfast is a cappuccino and a banana, more small talk with randoms, then back to work. Nothing works. You talk to the devrel for the sponsor tech you’re using, and he basically tells you the whole idea doesn’t really make sense. You and the team crash hard. The same devrel yesterday said, “Aw, that’s really cool, guys, definitely something we’d like on our stack,” and today he’s like, “I don’t know, guys, our stack doesn’t really support that zk thingy you’re trying, plus it won’t really make any sense.” Thanks for the bait-and-switch, bro.

Time for a new strategy. Strategy meeting outside the venue - maybe grab a beer. The plan’s literally: “Let’s go inside, find a sponsor that probably no one’s touching, and build some random thing.”
It’s 20:00, and you pick a tech - some crazy protocol with a weird programming language no one really knows. First bounty’s $5k. The example page has some use cases; we decide to fork one of those example repos and build on it.


Demo and Submission

You’re wasted. None of your positive predictions came true. You feel fat - mostly ate and yapped with fellow weirdos.
The crazy ideas you had in mind couldn’t be pulled off. Deadline’s 4 hours away, and you haven’t slept at all. Your teammate’s still wrestling with the frontend. He’s stuck ‘cause he’s used to ethers.js, but the template repo got viem, and he doesn’t get React hooks. He decides to rip everything out and use ethers.js anyway.

After a while, you and the team duck into a service toilet - the only quiet spot to record - and with your last ounce of energy, you make a 5-minute video. When you stumble out, anyone seeing you’d swear you’re on drugs. You laugh, play along, sniffle a bit.
Submission window’s got one hour left, and you need a readme. You carefully skip the “how to run locally” part because the project doesn’t actually run - it walks, maybe crawls sometimes.

Day 3 - Pitching

Pitching’s actually your favorite part. After 3 days of effort, you’ve built something that looks pretty good to your eyes. Like when your mom thinks you’re handsome, but you’re more of a sweet crocodile. You’re pitching to the main hackathon jury and the sponsors you applied for. The main hackathon jury judges your project as a whole, comparing it to all the others; the sponsors judge it based on how you used their tech.

For the main judging, you’ve got 5 minutes to connect your laptop to the screen and showcase the project. The first time you did it, you wasted time because you were so hyped you forgot how to duplicate your Mac’s screen instead of extending it. Mouth got dry, words barely came out.
But this time’s different; you’ve done it many times and gotten good. The pitch goes smooth, and the judges seem blown away. Well, they always are. Even if it’s just a Canva slide, they still go, “Wow, that’s veeeery cool! Thanks for the amazing project!”

Pitching to sponsors is easier because they already know the team and project - you’ve hounded them with questions nonstop. You keep the sponsor pitch more fun and less formal than the main judging, so the devrels factor in the “fun” vibe too.

Hackathon Ends

It’s been a hell of a ride, and at 14:00, the speaker will announce the 10 winners. You’ve got a tiny hope your project’s picked, but you also don’t want it to win because, let’s be real, it doesn’t work. Luckily, you’re not one of the winners. You watch their pitches with your mates, muttering stuff like, “Oh, that’s lame,” or “Those people are geniuses.”

Finally, the sponsor prizes announcement! Tension ramps up - you don’t wanna feel like you blew another weekend coding for nothing. But at the end, your project wins:

• $50 for deploying the contracts on some L2 chain

• $2000 as 2nd place for the sponsors you applied for!

That’s great - you feel like a genius and It wasn’t a waste of time. Sure, you dropped $4k on travel and accommodation, and the $2050 gets split three ways with your team, but you’re still stoked.
Most importantly, you had fun, made memories, and locked in new friendships. Exhausted but happy, with a bag of undersized t-shirts, it’s time to grab drinks in the City X center you still haven’t seen!

Some pictures of the teams I had the incredible pleasure to work with at hackathons:

I’m Fabrizio, proud member of @urbe.eth and smart contract guy at @beam. Sometimes I like writing articles, both technical and non-technical. I got a tiny Youtube channel where I enjoy interviewing people in web3 space.

During the last weeks, everyone's attention was so focused on speculation and shitcoins that the things I really like about the blockchain - tech and innovation - were totally overshadowed.

Today I want to try to reverse this trend and explain why you are likely to have a “one night stand” with Lens Network and probably fall in love with it.

This is my very first article, so before starting, click on the button below to subscribe to my mirror profile and get notified when I’ll write the second, the third, fourth…. 🤝

Is Lens Network Intriguing?

At the end of 2024, Lens closed an investment round for $31M to scale Lens Network, the new L2 layer aimed at revolutionizing SocialFi. Lens is set to be the fastest, cheapest, and safest Ethereum layer 2 to bring mainstream adoption to Web3.

Lens will adopt GHO as its native gas token, users will be able to onboard using social authentication and data will live in the ecosystem, not just locked in a single app.

“Ok bro, but why shouldn’t I use any other very good L2 like Base, Polygon, Optimism… Or even Farcaster!?”

The new Lens Network teases you with a sexy modular architecture, by importing the Lens Social Protocol natively and through a new concept: Lens Storage Nodes.

A Sexy Modular Architecture

Every blockchain needs to have an execution layer where transactions are processed and validated, a Data Availability (aka DA) layer to ensure all nodes can access the data necessary to validate transactions, and a consensus + settlement layer to finalize and record new blocks in the blockchain.

L1 networks are usually monolithic blockchains, meaning the nodes participating in the blockchain run all these functionalities. This represents a significant scalability limit: as the number of transactions increases, blockchain nodes must scale horizontally or vertically, which can be very expensive.

All layers are important for scalability in blockchains. Blockchains require a fast execution layer and an economical, scalable method to ensure that transaction data is always accessible for validation. The consensus mechanism (like PoS or PoW) and the settlement layer are critical as they dictate the level of security within a blockchain.

What most Ethereum Layer 2 solutions share in common is typically the consensus and settlement layer, which is Ethereum itself - pretty obvious, but it's worth pointing out!

Lens's execution layer is built using the ZkSync stack, with AvailDA serving as its data availability layer. This contrasts with other L2s like Arbitrum or Base, where data availability is managed through blobs, temporary and limited space within L1 blocks where L2 transaction data can be posted.

Using DA layers like Avail, means that as transactions number increase, the DA layer can handle it without increasing the transaction cost because it scales indefinitely.

Avail - optimized for zk stacks like ZkSync - allows Lens to have transaction costs near zero.

For this reason, Lens will be a super-sexy socialFi platform where transactions are nearly free and the network is fast and secure at the same time. If you see Lens at a party, maybe after a couple of Gin-Ts, you may have something together…

Comfort Zone: V3 Lens Social Protocol

A one night stand becomes “dating” when you have some sort of “comfort zone“ in the relationship.

The comfort zone created by Lens is defined by its built-in modules, known as Social Features, which developers can access and utilize through the Lens SDK.

Lens v3 has features - smart contracts - like Account, App, Group, Feed, Graph, and more, which are deployed on the network. Developers can use these features with a React SDK, so they don't need to learn Solidity.

Let’s make an example: To create a post, developers should just create the post metadata:

javascript

const metadata = textOnly({
  content: `Subscribe to Fabriziogianni7 Mirror folks!`,
});

And then post it on-chain with just two lines of code:

javascript

import { uri } from "@lens-protocol/client";

const result = await post(sessionClient, { contentUri: uri("lens://4f91ca…") }); // contentUri is the posted metadata uri

I think that’s the kind of comfort zone I’m looking for after a long day of coding and troublesh**ting bugs.

To avoid getting bored, developers can build custom Social Features on top of the existing ones and create unique use cases (I already got something in my mind 🤪).

Storage Nodes

Well, you began with a casual approach but now you are in a cozy relationship (you didn’t expect that right?!), and the next thing will make you able to build and have memories with your new L2 fiancee (well hopefully you’ll understand why, if not, reach out - I will explain).

A Lens Storage Node is designed to provide user-controlled, decentralized, yet efficient storage for digital content.

So far in Web3, we've seen storage solutions like IPFS, which is decentralized but does not guarantee data persistence; centralized solutions, which can be subject to censorship and unauthorized modifications; and decentralized permanent storage, which can be too expensive and not flexible or user-friendly.

Lens Storage Nodes indeed provide decentralized storage at a cost similar to that of centralized service providers, with good performance and Amazon-S3-like developer experience.

These nodes are built on top of a kubo-based IPFS cluster, exposing data interfaces via a REST-like JSON API and validating actions like update, delete, and edit using an Access Control Layer (aka ACL) based on smart contracts.

When uploading data, users can add rules (ACL) to validate future attempts to modify or delete data. All actions that edit or delete data on the storage nodes need to be signed with the user's private key, ensuring that only the data owner can modify or delete it.

Uploading a file to a storage node is easy as doing something like that:

const { uri } = await storageClient.uploadFile(input.files[0]);

Are you interested looking into Lens Storage Nodes? Your friendly neighborhood Fabrizio - that’s me, writing the article 🥷🏻- suggests you check out the docs: Lens Storage Nodes Docs.

Conclusion

There you have it - Lens Network is serious about competing with Farcaster on an infrastructure and tooling level - and it’s ready to make you fall in love.

If you have some “passion” with socialFi ecosystems like Farcaster, Len’s will be a super-sexy-bomb alternative you want to flirt with.

As Stani claims in his article: “costs on Lens are minimal enough, similar to cloud server costs, for developers to easily absorb them.”

Developers will have powerful infra and tools necessary to develop in the socialFi ecosystem and the costs will be so low that the dev itself can take care of it (bro like shipping some backend on a cloud provider; don’t you ask Jo Mama the money to do it?), finally abstracting blockchain usage from end user and creating new business models than the simple “Let’s do that in exchange of a small fee” approach.

Haven't you tried the Lens testnet yet? Here's your chance -→ ** Using Lens Network.**