Presenting 🐋 MONAD WHALES 🐋

Monitor Monad transactions in real-time!

Powered by @QuickNode Webhooks.

Link in the 🧵

1/8


Set hunting threshold from 10 $MON to 100 million $MON

2/8

Catch MEGA transactions with a multiplier

3/8

Hunt on-the-go with a mobile-friendly version

6/8

Notes:
→ Support for Monad-Mainnet will be added once the network is live and public.
→ More refinements are en route.

7/8

Happy hunting! 🎯
https://app.monadwhales.xyz

8/8

Monad Whales: Monitor Monad transactions in real-time!

More GAS discussions!

@VitalikButerin and @nero_eth are drafting EIP-7983, proposing to cap $ETH tx gas limit at 16.77M: https://github.com/ethereum/EIPs/blob/1433b4b94dcaa7a3f77784aaef228d454a62b6d2/EIPS/eip-7983.md

Let’s dive into the details... 🧵

1/7

Currently, Ethereum has no cap on tx gas limit. A single tx can consume the full block gas limit.

The max gas limit per block is signaled by the validators and is set to 36M right now.

2/7

Through EIP-7983, they propose a protocol-level max limit of 16_777_216 gas per tx—regardless of the block gas limit.

So even if validators signal 36_000_000 gas per block, no single tx can exceed 16_777_216 gas.

3/7

The objective?

→ Reduce risks of single-tx DoS attacks
→Enable more predictable zkVM circuit design
→Fairer gas allocation across txs in a block

4/7

However, it comes with a few caveats...

This change requires extra validation at both RPC and validator levels.

The RPC must check txs before adding them to the txpool, and validators must enforce the limit when building blocks.

5/7

Another thing it will introduce is a theoretical hard cap on the contract deployment size—which is set to be bumped up from 24KB through EIP-7907.

With the storage cost of 200 gas/byte, a max of 83_886 bytes contract can be deployed after this implementation.

6/7

Lastly, this isn’t backward-compatible.

Any tx specifying >16.77M gas will fail. So, complex dApps may need to split operations into multiple transactions.

Thoughts?

7/7

EIP-7983: Transaction Gas Limit Cap

Solana's new consensus, Alpenglow, just dropped and it's interesting!

Meet Votor—the voting engine that challenges traditional aspect of blockchain consensus.

Is it genius or dangerous?

Let's dive in 🧵 👇

1/11

Votor runs two voting modes simultaneously:
→ Fast track with 80% stake voting = 1-round finality
→ Safe track with 60% stake voting = 2-rounds finality

So, the blocks finalize in min(δ₈₀%, 2δ₆₀%)—whichever finishes first.

2/11

Here's how it works in practice:
→ Leader proposes block via Rotor (fast data dispersal)
→ Validators vote with notarization votes
→ If 80% agree, the block is finalized immediately
→ If 60% agree, there's a fallback round and then finalization happens

3/11

Votor uses 5 vote types:
→ NotarVote = Yes
→ NotarFallbackVote = Backup Yes
→ SkipVote = No
→ SkipFallbackVote = Backup No
→ FinalVote = Finalize

4/11

In the end, certificate thresholds are the key:
→ (Round 1) 80% notarization = Fast-Finalization
→ (Round 1) 60% notarization = Notarization Certificate
→ (Round 2) 60% finalization = Slow-Finalization
→ (Fallback) 60% fallback = Skip/Notar-Fallback

5/11

There are also safety checks baked into the protocol logic:
→ SafeToNotar = Prevents conflicting votes
→ SafeToSkip = Handles broken/lost blocks
&
→ Exclusive voting = Can’t vote for and against a same block
→ Parent validation = Ensures valid block chains 

6/11

But here's where it gets interesting...

Traditional BFT requires 67% honest nodes (33% fault tolerance). 

Alpenglow only requires 60% honest nodes with a new "20+20" failure model, assuming:
→ Up to 20% malicious actors
→ Up to 20% nodes offline due to crashes/outages

7/11

The rationale here is that in large-scale PoS systems with thousands of validators, coordinated 33% attacks requiring billions in stake are unrealistic. Most failures are crashes, bugs, misconfigurations—not coordinated attacks.

8/11

So, the gamble...

Why assume the worst-case scenario when you can optimize for the common case?

If it holds:
→ Faster finality
→ Lower latency
→ Better bandwidth usage
→ More real-world resilience

9/11

But, there are risks:
→ Deviate from 40+ years of 33%-tolerant BFT theory
→ Assume failures are usually benign

What if assumptions break? What if new attacks arise?

There is a tradeoff between proven security and performance.

10/11

So here's the million-dollar question...

Is @anza_xyz's Alpenglow consensus for @solana a breakthrough that finally matches consensus to reality? Or a dangerous gamble that trades proven security guarantees for performance gains?

Genius or dangerous?

Time will tell!

11/11

Alpenglow: Solana's New Consensus

Recently, I came across a question:

"How does Monad's 128kb contract size compare to Ethereum's 24kb, and how does it benefit the developers?"

Let's dive into exactly how the increased limit is changing the game and what it means for you as a developer! 🧵👇

1/9

Ethereum's 24kb limit (EIP-170) on deployed contract bytecode is crucial for preventing DoS attacks and ensuring manageable block processing.

However, this constraint often forces ambitious projects into complex workarounds.

2/9

Enter Monad: it raises the contract size to 128kb—over 5x Ethereum's limit!

This leap stems from Monad's architecture, built for massive parallelization and high throughput, enabling efficient handling of larger contracts.

What does this mean for the developers?

3/9

Sophisticated Logic & Richer Features

With 128kb, you can pack sophisticated logic and richer features into a single contract. No more aggressive code golfing or cutting corners to fit.

Think complex DeFi protocols, feature-rich on-chain games, or intricate DAO governance.

4/9

Reduced Fragmentation & Simpler Architecture

No more splitting contracts using proxies, diamond patterns (EIP-2535), or multiple logic contracts—which complicate deployment, security reviews, and maintenance.

With 128kb, you can build cleaner, more unified architectures.

5/9

Enhanced Developer Experience

Spend less time battling compilers and optimizing bytecode, and more time innovating and building features.

With 128kb, you can focus on creativity rather than constraint management. More building, less struggling with technical limitations.

6/9

Easier Library Integration

Leverage powerful on-chain libraries for advanced math, string operations, or popular ERC standards.

With 128kb, you have ample room to import and leverage existing, well-audited code without constantly hitting size ceilings.

7/9

Unlocking New Possibilities

This larger canvas doesn't just make existing development easier; it potentially unlocks entirely new categories of dApps that were previously impractical or too cumbersome due to size constraints.

With 128kb, you have more room for innovation!

8/9

Monad’s 128kb contract size isn't just "bigger"; it’s a meaningful leap forward in developer productivity, application sophistication, and blockchain innovation potential.

9/9


Monad vs Ethereum: Contract Size Upgrade

Ethereum is gearing up for the Pectra upgrade—combining "Prague" (Execution Layer) and "Electra" (Consensus Layer) improvements into one major milestone.

Here's a quick, easy-to-understand breakdown of the key EIPs going live! 🧵

1/14

What's the goal of Pectra?

To make life easier for validators, supercharge user accounts, and boost Layer-2 scaling across the network.

Meta-EIP tracking Pectra: https://eips.ethereum.org/EIPS/eip-7600

2/14

EIP-2537: Precompile for BLS12-381 curve operations

This enables more advanced cryptography on Ethereum, making zk-SNARKs and other zero-knowledge proofs faster and cheaper. This matters because it powers privacy solutions and scaling tech that many L2s rely on.

3/14

EIP-2935: Save historical block hashes in state

Currently, smart contracts can only access ~256 recent block hashes. This EIP extends this to ~8192 blocks, enabling new use cases for rollups, cross-chain bridges, and light clients.

4/14

EIP-6110: Supply validator deposits on chain

Currently, validator deposits happen on the beacon chain, with delays of ~12 hours. This EIP moves deposits directly into the execution layer, reducing delays to ~13 minutes, streamlining the validator onboarding process.

5/14

EIP-7002: Execution layer triggerable exits

This allows validators to exit through smart contract calls using their withdrawal keys, rather than only through beacon chain mechanisms. This creates more flexibility for staking services and liquid staking protocols.

6/14

EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

Currently, validators need 32 ETH minimum and can't stake more per validator. This dramatically increases the effective balance limit from 32 ETH to 2048 ETH per validator, improving capital efficiency in staking.

7/14

EIP-7549: Move committee index outside Attestation

A technical change that improves how validators attest to blocks, making the network more efficient by reducing redundant data in attestations.

8/14

EIP-7623: Increase calldata cost

As L2s grow, they're using more calldata. Following Dencun's introduction of blob storage, this EIP increases calldata pricing to better reflect actual network costs and encourage L2s to shift from calldata to blobs.

9/14

EIP-7685: General purpose execution layer requests

Creates a standardized way for the consensus layer to make requests to the execution layer. This enables more sophisticated validator operations and better coordination between the two layers.

10/14

EIP-7691: Blob throughput increase

This EIP doubles the blob throughput by increasing the target number of blobs per block from 3 to 6 and the maximum from 6 to 9, allowing more rollup data to be efficiently stored and processed.

11/14

EIP-7702: Set EOA account code

A massive upgrade for account abstraction! This lets regular user accounts set code temporarily for a single transaction, enabling advanced features like social recovery, batching transactions, and more without deploying smart contracts.

12/14

EIP-7840: Add blob schedule to EL config files

Makes it easier to configure blob parameters in clients. A technical improvement that helps coordinate network blob settings across forks with simplified client implementation.

13/14

Pectra's improvements for validators, user accounts, and L2 scaling show Ethereum's evolution toward greater scalability, security, and flexibility. These technical changes create a stronger foundation for the entire ecosystem.

14/14

Ethereum's Pectra Upgrade: What You Need to Know

Just read the fascinating research paper about MonadBFT — a breakthrough in blockchain consensus. 🎯

Let me explain it using something everyone can understand: giving a group presentation in class... 🧵 

1/14

https://x.com/category_xyz/status/1907442601822707922

Imagine students (validators) taking turns presenting slides (blocks) in front of the class. Each presenter builds on the previous one’s content. For fairness, there are classroom rules to follow.

But what if someone skips a teammate’s slide or pretends it never existed?

2/14

That’s why the class needs a system to ensure the presentation goes smoothly — even if someone messes up or cheats.

That system is called Byzantine Fault Tolerance (BFT) — a way to keep things on track even when some students misbehave.

3/14

Here’s how it works:

After Alice presents, the rest of the class reviews her slide. If more than 2/3 of the students agree it’s good, Bob can move on and present his own slide on top of hers.

The group approval happens through voting.

4/14

But there’s a catch:

Bob must show Alice’s approved slide when he presents. Her slide becomes part of the final deck only if Bob includes it in his presentation.

If Bob is slow, unresponsive, or dishonest, Alice’s work is lost.

This is called tail-forking.

5/14

MonadBFT solves this.

If Alice’s slide was approved, the next presenter (Charlie, if not Bob) must include it in their presentation. No one can ignore or discard previously approved work.

6/14

MonadBFT also fixes other problems:
👎🏻 Slides needing multiple rounds of review before getting finalized
👎🏻 Everyone sending votes to the whole class
👎🏻 Forced timer for everyone's presentation
👎🏻 Class stalling if someone misses their turn

7/14

🏎️ Fast Finality

In older systems, a slide needs multiple rounds of approval before it is accepted as part of the final deck.

MonadBFT speeds things up: if more than 2/3 of students approve a slide, it’s speculatively final after one round of approval.

8/14

That means everyone can safely build on it immediately — unless someone cheats and shows two conflicting versions of their slide.

And if that happens? The cheat is provable and punishable.

9/14

⚡️ Lightweight Messaging

Each student casts their vote — but only sends it to the next presenter, not the whole class.

This keeps the process smooth, even as the class grows from 5 to 500.

10/14

⌛️ No Arbitrary Delays

If Alice finishes early and everyone votes quickly, Bob can start immediately.

There’s no “wait x time just in case.” The presentation moves at the real pace of the class.

11/14

👀 Handling Absences

 MonadBFT handles missed turns gracefully. If enough students approved the previous slide, the next presenter (after the one who missed) can show that approval and continue the presentation. If not, the class can skip ahead if it’s provably safe.

12/14

A blockchain using MonadBFT is like a well-run class:
🏎️ Slides get speculatively finalized in one round
⚡️ Process scales from small to large lectures easily
⌛️ Presentation moves as soon as last slide is approved
👀 Presentation keeps going even if someone misses a turn

13/14

In short:

MonadBFT is the ultimate group presentation rulebook!

It makes sure every slide counts, progress stays smooth, and bad behavior doesn’t break the flow.

An elegant upgrade to how blockchains reach agreement.

 14/14

ELI5: MonadBFT — A Robust Blockchain Consensus Protocol

Build with @QuickNode! 🏗️

It's simple! 

Don't believe me? Check it out! 🧵

https://x.com/QuickNode/status/1836785136475746571

Blockchain Transaction Analyzer built using a QuickNode's Marketplace add-on.

https://x.com/a26nine/status/1830343918728462789

Ethereum Shanghai Tracker (Twitter Bot) built using QuickNode's QuickAlerts.

https://x.com/a26nine/status/1624152406526398464

ENS Email Notifier built using QuickNode's QuickAlerts.

https://x.com/a26nine/status/1619123688930156545

Ethereum Gas Price Estimator built using QuickNode's Marketplace add-on.

https://x.com/a26nine/status/1608128153444298754

QuickNode has a come a long way. There's Streams, Functions, and what not. Dive in at https://www.quicknode.com/!

Build On: A QuickNode Hackathon

FuelVM: A Proposed Solution to Ethereum's Scalability Challenge

@fuel_network has made significant strides since its V1. Initially a side chain, it has now evolved into an AltVM, poised to address the limitations of the Ethereum's EVM as the Execution Layer.

 🔎 📝 🧵

Ethereum's monolithic architecture consists of several interrelated components essential for network operations.

Among these layers, the Execution Layer (EL) is the core, handling transaction processing, smart contract execution, and state management.

While the EL is crucial to Ethereum's functionality, it also significantly bottlenecks overall performance due to factors like single-threaded, wasteful execution, unoptimized state management leading to rapid state growth, gas metering overhead, etc.

This leads to issues like network congestion, which impacts transaction speed and throughput, and results in high gas fees.

Although Ethereum is working to address these problems, its core design is not easily changeable, hindering its widespread adoption.

Layer-2 solutions (L2s) or Rollups address some problems but still encounter issues due to inheriting the original EVM design.

"... in fact, rollups have state size problems of exactly the same type as the Ethereum chain itself." - Vitalik Buterin

FuelVM introduces a purpose-built EL for sustainable state and high performance, aiming to help Ethereum scale to thousands of apps or app chains.

It addresses key challenges with its UTXO model, stateless predicates, and state minimization techniques, discussed below.

Attached is the comprehensive list of design considerations for the FuelVM.

FuelVM's parallelized transaction execution boosts throughput and cuts latency by splitting tasks into sub-tasks for simultaneous processing. It leverages the UTXO model for concurrent handling of non-conflicting transactions.

FuelVM's asset-oriented design enhances its parallelized execution. Built-in opcodes enable applications to create and manage native assets directly within the VM. This design significantly boosts execution performance by allowing native asset manipulation at a lower level.

FuelVM's Predicates are lightweight, stateless contracts that boost transaction processing and execution performance while supporting native Account Abstraction (AA). They enable developers to create conditional transactions with complex execution criteria within the VM.

FuelVM's Scripts are temporary logic embedded within transactions to execute specific functions or operations without permanently altering the global state.

All these features contribute to state reduction.

In the UTXO model, each transaction consumes previous UTXOs and creates new ones, resulting in localized state management. This confines state changes to the specific UTXOs involved, rather than impacting the global state.

Predicates take inputs and return a boolean value to determine transaction success. Unlike traditional smart contracts, predicates neither read from nor write to global storage. This absence of storage operations prevents them from contributing to state growth.

Scripts are ephemeral and confined to the transaction context, so they do not contribute to long-term state growth.

Lastly, FuelVM also introduces native state rehydration, efficiently managing state changes. Instead of constantly updating the global state, a FuelVM application compartmentalizes state changes into smaller, manageable segments stored as Non-Fungible Tokens (NFTs). 

By rehydrating only the state data needed for a specific transaction, FuelVM reduces the data load on nodes and speeds up state access.

In May 2024, FuelVM achieved asset transfer benchmarks of 12000 TPS per core, with potential for even higher results through further optimizations.

Fuel Network has undergone nearly half a dozen Testnet iterations, with the Mainnet expected to launch in the coming months.

That's a brief overview of FuelVM for you!

For in-depth reading, check out these materials by @fuel_network:
- https://fuel.mirror.xyz/uQxyb1o_Gu4oBSyT1ULuqRu7ffmIXuZtx9ux8ndFMXs
- https://fuel.mirror.xyz/GcCJzK05EZc3Uh1fbOuT-jxqN0nJjQn0ttSJVv9IfU0
- https://fuel.mirror.xyz/TNv7ICftL9Dy-KViULnrRZkMlGPUI6vSFicvjiaX6Ac

https://fuel.network/

FuelVM: A Proposed Solution to Ethereum's Scalability Challenge

Celestia: PayForBlobs Transactions

Dive into this 🧵 to learn about it!

@CelestiaOrg is a network that offers a scalable and decentralized solution for blockchain data availability. By separating consensus and data availability from execution, it enables more efficient and scalable blockchain architectures.

At the core of Celestia are "Blobs", which are essentially chunks of data. Celestia allows users to publish arbitrary data as blobs on the Celestia blockchain via a "PayForBlobs" (PFB) transaction.

A PFB transaction consists of two parts:
1. Blobs containing the data to be published on the blockchain.
2. An executable transaction that includes a commitment to the blob data.

Every blob posted on the Celestia blockchain belongs to a "Namespace". These namespaces allow users to focus on a subset of blobs by querying for blobs within a specific namespace. When posting a blob, assigning it to a namespace is mandatory.

A user has an option to submit blobs through a PFB transaction in
several ways, including:
• Consensus Node CLI
• Light Node CLI
• JSON-RPC API

Consensus Nodes maintain the blockchain's consensus layer. Celestia App Daemon, or "celestia-appd" binary, is used to operate Consensus Nodes.

PFB transactions submitted through a Consensus Node are directly added
to the mempool and then included in a block.

Light Nodes enable the user to perform Data Availability Sampling on the Celestia Data Availability network. Celestia Node, or "celestia" binary, is used to run Light Nodes.

PFB transactions submitted through a Light Node are routed to the
Consensus Node via JSON-RPC API.

To submit PFB transactions through the JSON-RPC API, the user needs access to a Light Node instance.

They can then submit one or multiple blobs using the 'blob.Submit JSON-RPC method.

Here's an interactive hands-on demo to generate a custom SVG, post
it to Celestia's Data Availability layer, retrieve it, and validate it. https://www.based64.xyz/

Explore the blobs and PFB transactions on @celenium_io:
- View all PFB Transactions: https://celenium.io/txs?status=success&message_type=MsgPayForBlobs
- Browse all Namespaces: https://celenium.io/namespaces
- See all PFB Transactions in a selected Namespace: https://celenium.io/namespace/00000000000000000000000000000000000000000065636c69707365?tab=Blobs

Lastly, it's important to note that the maximum blob size for a transaction is just under 2 MiB. Smaller blobs get included in blocks faster. Larger blobs leave no room for other transactions, needing higher gas prices for priority.

For more information, check out these official documents:
- https://github.com/celestiaorg/celestia-app/blob/main/x/blob/README.md
- https://docs.celestia.org/learn/paying-for-blobspace
- https://docs.celestia.org/developers/submit-data

https://docs.celestia.org/

Celestia: PayForBlobs Transactions

ERC-4337 isn't dead! The UX is being upgraded with new developments like EIP-7702, which makes it easier to integrate Externally Owned Account (EOAs) and enhances the overall experience for Ethereum users.

Dive into the 🧵 to learn more!

1/5

At its core, EIP-7702 seeks to elevate the UX of traditional wallets by unlocking features typically exclusive to smart contracts. It allows an Externally Owned Account (EOA) to temporarily function as a smart contract for a transaction.

2/5

EIP-7702 introduces a new transaction type with a `contract_code` field, allowing EOAs to temporarily adopt smart contract functionality for specific transactions. This eliminates the need for new opcodes and ensures seamless compatibility with ERC-4337.

3/5

The implementation of EIP-7702 will open doors for features like tx batching (combining multiple tx into one), gas sponsorship (allowing one user to cover gas costs for another), and account privilege de-escalation (setting specific permissions for different types of tx).

4/5

Learn more about EIP-7702 at: https://eips.ethereum.org/EIPS/eip-7702

Check out the discussion on EIP-7702 and its potential impact at: https://ethereum-magicians.org/t/eip-7702-set-eoa-account-code-for-one-transaction/19923

5/5