Momentum Episode 18 aired on August 27, featuring MultiversX Head of Technology Radu Chis and Adrian Dobrita, who leads Engineering. With two weeks to Supernova, the conversation covered what the upgrade does, what happens on September 10, and what users, builders and validators should have ready.

Six years, and the one thing that never changed

MultiversX mainnet has produced a block every six seconds since 2020. Twelve or thirteen major releases have landed on top of it by Radu’s count, including the virtual machine, the economics, the staking system and relayed transactions. The six second heartbeat stayed.

When mainnet launched, Bitcoin was producing a block roughly every ten minutes and settling in about an hour. Ethereum was around twelve seconds and needed several blocks before anything counted as done. Six seconds was, in Radu’s words, something extraordinary.

Supernova takes it to 600 milliseconds.

Why this is harder than turning a dial

Under the old design everything happened in sequence. The node proposing a block executed the transactions in it, sent the result to the other validators, who executed the same transactions themselves, and only then did the group agree on the block. Six seconds was long enough to contain all of that plus the time for the block to travel the network.

At 600 milliseconds there is no room to do those things one after another. So the team separated them. Validators now reach agreement on which transactions go in a block, while execution runs alongside that agreement rather than before it. When the agreement passes, the results are already waiting.

This is not the design they started with. The original plan, discussed as far back as 2024, aimed at one second and tried to get there by executing multiple transactions at the same time. That approach stalled above one second. Splitting agreement from execution turned out to be both faster to build and capable of going lower.

What happens on September 10

The epoch changes. Mainnet enters epoch 2233 in the early evening UTC. The network knows the new rules but is not using them yet.

A drain window opens, roughly 24 minutes. The network finishes the work it started under the old rules. Transactions are still accepted during this window, they are held rather than processed. Nothing is rejected.

The clock changes. At a specific round about 24 minutes after the epoch, block production moves to 600 milliseconds, the held transactions are picked up, and the network is running Supernova.

The window does two things. It lets the network finish work in flight so nothing is left half done across the change. It also gives the shards room to line up: each one has a small grace period entering a new epoch, and the new round duration needs them all on the same time boundary.

For users, the answer is nothing

Staking works. Smart contracts work. Exchanges work. Balances, addresses, keys and history are untouched. There is no migration, no re-staking, nothing to move and nothing to claim.

What changes is waiting. A transaction inside a shard should complete in under a second. A transaction crossing shards, which today takes around twenty seconds, lands in about two and a half. Radu’s framing was that the step from six seconds to 600 milliseconds is the one you feel, and that further reductions past this point would be real but much less noticeable.

For roughly 24 minutes on September 10, a transaction may sit before it goes through. That is the window doing its job.

It still runs on a normal computer

Supernova does not raise the minimum requirements to run a node. Four dedicated cores and eight gigabytes of RAM, the same as before, though those cores will work harder now that execution and agreement happen side by side.

Networks chasing low block times tend to need serious hardware: high core counts, large memory, heavy bandwidth between machines. Radu also raised catching up. If a node goes offline for a few hours it has to replay everything it missed. At six seconds with mostly empty blocks that is quick. At a fraction of a second with full blocks it becomes difficult.

They are not pretending to be relaxed

Asked how nervous he is, Radu admitted to a little, and quoted a professor of his: if something works the first time, it was either too easy or it is wrong. He pointed out that testnet and devnet are smaller and more uniform than mainnet, which carries far more machines, more observers, and the infrastructure of exchanges and integrators. He expects it to work, and expects some tuning afterwards.

Adrian was asked whether he would take an extra month if it were offered. He invoked Parkinson’s law, that work expands to fill the time available, and said another month would produce a fraction of a percent of improvement, with no current evidence of anything critical outstanding.

Supernova has been running on public testnet and devnet. The Battle of Nodes, run on a fork of real mainnet, surfaced a significant number of bugs, including ones sitting in the existing network rather than in the new code. Devnet’s activation was stressed with traffic and exposed an inconsistency that was then fixed.

What comes after

The team wants several weeks of stable running at 600 milliseconds before touching anything.

After that: zero knowledge support at the protocol level, where an implementation already exists and needs testing. Optimizations to how the network reads and writes its own state, already built and held back so Supernova could ship cleanly. Instant switching between staking providers, with protections against abuse. And a community request to let Guardians protect a fresh wallet immediately rather than after a waiting period.

Asked how people could help prioritize, Adrian said he would like to see the community vote on what it wants most, alongside a published status of the work already underway.

Measurements taken on mainnet before the final architecture was built suggested 400 milliseconds was within reach. 600 was chosen as the conservative starting point, and the team wants real mainnet data before deciding anything further.

Two weeks

Devnet and testnet are already running Supernova and anyone can test against them today. Radu’s closing suggestion was to try to break devnet before mainnet has the chance to break itself.

The countdown is live at supernova.multiversx.com, along with what is changing, what is not, and what builders need to check.

Episode 16 went live on June 25, with Robert Sasu, Mihai Schiopu and Lukas Seel, joined by MultiversX API developer Stefan Gutica. The conversation moved from the strange mood gripping crypto and AI, to why the agentic economy still needs a chain like MultiversX, through the security grind carrying Supernova toward mainnet, a look at what is new on the API, and a live (and gloriously buggy) demo of the new Supernova Arcade.

A Strange Moment for Crypto and AI

The hosts opened on the macro mood: equities climbing, crypto bleeding, and AI absorbing all the attention. Robert — “not the market guy,” by his own account, “just hoarding more and more EGLD” — sees no quick reversal: AI commands the world’s attention, and crypto’s old narratives no longer move it. Mihai read the moment as the start of a fresh Bitcoin cycle, with a long road ahead “in AI time.” Lukas pointed at the irony — the drawdown is arriving just as crypto finally finds real utility, with stablecoin volumes ballooning even as the majors get punished.

Blockchain Is the Missing Half of the Agentic Economy

The throughline of the episode: agents can already reason and act, but they cannot yet pay.

• The SDKs the team built for human developers, Mihai noted, turned out to be “built perfectly for agentic use cases” — an agent driving a CLI to send a transaction is a walk in the park.

• What is missing is the economic layer. An agent cannot prove who it is or who it is paying for, which makes agent payments “only half of a product.” The other half — identity, settlement, finality — is what a blockchain provides.

• Robert framed the moat plainly: no other system offers permissionless, composable actions between agents “all naturally flowing with finality, without gatekeepers, with micropayments.” A payment on Ethereum leaves you waiting; the agentic economy needs chains that are fast and reliable, which is exactly the gap Supernova is built to fill.

How the Team Builds with Agents

Both engineers now build with heavy agent tooling, and shared how their process has matured.

• Robert described “loop engineering” as the current meta — loops, state machines, quality controls, and specialized agents coordinating like a company organized around coding standards. He rebuilds his agent stack every few weeks and leans on memory vaults and lessons-learned so each agent hands context to the next.

• His contrarian note had teeth. By his own admission he is “not a Claude user at all,” favoring Gemini and any model that sticks closely to the rules over the louder frontier releases — because an experienced engineer wants the agent to follow known standards, not improvise its own. He also flagged open models catching up fast (now good enough to quantize and run at home) and waved off the recurring “too powerful to release” announcements as marketing theater.

• Mihai is building for production scale — hundreds of thousands of concurrent interactions — and noted that the hard parts are the familiar ones: infrastructure, DevOps, and robustness people can rely on at any hour.

• On security writ large, Robert was blunt: most breaches trace back to legacy software built on outdated, broken libraries, and the real fix is arming developers with agents that patch holes faster than attackers can find them.

The Road to Supernova: Security First

The heart of the episode was an honest look at what it takes to ship sub-second finality safely.

• Battle of Nodes turned the right incentives loose: bounties drew white-hats wielding AI tools to probe the code and propose fixes.

• Internally, the team runs continuous AI-assisted audits across multiple models, then verifies everything by hand. Roughly nine in ten flagged “bugs” turn out to be non-issues already caught by another check — but the hardening continues regardless, and AI is far better at finding problems than solving them.

• The core tension, in Robert’s words: “when you go from six seconds to 0.6, you want a lot of optimistic verifications, and sometimes they are too optimistic.” His example — a peer-to-peer check that trusts a hash without bounding its size — is harmless at six-second blocks but a denial-of-service vector at sub-second speed, where a hundred missed blocks would be felt instantly.

• On timing, Mihai was direct: “We are heading to Mainnet. We don’t have a date, and I’m not going to invent one.” The path runs Testnet, then Devnet, then mainnet, with a date to follow once the integration queue is clear. At least one more mainnet release is expected first, and a validator upgrade (v1.11.8) is out for node operators as routine housekeeping.

• Robert also put a recurring rumor to rest: he had spoken with Beniamin Mincu that very day. With the GitHub open for anyone to read, “everybody can see that we are working.”

On the API: WebSockets and Pagination

Guest Stefan Gutica, an xRise program alum and now an API developer (third in commits this month), walked through recent shipping.

• A WebSocket subscription feature, built for the Supernova era: at 600ms blocks, polling no longer makes sense, so applications now subscribe and get notified the moment something changes.

• A long-requested pagination feature, already in testing on Devnet, that finally lets developers page through every transaction or token holder beyond the old 10,000 cap.

• His verdict after exploring other ecosystems: “the developer experience at MultiversX is above much of the other ecosystems.”

Show, Don’t Tell: The Supernova Arcade

Lukas’s “one fun thing I coded this month” stole the back half. “I got tired of hearing about Supernova,” he joked, “so I had to actually experience it and feel it.” The result is the Supernova Arcade. It started with the Sprint game — close to 900,000 real onchain taps by the night of the episode, and past one million now — and has grown into a set of games (with a community-suggested “Wen Moon” on the way), each built to make one MultiversX advantage undeniable. A live Tug of War match promptly tripped a multiplayer bug — a fitting tribute to the demo gods — but the point held: every pull is a real transaction, and the arcade is open for anyone to build a cabinet.

P.S. The repo is open source and ready for builder contributions.

What’s Next

• Stefan: the pagination feature, shipping soon.

• Mihai: an internal agentic auditor framework that learns known attack patterns and sets agents loose to hunt them in the codebase.

• Robert: personal agents for design decisions, continuous reviews, and penetration testing — to be shared once they genuinely deliver.

The shared thread, as ever: shipping discipline through a down market.

Watch the full episode on YouTube:

A recap from the Engine Room X Space with Adrian Dobrita.

Battle of Nodes is officially over. The security track closed Monday. Around 192 submissions came in, from roughly 25 independent submitters. The team has pre-analyzed about 130 of them, with more than half already confirmed as real findings. The rest is active work.

What Battle of Nodes produced

More than internal testing could have. Community validators stressed the network in ways the team couldn’t replicate in the lab, and the results held up: under the right conditions, Supernova reached the expected throughput, maxing out at a 120,000 TPS run on the final day under controlled conditions, and reaching 1,000,000,000 total transactions in around one month of testing.

Guild Wars surfaced a throughput ceiling that turned out to be a coding issue. Fixed, binary updated, network continued. That’s the pattern — real load exposes real bugs, and real bugs get fixed in public.

The team came out of BoN with a long list of Mainnet optimizations. Not all of them are critical. Some ship with Supernova. Some wait.

Security in the age of AI

Almost every submission used AI tooling. The team is using it too. Internal audits are running in parallel with external submissions, and the overlap is high: most findings were discovered on both sides.

Two observations from Adrian worth sitting with:

Dismissing a bad report now takes real work. AI writes hallucinated findings that look plausible through two or three layers of review. The team has to dig further than before to invalidate something. The upside is that valid findings are more valuable, and the invalid ones sharpen the protocol anyway by forcing deeper inspection of adjacent code paths.

Working in public gets harder when adversaries have the same tools. A fix committed openly can expose the vulnerability it’s fixing, before the fix lands. The team is exploring a workflow where security-sensitive changes move on a private fork until ready. Non-security work stays open.

Critical fixes were never public anyway. What’s changing is the gray zone — changes that aren’t obviously security-sensitive, but that could uncover something on the version they’re patching.

Depth over edges

A recurring theme in the submissions: protections exist, but sometimes only at a single layer. If that layer changes, the protection disappears. The team is now adding defense in depth — redundant checks at multiple levels — so that future code changes don’t accidentally expose something that was previously guarded.

This is slower. It is also the reason the release deserves the extra care.

What’s actually left

In order:

1. Finish triaging the remaining security submissions. Fix what applies.

2. Apply the relevant findings from the external audit, which wrapped about two weeks ago.

3. Deploy to public Testnet, ideally in smaller validated steps rather than one large push.

4. Update public Devnet so builders who didn’t participate in BoN can validate their applications against Supernova.

5. Then Mainnet.

The shape of the timeline

Round times can still come down. CPU and memory usage can still be optimized. Those aren’t blockers for launch. They’re work for after.

What has to be true before Mainnet activation: the security backlog is clear, the audit findings are applied, Testnet and Devnet have validated the integrated build, and the team is confident that defense-in-depth changes haven’t broken anything else.

Next update: in about two weeks.

This post summarizes the X Space hosted by Code MultiversX on April 21, 2026.

You can listen to the full recording here.

On March 31, MultiversX opened the doors for a community-wide stress test called Critical Mass — the last public push on BattleNet before the focus shifts to mainnet preparation. Anyone could join, spin up a wallet, and start firing transactions at the network. The goal was to see exactly what Supernova could handle when everyone hits it at once.

The answer: 120,000 TPS. Multiple times.

A Testnet, made real

BattleNet was never a throwaway testnet. It launched from the same accumulated state as MultiversX mainnet, ran with community validators on real hardware, and had live applications updated to run on Supernova. The protocol parameters were new — 600ms block times, parallel asynchronous execution — but everything else was as close to production as you can get without actually being on mainnet.

That context matters. A 120k TPS result on a clean testnet is one thing. On a mainnet-equivalent environment, with hundreds of real participants, scripts, and agent-assisted load all hitting simultaneously, it means something different. Every number was backed by live API calls and on-chain receipts. No estimates.

For reference: 120k is the ceiling for three execution shards, not for the architecture. More shards, higher minimum specs, additional execution paths — all of that pushes the number higher. What makes the result stand out is that it was achieved on hardware modest enough to include nodes running on Raspberry Pis.

What the Battle revealed

Two and a half weeks of real load, real participants, and real edge cases did exactly what the competition was designed to do.

Bugs were found and fixed. One issue was serious enough to require a hard fork — the team had the tooling, updated it for Supernova, and got the network back up. A missed configuration affecting cross-shard transaction latency was caught and corrected. The tx pool behavior under sustained high load surfaced patterns that internal testing simply cannot replicate.

That’s the point. Internal teams cannot anticipate every way a community will stress a system. Battle of Nodes put that to the test, and the protocol is better for it.

The security track remains open through April 10 for any remaining submissions. Parallel chaos testing continues internally while the team works through the remaining hardening and performance improvements before mainnet.

The Road to Mainnet

BattleNet is shutting down. Validators who ran nodes throughout the competition can begin decommissioning. The public testnet upgrades to Supernova shortly, DevNet follows after that, and then the focus is fully on mainnet.

Two and a half weeks, hundreds of validators, guilds, and community members, one billion total transactions processed on BattleNet, and a protocol that came out the other side better than it went in.

The finish line is (very) close.

This post is based on the Critical Mass livestream from March 31, 2026. You can rewatch the full stream below:

A recap from yesterday’s X Space with the MultiversX engineering team.

Battle of Nodes is doing exactly what it was designed to do. Community validators and guild teams are surfacing real issues that internal testing can’t reach — tx pool behavior, consensus edge cases, gateway limits under load. Every finding feeds directly into the protocol before it hits mainnet. Competition extended through next week.

What Supernova is

Supernova is the largest upgrade since mainnet launch — cutting block times from 6 seconds to 600 milliseconds.

600ms was chosen because current mainnet hardware and validator liveness can support it safely. This is not the ceiling — it’s the first version of a design built to improve iteratively. Once live on mainnet, new metrics will show how much further it can go.

Pre Mainnet Testing

Every pull request goes through unit tests, integration tests, manual QA, and internal testnet validation. Larger features are tested on an internal shadow fork that mirrors mainnet state — not a clean-slate testnet.

But internal testing has limits. The team cannot anticipate every way a user — or a malicious one — might interact with the network. That’s the explicit reason Battle of Nodes exists.

Why the Battle of Nodes and Community Validators are so important

Internal testnets use different providers, but the same type of providers. Community validators bring hardware diversity the team doesn’t have access to, making the environment much closer to what mainnet actually looks like.

Geographic and operational distribution across community setups makes latency estimation far more realistic — spreading infrastructure that widely is cost-prohibitive internally.

And validators go off-script. They run tests the team didn’t ask for, and several issues were found and fixed as a direct result.

What happened this week

The BoN chain halted for roughly 24 hours. The metachain notarized blocks from shards that were no longer available — a state inconsistency that required going back to a clean state before the split. A hard fork.

The team had hard fork tooling from previous devnet runs, but the scripts weren’t updated for Supernova. Since Andromeda went live, proofs are now separate from blocks, which changes what needs to be cleaned up. Finding a round where all shards and the metachain state aligned took two days of work: updating scripts, spinning up new seeders, restarting from the target round, and packaging the binary for community validators.

The root cause: when Supernova activated, a fix for this exact scenario caused a liveness degradation and was reverted. A proper fix was prepared in the background, but the issue on BoN happened before it could be pushed. With block times reduced so dramatically, some consensus timeouts weren’t properly calibrated — allowing signatures to be sent before a proof for the previous block was received. The fix is now in and will be validated on the live BoN environment.

If it ever needs to happen again, it’ll be much faster now that the tooling is current.

More learnings from BoN

Under Supernova, the tx pool retains transactions longer, reducing space for new ones. During one Guild Wars challenge, throughput was similar to pre-Supernova despite 10x faster blocks — the tx pool was the bottleneck, not the network itself. Capacity has since been increased, and optimizations were added to ensure transactions propagate before being proposed in blocks.

The API gateway hardware was underspecced for the volume participants generated. Under high load, observers returned stale data, which caused users to submit duplicate nonces — adding noise that further stressed the tx pool.

Users stress the network differently than we do internally. One challenge saw participants spend over 20,000 EGLD in gas fees on cheap spam transactions. That kind of load pattern is hard to simulate but immediately useful for finding edge cases.

What’s next

The hard fork included several fixes beyond the root cause. These need to be validated under the same real-world conditions that surfaced them.

Validator challenges continue, Guild Wars resumes next week, and the security track — where the most impactful bugs tend to surface — remains open 24/7.

The competition has been extended through next week.

Jump in: bon.multiversx.com

This post is a summary based on the Code MultiversX thread from March 20th 2026.

You can listen to the full recordings on X.

If you read Part 1, you know the origin story: I dove headfirst into Rust, battled the Borrow Checker, and successfully deployed my Escrow smart contract (the “Brain”) to the MultiversX Devnet. At the close of that chapter, I was actively building a NestJS Microservice API to wrap my contract calls.

I assumed the hardest part was behind me. Writing a secure financial primitive in Rust is the peak of the mountain, right?

Not quite. Writing the smart contract logic is pure, isolated mathematics. Integrating it into a full-stack Web3 application is a chaotic battle of headers, cryptographic signatures, and network states.

Here is how the rest of the journey played out, from pipeline nightmares to an AI-assisted finish line.

Phase 4: The Backend Boss Fight and NativeAuth

My first major roadblock in building the bridge between Web2 and Web3 was authentication. I spent hours staring at a frustrating NativeAuthInvalidTokenError (403 Forbidden) on my Swagger dashboard. The backend was outright rejecting my requests, refusing to let the frontend communicate with the smart contract.

After some deep architectural debugging, I realized the issue wasn’t the logic itself, but the exact format of the NativeAuth token being sent in the headers. In a traditional Web2 app, you pass a standard JWT. But MultiversX requires a highly specific Base64 encoded token that combines the user’s wallet address, the block hash (as a nonce), and the wallet’s cryptographic signature. Getting the pipeline of Wallet → Auth → API to communicate perfectly was an absolute grind.

Finally fixing that format and seeing a beautiful 200 OK return on my screen was a massive relief. The plumbing was finally watertight.

But the Devnet had one more trick up its sleeve.

When I went to test my createOffer endpoint via the MultiversX Utils dApp, I hit an “Insufficient Funds” error—even though my wallet was fully funded with xEGLD. The culprit was a single, powerful tag in the smart contract: [Payable].

In the Web3 world, you can’t just tell a contract “I offer 10 tokens” via JSON arguments; you have to physically attach the cryptographic value to the transaction payload. I had to configure the transaction builder to pull the selected asset and send it alongside the function call. This strict mechanism is exactly what solves trust issues in P2P trades. It completely eliminates the dangerous “send first and pray” dynamic because everything is conditionally locked on-chain.

Phase 5: Stealth Mode & The AI Cheat Code

I took a much-needed break from public updates over the holidays to focus family, work, and rounding up school stuff (now a certified Bsc. Computer Science holder) yet to be convocated though lol. Operating in stealth mode, I finished up the backend microservices using Node.js and the mx-sdk.

It was time to tackle the frontend. Normally, this is where the long, tedious grind of building React components and wiring up wallet connection utilities begins. Instead, MultiversX released something incredible: the mx-ai-skills Pack.

This pack contained dense, machine-readable context designed specifically for AI agents to understand how to build on the blockchain. I decided to run an experiment. I fed the AI Skills pack to my agent, provided my completed backend services, and asked it to act as my co-pilot to build the frontend.

The result was staggering. It generated a clean, beautiful, fully functional interface using React and @multiversx/sdk-dapp almost instantly. AI + Web3 isn’t just an ecosystem buzzword; it became my ultimate productivity cheat code, accelerating the design phase without forcing me to sacrifice control over the underlying logic.

Phase 6: Deployment and Squashing the Final Bug

With the frontend generated, I deployed the full stack hosting the UI on Vercel and the backend services on Render.

(A quick tip for devs: Because the backend is on Render’s free tier, the server sometimes “sleeps” when inactive, meaning the initial load requires a few seconds of patience to wake up).

Testing the live environment, the flow was incredibly smooth. The seller could lock assets, and the buyer could send payment. The create_offer and cancel_offer endpoints worked flawlessly.

However, the accept_offer logic was still slightly buggy. There was a friction point in how the frontend handled the token transfer edge cases during the payment flow. After a final push of tracing WASM execution and tweaking the scenarios, the bug was squashed.

The MultiversX Escrow dApp is now fully up and running end-to-end.

True to the spirit of learning in public, I’ve open-sourced the entire project. You can explore how I integrated the Rust Smart Contract, the backend services, and the AI-generated frontend.

GitHub: https://github.com/MeetEnRich/EnR_Escrow_MvX

Live Demo:

https://enrich-escrow.vercel.app

Full Circle: The Ideathon Origin Story

Before I reveal what’s next, I need to take you back to August of last year.

Long before I wrote my first line of Rust or wrestled with NativeAuth, I attended the first-ever MultiversX Ideathon here in Nigeria (FULafia). I stepped into a room full of strong Web3 ideas and pitched a concept: a fully on-chain, decentralized voting system designed to be secure, transparent, and tamper-proof.

The judges saw the vision, and I ended up taking 2nd place.

It was a huge moment of validation, but it also came with a stark realization: I had a winning idea, but I didn’t yet know the MultiversX stack well enough to build it the right way. I needed to learn. I needed to build something complex from scratch to cut my teeth.

That is why the Escrow dApp exists. It was my training ground.

What’s Next? Project D-Vote

Now, I am returning to the project that sparked this entire journey. My next build is D-Vote, the decentralized voting system I pitched at that Ideathon. It will heavily leverage MultiversX’s unbreakable security, sub-second finality, and negligible fees to handle high-volume, secure ballot casting.

Project D-Vote is officially initiating.

Let’s build something huge.

Follow the journey on X: @MeetEnRich

Below are the key insights and takeaways.

Supernova

• Currently in a private Battle of Nodes phase with selected validator partners (Dr. Delphi, Mihai Eremia, Eddie Nuuta, xExchange) who are actively stress-testing and attacking the network

• Internal testnet survived a full day of sustained attacks; processed over 2 million transactions in five minutes on bare-minimum VPS hardware

• Edge cases found and fixed around relayed transactions, logs, trie access, and restarts

• Public Battle of Nodes expected to launch in early March (contingent on the network surviving the weekend following the recording)

• Robert compared the scope to launching a new mainnet — “changing the engine on four cars running in parallel”

AcceleratorDAO & Ecosystem Grants

• Close to $1 million in EGLD earmarked across two ecosystem grant buckets

• Grant processes will open after Supernova launches

• Structure and ideation documented in Robert’s AcceleratorDAO GitHub repository

• Core principle: grants go to projects that demonstrate real revenue and economic activity, not just pitch decks

• DAO members and processes to be voted in by the community

OpenClaw & Agent Commerce

• OpenClaw (previously ClaudeBot, then MaultBot) described as an orchestrator / squad — a long-running manager that spins up specialized agents with memory, tools, scheduling, and persistence

• Robert is working on a repository that lets developers launch an agent with MultiversX skill sets, auto-register it in the MX-8004 agent commerce contract, and monetize it immediately

• Example use case: an agent producing daily market research reports sold as a $10/day service

• Key point: the 99.9% of users won’t run their own setups — builders need to package agents into full products with proper UX

“Build for Agents” as a Design Principle

• MultiversX has adapted its documentation and repos specifically for agent consumption

• CLIs, APIs, and programmatic interfaces are now first-class because agents work best calling well-defined functions rather than generating everything via LLM token output

• Robert builds “squads” — combinations of skills, knowledge bases from MultiversX docs, and agents that dynamically select the right tools

• Non-EVM architecture cited as a structural advantage: SDKs, token system, and contract model are inherently simpler for agents to work with

Agentic Development Inside MultiversX

• The Supernova team uses agents for security auditing, penetration testing, code reviews, and automated test generation

• Robert’s workflow: architecture specs → master task list with small scoped subtasks → dedicated code review, security review, and production-readiness agents running in loops

• Features that previously took a week to code and a month to test now take roughly a day each

• Robert emphasized test-driven development, no mocks/stubs, and agent-driven architecture as non-negotiable quality practices

Advice for Builders

• Download the agent tooling, fork the agent ecommerce specs, ship an MVP to devnet in a day

• Don’t come with a PowerPoint — come with something that works

• The shift is from months-long development cycles to same-day functional prototypes

Future of Programming & Teams

• Much smaller teams; “one person ruling them all”

• Programming language mastery matters less; architecture, critical thinking, and problem framing matter more

• Companies that don’t adopt agentic development will be disrupted — Robert gave a two-year window

• MultiversX internally replaced Jira with a custom tool built in roughly one week of vibe coding by one person

Watch the full episode on YouTube:

by Lucian Mincu

Last month, Robert Sasu, one of our core engineers at MultiversX, shipped 8 production-ready repositories in 2 weeks using AI agents.

Not prototypes. Production systems. For blockchain infrastructure designed for the agentic internet.

I’ve been actively building in this space since 2017. I’ve never seen anything like it.

We’ve been running intensive experiments across our engineering team, testing different agent architectures and workflows. Robert’s output is proof the system works.

We’re now rolling out these principles across MultiversX to accelerate our development by a factor of 20.

Here’s exactly what we’ve learned and how you can apply it as a company, developer, entrepreneur, or vibe coder.

7 Principles for Agent-Native Development

1. Planning Is 80% of the Work

Plan → Work → Review → Feedback

Most teams skip planning and jump to code. This is the fatal mistake.

Across our experiments, we’ve found the same pattern: 2 days of pure planning beats 3+ weeks of chaotic iteration.

Interview sessions. Security audits. Architectural decisions. Zero code written.

Then execution becomes mechanical.

We use interview agents to surface brutal questions early. “Whitelist with known contracts or onchain verification?” Not easy questions. But answering them during specs instead of mid-implementation saves weeks of rework.

Key insight: If specifications are solid, everything else is mechanical.

2. Specialized Agents Are 10x More Token-Efficient

Generic agents burn money. Specialized agents print efficiency.

Our testing shows specialized agents use 10x fewer tokens than generalists because they think in straight lines. Deep domain expertise without wide exploration.

The agent stack we’ve standardized:

• Planner (creates master plan, assigns sub-agents)

• Language specialists (Go, TypeScript, Rust)

• Integration specialists (external protocols)

• Domain-specific reviewers

Real example from our codebase: Planner generated 100+ refactoring tasks and assigned each to appropriate specialists working in parallel. Token cost: fraction of what generalists would burn.

Most teams waste time, tokens, and talent here without realizing it.

3. Never Auto-Implement Reviews

Critical rule we enforce: Agents don’t implement their own code reviews.

Agents are yes-men during normal coding. But during review phases, they become ruthlessly critical… if you structure it right.

Our review process:

1. Agent generates review report (does NOT make changes)

2. Human reviews findings

3. Human decides what ships

4. Fresh agent instance executes approved items only

We’ve run reviews that found 100+ issues. Some were critical security vulnerabilities. Others were style preferences we rejected outright.

Auto-implementation would ship broken code with “improvements” nobody wanted.

We also run competing models. Claude writes code. Codex reviews it. Single-model workflows miss things that multi-model approaches catch.

4. Test-Driven Development (TDD) Is Non-Negotiable

Without explicit TDD mandates, AI agents skip tests like junior developers who don’t know better.

This isn’t a bug. Agents mimic how most developers actually work. The joke is on us.

The TDD workflow we enforce:

• Write minimal test

• Write minimal code to pass

• Write next test

• Repeat

Results: Clean interfaces. Code that works.

Alternative: Agents claiming “it’s done” with placeholders, hardcoded values, and missing edge cases everywhere.

We don’t negotiate on this. TDD is explicit in every workflow.

5. Enforce Architectural Boundaries

When building full-stack systems: We explicitly block agents from crossing boundaries.

Separate folders. Separate repositories. Frontend agents cannot see backend code. Backend agents cannot see smart contracts.

Why this matters: If an agent can access both sides of an interface, it will “helpfully” solve problems by changing both sides. This breaks the architectural discipline that keeps systems maintainable.

We force clean interfaces instead:

• Frontend defines what it needs from the API

• Backend defines what it provides

• Each side implements to the contract

Intentional friction creates proper design.

We also always specify for new work: “No backwards compatibility. Remove all migration code.” Otherwise agents generate thousands of tokens worth of complexity for code that never shipped.

6. Manage Context Deliberately

Agents degrade after about an hour. Error rates spike. Context windows get polluted with earlier assumptions.

Our practice: New agent instance every hour. Fresh instance for every review.

A review agent seeing code for the first time catches issues that a long-running session would rationalize away.

We’ve also found: Don’t try to manage more than 3 parallel projects per engineer. The human orchestrating the agents becomes the bottleneck.

Context management is not optional. It’s architecture.

7. Optimize Architecture, Not Budget

Most people think serious AI development requires $200/month enterprise plans.

Most of our engineers run on the $20/month Pro tiers.

The difference isn’t budget. It’s architecture.

Token optimization through:

• Detailed planning first (drastically cuts implementation tokens)

• Specialized agents (10x efficiency vs generalists)

• Small task breakdowns (each task uses fewer tokens)

• Fresh sessions (prevents exponential context growth)

We also use different models for different phases:

Claude Opus 4.5 → Planning and architecture
Codex 5.2 → Critical review, finding omissions
Gemini/Jules → Language-specific expertise

If you’re burning through token limits, your architecture is wrong.

What This Looks Like In Production

Here’s a typical production cycle using our system:

• Days 1-2: Interview sessions → specifications → security audit on specs → iteration until solid

• Day 3: Planner creates implementation plan → breaks into tasks → assigns specialists

• Days 4-5: Specialists execute (backend, frontend, integrations, documentation) with TDD throughout

• Day 6: Multi-specialist review → domain experts generate recommendations

• Day 7: Human reviews recommendations → selects critical items → execution agent implements → final review → ship

Total: 2 days planning, 5 days execution.

Without this architecture: Weeks of chaotic iteration.

The multiplier effect: We run several of these production cycles in parallel. Different engineers, different repos, same proven system. This is how you get to 20x.

Why This Matters for MultiversX

We’re not experimenting for fun. We’re pioneering agent-native workflows because we have to.

MultiversX is building blockchain infrastructure for the agentic internet. Systems that AI agents will use at scale.

Our development practices and our infrastructure are converging toward the same future. The learnings compound.

Building with agents on infrastructure built for agents creates feedback loops most teams won’t see for years.

These 7 principles survived real-world testing across our engineering team.

Core insights that proved durable:

• Specialization beats generalization

• Deliberate context management prevents degradation

• Multi-phase workflows with human oversight work

• Architecture matters more than model quality

We’re Building in the Open

Development is becoming agent-orchestration. Teams figuring this out in 2026 will 10x their velocity.

Teams treating AI as autocomplete will fall behind.

We’re open-sourcing our MultiversX AI development toolkit: the actual workflows, agent skills, and best practices we use to build production systems at scale. Optimized for the most advanced blockchain architecture ready for agentic applications.

The future of development isn’t coming. We’re shipping it right now.

→ Build the agentic internet with us

The original article was published by Lucian Mincu via X on January 30, 2026.

What started as Elrond, a vision to make blockchain fast without breaking it now stands at the edge of its biggest transformation yet. Not just making things better, but a complete rethinking of what blockchain can do when it moves at the speed of thought.

The shift from Elrond to MultiversX was never just about a new name. It was about dreaming bigger. Elrond proved that splitting the blockchain into shards could work; MultiversX is now showing something far bolder: that the supposed “impossible trilemma” of blockchain was never about limits but about not thinking big enough.

Supernova is the turning point. The moment when years of careful building come together into something that feels more like a leap into new territory.

Building The Impossible

To understand Supernova, you need to see what MultiversX already built and why that foundation makes the impossible real.

The Elrond Foundation: Adaptive State Sharding

Most blockchains that claim to “shard” are faking it. They split up transaction processing but keep everything else in one place, or they split the data but force different parts to talk to each other so slowly that it cancels out any speed gains.

MultiversX implemented true adaptive state sharding from day one. Everything, the network, transactions, and state splits up in a unique way. Three shards process transactions simultaneously, each handling its own accounts, smart contracts, and balances. A metachain coordinates everything and provides finality.

The result: add more shards, get more throughput. The design that hit 263,000 transactions per second in testing, processing ten years of Bitcoin transactions in less than a day.

But speed was never the only goal.

The Consensus Upgrade: From Waiting to Instant

Before Andromeda, MultiversX needed confirmation blocks a second round of checking to make transactions final. Block proposed at step N, confirmed at step N+1. Mathematically solid but practically limiting.

The Andromeda upgrade (May 2025) eliminated confirmation blocks completely by expanding the consensus group from 63 to 400 validators per shard. Not 400 validators total 400 per shard, with every active validator helping to validate each block.

The math changed. With 63 validators, you needed careful probability calculations to ensure security. With 400 validators the full set the security became rock solid. No confirmation needed. Finality in half the time.

Time to finalize: 12 seconds down to 6 seconds.

But Andromeda was just the setup. Supernova is the main event.

Supernova: Breaking The Chains

The bottleneck in every blockchain claiming “instant finality” has been that consensus and execution happen together. Ethereum, Solana, even advanced systems all require transactions to execute before validators can agree.

The logic seems obvious: how can validators agree on what happened if they haven’t calculated the result?

Supernova’s answer: you don’t need to.

The Big Flip: Agree First, Execute Later

Old way (Execute-then-Propose):

1. Leader gets transactions

2. Leader executes transactions, calculating all state changes

3. Leader proposes block with results

4. Validators execute the same transactions again to verify

5. Everyone agrees

6. Block is final

This forces execution into the critical path. Every validator runs the same transactions twice once to check, once to finalize. How fast you can execute code becomes your speed limit.

Supernova’s way (Propose/Vote-then-Execute):

1. Leader gets transactions

2. Leader proposes block with transaction order

3. Validators vote on the validity and order without executing anything

4. Everyone agrees on what happened and in what order

5. Execution happens separately, in parallel

6. Final state follows consensus

The separation is powerful. Consensus doesn’t wait for execution anymore. Validators agree on what happened and in what order without wasting time running the same code thousands of times.

The execution layer becomes fully parallel free to use every processor core, every optimization, every bit of computing power without holding consensus hostage.

The 10× Speed Jump

Block time reduction: 6 seconds > 600 milliseconds (at launch).

In controlled tests, Supernova hit 88-millisecond block finalization. Real-world targets stay under 300ms—faster than you can blink.

For comparison:

• Ethereum: ~12,000ms finality

• Solana: 400-800ms finality

• Sui: 400-800ms finality

• Supernova: <300ms target, 88ms achieved in testing

But raw speed misses the bigger change.

Running Everything at Once

By separating execution from consensus, Supernova unlocks true parallel processing at both levels:

Consensus runs in parallel: With execution out of the way, validator nodes can process consensus rounds at the same time as execution from previous rounds. Block N finalizing while block N-1 executes. The pipeline stays full.

Execution runs in parallel: Without consensus waiting on execution results, the execution engine can identify non-conflicting transactions and run them simultaneously across multiple threads. No artificial slowdowns. No wasted power.

The bandwidth savings are massive too. Before Supernova, validators needed execution results to reach consensus huge messages traveling across the network. After Supernova, consensus messages only contain transaction order. Execution results propagate separately, reducing network load dramatically.

The Technical Foundation: What Made This Possible

Supernova didn’t come from nowhere. It needed three previous releases, each building essential pieces:

Andromeda (v1.9.6, May 2025)

• Removed confirmation blocks

• Expanded consensus groups to 400 validators per shard

• Enabled any node to finalize a block with zero risk of equivocation

• Improved cross-shard execution (reduced from 6 blocks to 3)

• Cut finalization time in half (from ~12s to ~6s)

Barnard (v1.10.4, July 2025)

• Onchain governance (500 EGLD to propose, voting power based on staked EGLD)

• Reduced max gas factor (from 10× to 2× maximum)

• Millisecond timestamps for smart contracts (from second-based to millisecond-based)

• Updated Go toolchain

• Enhanced VM features

Barnard’s timestamp change was essential. Supernova’s 600ms blocks required smart contracts to work at millisecond accuracy. The entire developer ecosystem needed sub-second timing support.

Staking V5 and New Emissions Model (v1.11.1, December 2025)

A complete economic overhaul that replaced the genesis-based inflation model with a dynamic “Tail Inflation” system:

• First-year inflation: 8.757%

• Annual decay: 0.25%

• Minimum floor: 2%

New distribution model:

• 50% - Staking V5 (validator and delegator rewards)

• 20% - Growth Dividend (user incentives for DeFi participation)

• 20% - Ecosystem Growth Fund (DAO-governed grants and infrastructure)

• 10% - Protocol Sustainability (core engineering, research, audits)

Critically, 40% of total emissions (Growth Dividend + Ecosystem Growth Fund) only unlock if ecosystem growth KPIs are met, tying EGLD scarcity directly to network growth.

The Battle of Nodes: Testing Reality

December 2025. A coordinated stress test involving validators, builders, infrastructure providers, and community guilds. The biggest community-powered battle test in blockchain history.

It wasn’t a publicity stunt, it was a gauntlet designed to find every bug, every race condition, every performance cliff under conditions worse than real-world use.

Originally announced with a $100,000 prize pool, strong ecosystem partners like Tencent Cloud and CertiK contributed to the hackathon component, bringing the total to $150,000 across five tracks:

• Protocol Integrity: Discovering vulnerabilities, exploits, bugs, and anything that can impact the network ($50,000)

• Infrastructure: Operating public RPCs, indexers, and endpoints under load ($20,000)

• Validators: Competing on performance, uptime, and synchronization ($10,000)

• Builders: Building and testing dApps, contracts, and tools on Supernova ($10,000)

• Guild Wars: Team-based, fast-paced, high-intensity battles that push the network to its limits ($10,000)

The data from Battle of Nodes will shape the final mainnet release. This is how you prepare for a launch that sets new performance standards across the entire industry.

What This Means for Everyone

For Developers: New Performance Levels

Smart contracts running in an environment where blocks finalize ten times faster. Where cross-shard atomic operations become practical for complex DeFi protocols. Where the gap between Web2 and Web3 user experience narrows to nothing.

Imagine building:

• DEXs where trading bots operate at sub-second speeds, tightening spreads and improving efficiency

• Gaming engines where onchain updates feel instant, enabling real-time multiplayer

• Payment systems that confirm faster than credit card networks, without sacrificing security

• DeFi apps that don’t break when transactions cross multiple shards

The execution model requires some adaptation. Contracts can’t assume instant state visibility after consensus. But the performance ceiling just jumped into territory previously held only by centralized systems.

For Users: The Invisible Blockchain

Speed becomes invisible when it’s fast enough. Users shouldn’t think about block times any more than they think about internet lag.

Supernova makes blockchain fade into the background. Transactions that confirm before you can second-guess clicking “submit.” DeFi swaps that execute before prices can move. NFT mints that feel like button clicks, not pending transactions.

The experience becomes the app, not the chain beneath it.

For Validators: New Performance Standards

Supernova’s efficiency comes with infrastructure requirements. The parallel execution model needs multi-core processors (8+ cores recommended, 12-16 cores optimal). Memory needs scale with increased throughput (32GB minimum, 64-128GB for production).

But the reward model evolves too. Staking V5, launching with the new economic model, introduces dynamic validator rewards tied to network activity and uptime. High-performance nodes earn more. The protocol’s reputation system ensures quality.

The validator landscape shifts from passive staking to active performance optimization.

The Competition: Where MultiversX Stands

Current blockchain performance (transaction finality):

• Bitcoin: ~60 minutes (6 confirmations)

• Ethereum: ~12.8 seconds

• Avalanche: ~2 seconds

• Solana: 400-800ms

• Sui: 400-800ms

• Aptos: ~4 seconds

• MultiversX Supernova: <300ms (88ms achieved in testing)

But comparing finality times misses the deeper technical differences:

Solana achieves speed by optimizing a single high-performance chain. Brilliant engineering. Also a single global state, single sequencer, and hardware requirements that push decentralization limits.

Sui and Aptos use object-based and parallel execution models. Elegant solutions that work within their design constraints. Still fundamentally different from MultiversX’s sharded architecture.

MultiversX Supernova combines parallel execution with adaptive state sharding and the Propose/Vote-then-Execute consensus model. The architecture delivers sub-second finality while maintaining linear horizontal scaling through sharding.

Add more shards. Get more throughput. No theoretical ceiling where coordination overhead beats parallelization gains.

This isn’t a race to “fastest blockchain.” It’s a race to build infrastructure capable of supporting global-scale apps without forcing developers to choose between decentralization, security, and performance.

The Timeline: From Battle to Launch

• November 2025: Battle of Nodes registration opened (You can still register here!)

• January or February 2025: Battle of Nodes stress testing begins

• Q1 2026: Battle results and final adjustments. Supernova mainnet launch.

The dates are flexible because they should be. Rushing a network upgrade this massive would be reckless. The Battle of Nodes will determine readiness.

When Supernova launches, it needs to launch perfectly. One shot at getting it right.

The Bigger Picture: Why This Matters Beyond MultiversX

Blockchain infrastructure has been stuck for years. Small improvements to consensus. Minor tweaks to execution. The industry convinced itself that the “impossible trilemma” was fundamental that you could have decentralization and security, or decentralization and speed, or security and speed, but never all three.

Supernova proves that the trilemma was a limit of design, not physics.

By separating execution from consensus and using adaptive state sharding, MultiversX created proof: sub-second finality and horizontal scaling work with full decentralization and Byzantine fault tolerance.

This matters because infrastructure determines everything. If blockchains stay slow, expensive, and complex, they’ll remain niche tools for speculation and narrow uses. If blockchains become fast, cheap, and invisible, they can become the foundation for the next generation of internet applications.

The transition from Elrond to MultiversX was about expanding the vision from “fast blockchain” to “internet-scale infrastructure.” Supernova is where that vision actualizes.

What Happens Next?

The community will stress-test Supernova during Battle of Nodes. Validators will find edge cases. Builders will discover migration challenges. Infrastructure providers will identify bottlenecks.

And the engineering team will fix them.

Because the goal isn’t shipping an upgrade on schedule. The goal is building infrastructure strong enough to support the next wave of blockchain adoption without breaking.

When Supernova reaches mainnet, it won’t just be another protocol upgrade. It will be a statement: the blockchain trilemma is solved. Sub-second finality at internet scale is here. The infrastructure that makes Web3 feel like Web2—but with the security and composability only blockchains provide—is live.

What gets built on that infrastructure will determine whether blockchain technology fulfills its promise or remains an expensive experiment.

The technology is ready.

The ecosystem is preparing.

The Battle of Nodes will prove whether it’s time.

And then, Supernova.

Technical Specs Summary

• Block Time: 6s > 600ms (10× reduction, launch target)

• Finality: <300ms production target (88ms achieved in testing)

• Consensus Model: Propose/Vote-then-Execute (separate execution)

• Validator Count: 400 per shard (full consensus group)

• Execution Model: Parallel, multi-threaded, separate from consensus

• Sharding: Adaptive across network, transactions, and state

• Bandwidth Reduction: Consensus messages no longer include execution results

• Smart Contract Timing: Millisecond-level timestamps

• Previous Upgrades: Andromeda (v1.9.6), Barnard (v1.10.4)

• Battle Test: Started in December 2025, $150,000 prize pool (expanded with partner support for the hackathon)

• Expected Mainnet: Q1 2026 (based on validation)

For the Builders

If you’re reading this and thinking about what becomes possible when blockchain finality drops below human perception, you’re on the right track.

The infrastructure layer is about to become invisible. Which means the applications can finally become everything.

The race isn’t to build on the fastest chain.

The race is to build the apps that couldn’t exist before the chain got this fast.

Supernova is coming. What are you going to build on it?

Building on MultiversX has always been a little different.

Not just because of the tech, but because of the people. Builders helping builders. Context passed along in conversations, not just docs. Momentum created by showing up and shipping.

With increasingly capable AI “coworkers” making it easier than ever to ship applications in record time — and with Supernova about to begin a new chapter for the network and bringing new eyes to the ecosystem — one question becomes more pertinent than ever:

Where do I start?

Today, we’re adding a better answer to that question: the MvX Welcome Kit.

MultiversX, for Builders

The Welcome Kit is a new starting point for builders who want to explore, build, and connect inside the MultiversX ecosystem.

It brings together:

• Technical tools and infrastructure to help you ship faster

• Human expertise to help newcomers get started and experienced builders accelerate

• Ecosystem partners ready to collaborate and grow alongside other projects

A new foothold for builders — and a hand up for anyone willing to put in the work.

A Serious Toolkit

At xAlliance, our mission has always been straightforward: help builders build better.

Sometimes that means grants. Sometimes mentorship. Sometimes introductions, feedback, or simply being available when someone’s stuck. Over time, that support has taken many forms — often informal, often invisible.

The Welcome Kit makes one part of that work explicit. It’s support, up front. A signal that if you’re serious about building on MultiversX, you don’t have to figure everything out on your own.

Why now

Supernova is a complete overhaul of the MultiversX (formerly Elrond) infrastructure — a network that meaningfully raises the bar for speed, scalability, and performance. That still matters, especially to builders deciding where to invest their time and energy.

But technology alone doesn’t onboard builders. Experiences do.

The Welcome Kit exists to make that first experience smoother, clearer, and more human, at a moment when many people are taking a fresh look at MultiversX.

Who this is for

The MVX Welcome Kit is for new builders — but it’s also for the community that’s already here.

If you meet someone who’s curious about building on MultiversX, you now have something solid to point them to. Not a list of links. Not a disclaimer. A place to connect and get started, right away.

And for deeper technical resources, the Welcome Kit naturally connects to xDevHub, which brings together MultiversX’s core developer tools and documentation.

Like all of our initiatives, the Welcome Kit will evolve with the ecosystem — and with feedback from the builders who use it.

No time like the present

The tools are getting sharper. For beginners and seasoned developers alike, creating new applications and use cases has never been easier. With Supernova, we’re about to enter a new era of speed and performance, unlocking entirely new categories of applications — from DeFi to AI and beyond.

The MvX Welcome Kit is a small piece of that momentum. Something useful, made with care, for builders who want to get started.

It’s always time to build.

The Supernova walkthrough focused on substance: what is changing in the MultiversX protocol, how it works, and what it means for builders, validators, and operators.

At its core, Supernova introduces a structural change to block production by separating consensus from execution. This recap summarizes that change and the reasoning behind it.

From Andromeda to Supernova

Supernova builds directly on the Andromeda upgrade.

Andromeda redesigned consensus and finality, removed confirmation blocks, and made finality both faster and deterministic. As explained during the walkthrough:

“As soon as you have a proof that a block has passed consensus, that block is already final. It cannot be reverted.”

After Andromeda, one major limiter remained: execution.

Transactions still had to be executed before blocks could pass consensus. In practice, execution dominated block time:

“Execution time, depending on how many transactions there were in a block, could take up to 4.5 seconds out of the block slot.”

Consensus was already fast. Execution was not.

The Architectural Change

Supernova removes execution from the consensus critical path.

Previously, block production required a proposer to execute transactions before proposing a block, and validators to re-execute them before voting. Supernova changes that flow.

“We completely decoupled execution from consensus, and now consensus runs on a proposed set of transactions.”

Blocks are proposed and voted on first. Execution happens asynchronously in parallel, and execution results are notarized in later block headers.

As it was summarized in the session:

“Everyone agrees on the set of transactions. And in parallel with agreeing on them, everyone also does the execution.”

What Block Production Looks Like Now

Before Supernova:

• transactions were selected, executed, and proposed as a single synchronous step

• validators re-executed transactions before voting

With Supernova:

• transactions are proposed without prior execution

• validators verify proposal rules and vote immediately

• execution runs in the background

• results are referenced and finalized in subsequent headers

Consensus no longer waits for execution to finish.

Why Execution Had to Move

Measurements shared during the walkthrough showed that consensus already completes very quickly on mainnet:

“More than 99.98% of blocks reach consensus in under 250 milliseconds.”

Execution was the remaining blocker to shorter rounds.

By removing execution from the critical path, Supernova enables much shorter block slots. The initial target is 600ms, with internal testing showing consensus completing well within that window.

Making Asynchronous Execution Safe

Decoupling execution introduces a clear challenge: avoiding the proposal of transactions that won’t execute later.

Supernova addresses this by redesigning the transaction pool.

The mempool now maintains a virtual state that tracks pending nonces, expected balance usage, and transactions already proposed but not yet executed.

“The transaction pool maintains state for accounts that had transactions proposed but not yet executed, so we don’t select transactions that cannot be executed.”

This virtual state is updated as blocks are proposed and as execution results are finalized, keeping transaction selection aligned with actual network state.

Keeping Validator Requirements Stable

Faster rounds should not exclude validators with minimum-spec hardware.

To prevent that, Supernova introduces the Execution-Result Inclusion Estimator (EIE).

“We need to make sure that whoever respects the minimum hardware requirements is able to participate in consensus, produce blocks, and earn rewards.”

EIE deterministically limits how many execution results can be referenced in a block based on what a minimum-spec node can safely process. If execution starts lagging, block capacity is reduced automatically.

Validator economics remain unchanged:

“From the point of view of economics, nothing has changed. The same rewards are generated and distributed as before.”

Automatic Backpressure

Supernova also includes built-in backpressure.

If execution falls behind proposals, the protocol dynamically reduces block capacity until execution catches up. This prevents unbounded execution backlog and requires no manual intervention.

Transition and Testing

Before activating the new execution model, the protocol performs a cleanup phase:

“We finalize all pending partial execution and scheduled execution before switching to the 600ms round time.”

Supernova is then validated through Battle of Nodes, which runs on a shadow fork of mainnet state:

“We want to stress-test Supernova using real participants and real workloads. Synthetic benchmarks are not enough for an upgrade of this size.”

The goal is to surface edge cases under realistic conditions before full activation.

What This Enables

For builders, Supernova changes the constraints they design within.

Shorter rounds and predictable finality make it easier to build applications that react quickly to on-chain state: real-time games, trading systems, responsive DeFi components, and complex cross-shard flows.

For users, interactions resolve almost immediately.

For autonomous agents, fast and deterministic finality is essential. Agents that react to events, coordinate across contracts, or operate continuously depend on clear guarantees around when state becomes irreversible.

Supernova provides those guarantees while keeping validator participation broad.

A Shift in the Baseline

Supernova does not add a feature on top of the existing protocol. It changes how the protocol itself moves forward.

Once consensus and execution are no longer tied together, the baseline assumptions around speed, responsiveness, and system design shift accordingly.

That shift is what Supernova brings to the MultiversX ecosystem.

The end-of-year town hall brought the MultiversX community together for a reflective close to 2025. The session was intentionally structured as a journey through the year: starting with the community, moving through technology and real-world deployments, and closing with a forward-looking view into 2026.

A summary of the most important points and takeaways from each segment of the town hall.

Community Updates:
Builders Shipping in the Real World

The town hall opened where it deliberately should: with long-standing community builders who have continued to execute through changing market conditions.

Several ecosystem projects were highlighted to illustrate how MultiversX is being used beyond experimentation:

• Transparency and philanthropy infrastructure
  Philanthrify, a donation and impact-tracking platform co-founded by Tomos Rees demonstrated how blockchain is being applied to real governance problems. Donations can be traced end-to-end, with charities and donors seeing how funds are allocated and spent. Importantly, the product abstracts blockchain complexity for users while anchoring verification fully onchain.

• Payments and compliance at live events
  VeroPay co-founder Ovidiu Popica showcased an active deployment at a physical market, enabling cashless payments and blockchain-anchored fiscal receipts. The implementation emphasized regulatory alignment and usability: vendors and buyers do not need to understand blockchain mechanics for the system to work.

Across these examples, a clear pattern emerged:
MultiversX projects are increasingly designed for non-crypto-native users, with blockchain functioning as infrastructure rather than the user interface.

Tech & Protocol Updates:
Blockchain as Invisible Infrastructure

Following the community segment, the town hall shifted into a more technical perspective, focusing less on individual features and more on how the protocol is evolving in practice.

Key themes included:

• Abstraction over exposure
  Wallet creation, smart contracts, NFTs, and onchain records are increasingly handled behind the scenes. The goal is to allow users to benefit from blockchain guarantees without being forced to interact with raw blockchain concepts.

• Scalability through automation
  Smart contracts and onchain data structures are being used to automate processes that would otherwise require manual coordination, enabling products to scale without proportional increases in complexity.

• Real-world alignment
  Technical decisions are being informed by regulatory realities, compliance needs, and enterprise-grade expectations—particularly for payments, accounting, and public-facing services.

Rather than positioning protocol updates as isolated innovations, the town hall framed them as enabling layers for ecosystem teams to build products that work reliably outside of crypto-native environments.

Big Picture: What Defined 2025

Looking back, 2025 was characterized less by headline moments and more by consolidation and learning.

Key patterns from the year:

• A shift from experimentation to execution and deployment

• A focus on creating working products with revenue

• Increased focus on usability and real-world applications

• Stronger alignment between infrastructure capabilities and builder needs

The ecosystem spent the year proving what works, identifying friction points, and refining how MultiversX is positioned as a foundation for serious builders.

Looking Ahead: Direction for 2026

While detailed roadmaps were intentionally avoided, the closing segment outlined clear strategic priorities for 2026:

• Scale what already works rather than multiplying experimental initiatives

• Deepen integrations between ecosystem projects and real-world systems

• Raise the bar for impact, execution, and delivery

• Continue supporting builders who innovate and execute

The overarching direction is focus. Fewer distractions, clearer priorities, and stronger standards for what qualifies as meaningful ecosystem progress.

Closing Note

This town hall reinforced a simple but important message:
MultiversX is entering a phase where credibility is built through delivery. Supernova will be real inflection point, delivering the internet-scale blockchain. On it, anything can be built, for human users and AI agents alike.

For xAlliance, the takeaway is equally clear. The strongest contributors in the ecosystem are those building practical, user-first products on solid infrastructure—and 2026 is about giving those efforts room to compound.

What started as a simple curiosity, a junior dev wanting to dip his toes into a new tech stack snowballed into a full-on obsession with building on MultiversX (MvX). I didn’t come from a Blockchain background. I’ve never written a line of smart contract in my life. I came into this fresh, looking to cure my boredom by building something real.

But why did I choose the hard path?

The “Rust” Decision

You might ask: “Why pick a language notorious for being difficult?”

Here is the technical reality: MultiversX smart contracts run on the SpaceVM, which executes WebAssembly (WASM). This is cool because, theoretically, you can write contracts in any language that compiles to WASM.

But let’s be honest, Rust is the first-class citizen here. It is the standard for a reason. Its strict memory safety and performance make it the perfect tool for writing bulletproof financial code.

So, despite the steep learning curve, I decided to go all in. I grabbed the docs, installed rustup, and prepared for battle.

Phase 1: The Rust Bootcamp

Jumping into Rust felt like trying to learn a new language while someone constantly corrects your grammar. It’s strict. It’s unforgiving.

The first few days were a blur of “Hello EnRich” and false confidence. I thought, “Okay, variables, loops, I got this.”

Then I hit the Structs and Vectors wall. I realized quickly that you can’t just throw data around loosely. I had to learn how to structure data types specifically for contract state, wrestling with Vec<T> (dynamic arrays) to manage lists efficiently.

And don’t get me started on Ownership. In Rust, every value has an “owner.” If you try to use a value after its owner has dropped it, the compiler screams at you. I spent time fighting the “Borrow Checker,” trying to understand why I couldn’t just mutate a variable I was only looking at.

But then came Traits (interfaces) and Error Handling. I learned that using panic! is a bad idea because it burns gas; you need graceful Result flows instead.

By the end of the first few days, I wasn’t just typing code anymore; I was finally thinking in Rust.

Phase 2: Building on MultiversX (The Real Fun Begins)

Once I survived the Rust bootcamp, I finally shifted to “Builder Mode”. This was the moment I moved from generic coding to actual blockchain development.

My first mission? Assets.

This was my biggest “Aha!” moment on MultiversX. On other chains, if you want a token, you usually have to write a smart contract (like ERC-20). On MultiversX, tokens are native. They are built into the protocol itself.

I wrote a script to issue an NFT collection (unique assets) and an SFT collection (stackable items, like game potions).

Of course, it wasn’t a straight line. I spent hours stuck on a bug where my transaction said “Success,” in my terminal, but the explorer said “Fail”. The error? Token name length. I was trying to be clever with a name that broke the protocol rules (too short/long).

It was a humbling reminder: The blockchain verifies everything. But once I fixed the parameters, seeing that “SFT” tag on the Devnet Explorer was worth every second of debugging.

Phase 3: The Escrow & The Bridge

With assets mastered, I moved to the boss level: The Escrow Contract.

I wanted to build a trustless middleman. A contract that locks assets from a seller and only releases them when the buyer sends the correct payment.

I mapped out the logic: create_offer, accept_offer, cancel_offer. The logic was clean, but I didn’t want to just leave it in VS Code.

Going Off-Script The tutorials I was following covered the logic, but I got a little impatient. I wanted to see this thing live. So, I went off-script.

I set up a dedicated Devnet wallet and hit the faucet. You can write the best code in the world, but without gas (xEGLD), it’s not moving anywhere.

I deployed the contract to Devnet. It’s live right now.

But I’m not stopping at “On-Chain.” A smart contract is useless if no one can talk to it. So, I’m currently building the Bridge.

I’m using NestJS to build a Microservice API that wraps my smart contract. Instead of raw blockchain calls, I’m building clean API endpoints using Swagger that a future frontend can easily talk to.

The Arsenal: What I Can Do Now

A month ago, I was just installing Rust. Today, the difference is night and day. Here is what I can actually ship:

• Read & Write Rust: I can navigate source code and build custom types without panicking.

• Deploy Smart Contracts: I can compile WASM files and push them to Devnet using the CLI.

• Issue Assets: I can create Fungible Tokens, NFTs, and SFTs programmatically.

• Build Trustless Logic: I can engineer financial primitives (like Escrows) that replace middlemen.

The Real Lessons

If you’re sitting on the sidelines thinking about learning to build on MultiversX, here is my takeaway after 30 days:

• Community is the cheat code: Whether it is the xAlliance or just random devs on X, having people to cheer you on when you’re stuck is vital.

• Build in Public: Sharing my failures taught me more than sharing my wins.

• Rust is worth the pain: It’s hard at first, but it forces you to write safe code.

What’s Next? The “Brain” (Contract) is built. The “Bridge” (API) is under construction. Next, I’m building the frontend so actual humans can use this thing.

I started last month knowing nothing about MultiversX development. Now, I’m deploying financial primitives. If I can do it, you definitely can too.

Let’s keep building.

Follow the chaos on X: @MeetEnRich

MultiversX is on track to deliver the most consequential milestone since its original Elrond Genesis: Supernova.

This is a complete re-imagining of MultiversX designed to push the limits of speed, scalability, and decentralization, and to establish it as a fiber network for global finance.

The big question is this: how do we make this defining milestone an ignition moment for the entire EGLD ecosystem?

To transform this technical leap into a true Genesis moment, we’re proposing a new economic model, grounded in competitive market dynamics, linked to quantifiable performance indicators, institutionally-aligned, and engineered so that every unit of EGLD carries an intrinsic force of generative momentum.

The New Economics Model is Built For Growth

What does growth mean? It means we are on a deliberate quest to target a 10x expansion in network liquidity, a 10x surge in network revenue, and a 10x increase in token demand over the coming cycle. More liquidity means more economic value anchored within the EGLD ecosystem, and less float in circulation.

More network usage means greater EGLD velocity within the system, and less capital leaving it. More demand means stronger capital inflow and buy pressure, supply inelasticity, and accelerating market momentum.

Growth, in this model, is not abstract. It is mechanical, measurable, and compounding.

Strong Staking Incentives, Attracting New Liquidity

We want to attract more liquidity to the network. But what does liquidity want? Liquidity seeks one thing above all: the prospect of growth. It moves where opportunity compounds, where short and medium-term incentives are competitive, and where the long-term vision signals significant expansion.

To reignite positive momentum, we have defined a new, competitive incentive structure:
(a) 9.2% APR for simple staking, and
(b) 7.3% average APR for pro staking

Together, these buckets form a combined reward of roughly 16.5% per annum.

This is a precise and deliberate signal for new liquidity to enter, to stay, and multiply. A first foundational pillar pairing competitive incentives, with a quest to attract 10x liquidity.

But why does liquidity matter? New liquidity means new buy demand. Furthermore, new liquidity takes float supply out of circulation, and locks it in as productive capital.

The snowball is in motion. For new liquidity, this is the time to deploy.

Competitive Builder Incentives, Jump-starting the Revenue Machine

We want more network revenue. But how do we engineer toward that?

Well, revenue comes through usage. Usage comes through users. The more applications are built on top of the network, the more potential for users, the more potential for usage.

Thus, we can significantly increase the revenue, by dramatically growing the number of users, and expanding their usage behavior.

But how do we do that?

Two incentives engineered to accelerate builder cycles:
(a) 90% of transactions fees go to builders directly
(b) 20% of new emission jump-starts new revenue engines via builder credits

Together, these two steps set a robust incentive package , on a quest to 10x network revenue.

But why does revenue matter?

More network usage means greater EGLD velocity within the system. It means more capital productivity, and less capital leaving it. It means less supply float, tighter inelasticity, and stronger buy side impact.

With the second foundational pillar in place, the snowball is gaining momentum.

New Market Connectivity Accelerating Buy Demand and Supply-Locking Catalysts

We want more demand. But why?

Because demand is the engine of momentum. It drives buying pressure, reduces free-floating supply, expands market velocity, and builds a larger economy, filled with productive capital.

We aim to unlock this through three concrete, measurable, and compounding mechanisms:

DAT
The primary bridge to deep stock-market liquidity and recurring demand. Executed correctly, it can establish a sustained buyback mechanism financed by capital markets, effectively locking 20–30% of the total token float out of circulation.

ETF
The key institutional bridge designed to serve an untapped market and add another powerful demand vector, continuously absorbing EGLD supply from the open market.

U.S. Labs
The dedicated business and marketing acceleration arm, representing MultiversX in strategic U.S. discussions, bootstrapping a new attention-to-adoption program, and securing the three most consequential ecosystem deals necessary for growth.

Together, these components serve a clear objective: to 10x demand, activate self-reinforcing buyback mechanisms, and accelerate market momentum.

This is the third foundational pillar, amplifying motion, bringing the snowball to a tipping point, ready to transform into an avalanche.

Exploring In Vitro Scenarios for Growth

How does a possible scenario for success look like?

Above, we present an initial in vitro scenario simulation for how growth could look like during the next 30 years, given conservative and accelerated assumptions for liquidity, revenue, and demand.

The Future We Deserve, the Future We Build

We are entering perhaps the most decisive phase since the network’s Genesis. This is about arming MultiversX with the tools to lead and win.

Best-in-class technology. Competitive economics. Institutional capital. New engines to drive liquidity, revenue, and demand.

A chance to root ourselves into the U.S. financial system, with ETFs, DATs, Wall Street, Washington. Secure liquidity, and a new shot at material growth.

The choice lies wholly with the community. History moves fast. The window for action is open now.

With your vote, we can arm EGLD for real growth, today.

I want to express my heartfelt appreciation for all your continued support and participation. This is the moment we make action count. And shape the future of MultiversX, together.

The original post was first published via Twitter on October 22, 2025.

The new economic model for MultiversX switches to a new model for funding activity on the network. You can think of it like the network’s growth budget. The money is spent to keep MultiversX secure, grow the ecosystem, and fund new ideas.

Instead of letting this “new money” go to waste, the system divides it carefully into four smart buckets, each with a clear job.

1. Simple Staking: The Security Team (50%)

Half of the budget goes to people who stake their EGLD — those who lock it up to keep the network safe and running. These rewards attract more stakers and validators, making the network stronger and harder to attack.

It’s like paying the guards who protect the city walls.

2. Growth Dividend: The User Rewards (20%)

This part rewards everyday users who actually use the network — not just those who stake.
If you provide liquidity, join DeFi strategies, or use dApps, you can earn extra rewards.

Here’s the idea:

• Just staking = regular rewards.

• Staking + helping the network grow = bonus rewards (the “boost”).

It’s like earning points not just for having a bank account, but for spending, saving, and helping the local economy thrive.

To keep it fair, these rewards depend on real growth. If the network isn’t growing (meaning there are fewer users and less liquidity) the system automatically locks the unused tokens, keeping EGLD supply tight.

3. Ecosystem Growth Fund: The Builder Boost (20%)

This fund fuels developers and creators: the people building apps, tools, and games on MultiversX.

But it’s not a giveaway. Builders only receive tokens after proving their apps bring real users, transactions, or revenue. If they don’t deliver, the tokens stay locked.

It’s like a startup grant system that only pays out when progress is real and measurable.

4. Protocol Sustainability: The Innovation Engine (10%)

This last part keeps the core network alive and improving to pay for engineers, research, upgrades, infrastructure. Think of it as funding the city’s power grid, roads, and research labs.

It ensures MultiversX can keep evolving without needing outside help.

How It All Works Together

Every new EGLD is put to work. Each bucket feeds into the others, creating a balanced loop:

Stakers secure the network → Builders create apps → Users bring activity → More transactions → More rewards → More growth.

This is how emissions become a growth engine, not a cost. The system reinvests in itself, turning new EGLD into security, innovation, and user growth—with burn and lock mechanisms keeping the supply under control.

In One Line

Every new EGLD has a job: protect the network, reward users, fund builders, and keep MultiversX innovating.

That’s how the network turns emissions into growth.

Every time you use an app on MultiversX—to send a transaction, buy an NFT, or make a swap—you pay a small network fee.

But unlike other blockchains, MultiversX turns that fee into a powerful incentive system that helps everyone: builders, validators, and users.

The Two Parts of a Transaction Fee

1. Base Fee → goes mostly to builders
   This is the standard fee that every transaction pays. It’s about $0.002 on average.

   • Almost all of this (90%) will go to the developer who built the app or smart contract you’re using.

   • 10% of it is burned—permanently destroyed—which ties network usage to EGLD scarcity.

   • Over time, that split will move toward 50/50: half to builders, half burned which slowly puts more deflationary pressure on EGLD.

2. Priority Fee → goes to validators
   This is an optional “tip” if you want your transaction processed faster. Validators—the ones keep the network running—earn 100% of this tip. On the user end, this will increase the transaction cost to around $0.01.

Why This Model?

This system aligns everyone’s incentives:

• Builders earn directly from app usage, not just from tokens or hype. The more people use their app, the more they earn. This creates additional incentives to make great products, better design, and smoother UX.

• Users get better apps and potentially gas-free transactions, because builders can use their fee income to sponsor fees for them. And since part of every base fee is burned, every transaction adds a bit of deflationary pressure on EGLD.

• Validators earn more when activity increases, especially from priority fees, so they’re motivated to keep the network fast and secure.

The Growth Loop

This model creates a simple but powerful flywheel:

More incentives for builders → better apps → more users → more transactions → more rewards for builders & validators → more building.

At the same time, every bit of network activity burns EGLD, tightening supply and linking usage to value.

At A Glance

The new MultiversX fee markets turn activity into alignment.

Every app, every transaction, and every new user fuels the same cycle:

More usage → more rewards → more building → more value for EGLD.

Dear Diary,

It was 10 a.m.

I was still debating whether to make breakfast or just pretend I wasn’t hungry when my phone buzzed. It was Elijah.

“Irene, let’s go to Federal University of Technology, Minna,” he said, his voice carried a familiar spark that could only mean something big was about to happen.

He graduated from the University four years ago, and before I could even ask why, he was already talking about how “MultiversX Ideathon in Minna would be impactful.”

According to him, Federal University of Technology Minna (FUTMinna) is a hub for young developers who could code their way out of any problem. I laughed, half-skeptical, half-curious. “Let’s see how fast your tech school gives us approval.”

The next morning, I found myself in the passenger seat of a car heading to Minna, with Elijah as my self-appointed tour guide.

Long roads, Music, and Hype

The road to Minna was full of potholes. Some were big enough to make me sit up straight, clutch my seat, and silently pray. Meanwhile, Elijah who was clearly familiar with the drill, was laughing and acting like it was just a Sunday drive.

And if you’ve ever been on a road trip in Nigeria, you'd know using a headphone on those trips isn’t something to debate on. You would most likely be forced to endure long stretches of silence and long dusty roads, proving your headset is a necessity.

However, ours was pure chaos disguised as music. Elijah had hijacked the aux cord like a DJ on a mission: one minute it was Nasty C, the next Michael Jackson, then Davido for “energy balance.” Between the blaring speakers, the bumpy roads, and Elijah’s commentary on why Minna was the North’s “hidden Silicon Valley,” the silence couldn't stand a chance.

The road stretched endlessly. The sun refused to give us a break, but somehow, Elijah's excitement made the four hour trip a almost bearable.

The Subtle Art of Surviving Bureaucracy

By the time we reached Minna, the sun had already settled into its full-time job. It was blazing hot like it had a personal grudge against first-time visitors.

We walked into the campus with the enthusiasm of explorers, only to be reminded that in Nigeria, even enthusiasm needs a written approval. We couldn’t just waltz in to host an event—Nigerian universities have protocols. The kind that starts with “write a letter to the..” and ends with, “wait for an approval.”

And that may last forever.

Thankfully, Elijah’s old connections came through. His former professor welcomed us warmly, listened to our pitch, then he referred us to the Dean of Engineering.

The Dean listened patiently while Elijah did most of the talking. He was confident, composed, and sounded like someone who’d done this a hundred times.

Then came the moment that changed everything.

“Sir, we’ve prepared a letter to submit to the registrar for approval,” Elijah said confidently.

The Dean looked up, adjusted his glasses, and gave us that academic look like we were joking.

“The Registrar?” he repeated slowly, raising his eyebrows like we had committed a crime.

Honestly, it wasn’t Elijah’s fault. The event at Keffi had gone so smoothly (one updated letter, instant approval, and a great event) that we'd gotten a little too comfortable, thinking Elijah’s influence and previous experience as a sport director would be enough to get us a quick approval and a mind-blowing event.

But Minna seemed to have other plans.

The Dean cleared his throat and launched into what could only be described as a full lecture on University procedures and organogram.

Dean → Registrar → Vice Chancellor.

Meanwhile, I quietly pulled out my journal, taking notes like a student in Bureaucracy 101. Perhaps it would have felt rude not to write—especially now that Elijah’s confidence had already packed its bags and was halfway out the door.

We left the office acting like we hadn’t just been schooled. Elijah kept a straight face, but the silence was loud.

“Things have really changed o,” he said finally, adjusting his tote bag like someone carrying the weight of the university system.

I laughed. “Or maybe we just got too confident.”

We drafted the letter the same day, printed and submitted it to the office of the Vice Chancellor.

Student Rep, Venue and Partnership

If there’s one thing I learned from campus tours, it’s that you need students who genuinely believe in what you’re doing.

For us, that person was Omeiza Abraham, one of Elijah’s friends. He helped us scout possible venues and that's how we found Window on America, Minna. It was a bright space that had a calm atmosphere, a mix of books, portrait of great African leaders and an aura that welcomed anyone to learning and growth.

We met with the Assistant Director who was genuinely happy to educate us on the American Spaces objectives. After a short chat, he promised to speak with the Director about our proposal. It sounded like one of those polite “we’ll get back to you” lines, so we didn’t expect much.

A few days later, Elijah’s phone rang. It was from the assistant director. The director had heard about the MultiversX Ideathon and was enthusiastic about partnering with us.

And just like that, xAlliance partnered with American Spaces Nigeria—a learning environment for future builders.

With that sorted, it was time to move on to the next phase: planning, publicity, and everything else that makes you question why you ever thought event coordination was easy.

Between Bright Faces and Bigger Ideas

The day of the Ideathon came faster than expected.

Or maybe I never really slept. My brain had been running through checklists all night: banners, snacks, mics, slides etc.

We got to Window on America around 8 a.m. The hall looked beautiful. xAlliance banner was up, projector on, snacks and drinks on standby. Everything had to go right.

Then the doors opened.

At first, a trickle of curious students. Then more came in, filling the seats, chatting softly, phones out, eyes bright with curiosity. You could feel the blend of uncertainty and excitement that usually comes before exciting activities.

Lukas Seel kicked things off, setting a welcoming tone that instantly melted the tension. Then it was my turn to share a bit about my journey and how the MultiversX ecosystem is a home for dreamers who dare to build.

Our guest speakers, Micha and Flaka followed. They introduced the students to tools like VibeOX and JoAI, showing how anyone could automate ideas and build smarter apps.

You could see their faces lightening up at the possibility of building apps and games on-chain faster without the hurdle of coding.

Then came the real challenge: The Ideathon.

Ideas Took the Stage

We divided the students into groups and gave them one task: use blockchain to solve local problems. In less than twenty minutes, the hall turned into chaos—but the good kind. Brilliant minds were racing, some huddled by the window, deep in group discussion. Others took over corners with papers flying everywhere. You could hear snippets of conversation:

“Let’s build a digital library on blockchain.”

“No, no—let’s track food supply chain.”

“Wait, what if we build a farm monitoring app for local farmers?”

The energy was contagious. A few standout ideas still lingers in my mind:

• SmartClean Technology: an AI-integrated, blockchain-powered robotic cleaner.

• MobiNet: a way of tracing the distribution of portable mosquito net with built-in lights, fans, and charging ports onchain to ensure effectively combating malaria.

• Campus Quest: a gamified platform rewarding students for participation during events.

• Farm-to-Fork Ledger: tracking food from farms to tables with on-chain transparency.

• Flok: a decentralized social app to reward creators for their efforts.

The judges listened, smiled, and occasionally threw questions sharp enough to test their knowledge on the ideas they pitched. But most of the students held their ground. You could see confidence blooming in real time. Voices grew stronger, eyes brighter and ideas louder.

After it was all done, laughter filled the room. Everyone wanted to take pictures, exchange numbers and celebrate the winners.

As we packed up, Elijah looked at the hall and said, “We did good.”

This time, I didn’t tease him. I just nodded, because he was right.

We really did good.

The drive back wasn’t loud or cheerful like before. It was the kind of silence that inspired me to reflect on the time Elijah called me that Wednesday morning. I also thought about the Dean’s lecture on protocols, the student's laughter in the hall and the spark in their eyes.

It reminded me that every journey to a north star may come with its share of potholes.

And when people say “Web3 is about technology,” I tell them the MvX Ideathon in Minna isn't about tech, it is about people who are curious and determined to use the tech to build.

I do hope to find you in the next city.

Onward and forward,

Irene.

MultiversX’s new economic model introduces an intricate and novel mechanism introduced as “Tail Inflation + Burn Mechanism.” At the heart of it: the Growth (or simply G) factor.

Let’s break down what the G Factor is.

Think of the MultiversX network like a living economy. To keep it healthy, it needs the right amount of “fuel”: new EGLD that enters the system as emissions.

The G Factor (short for growth) is a “smart dial” that turns this fuel up or down based on how well the ecosystem is doing.

When Growth Is High

• Lots of people are using apps, staking EGLD, trading, and building new things.

• The network burns more fees and earns more revenue.

• The G Factor says: “We’re growing fast, let’s keep the rewards coming!”

• Emissions stay higher for longer (around 5–7%) to encourage builders, validators, and DeFi applications to keep expanding.

What it means for EGLD: Even though a bit more EGLD enters the system, there’s more demand for it: people need EGLD to stake, participate in DeFi, use apps, and pay fees. That usually supports price growth because real activity drives real value and more EGLD is burned.

When Growth Is Moderate

• Apps are active, staking is solid, but not booming.

• The G Factor keeps things balanced.

• Emissions slowly decay toward about 4–5%, still enough to fund security and incentives but not too much to risk oversupply.

What it means for EGLD: This is the “steady and sustainable” mode: the network remains competitive, validators earn well, and inflation doesn’t eat into long-term holders.

When Growth Is Low

• Fewer new apps, less volume, slower burn rate.

• The G Factor reacts: “We need to tighten up.”

• Emissions decay faster, down toward 2–3%, while more fees get burned (up to 50%).

• The supply of EGLD shrinks, making it scarcer.

What it means for EGLD: Lower emissions and higher burns protect the token’s value. Even if activity slows, EGLD becomes harder to mint and easier to burn—a natural brake that helps price stability.

Smart Supply Control

Most blockchains have a fixed inflation—they print coins at the same rate no matter what’s happening. MultiversX doesn’t. The G Factor makes inflation responsive to real performance.

When the network grows, rewards keep the fire burning. When growth slows, scarcity increases to protect holders.

It’s like an automatic economic thermostat that is always adjusting to keep the MultiversX economy competitive, sustainable, and healthy.

What changed vs. the first draft

• Tail emissions revised down: initial 9.47% → max 8.757%, with an effective start ~4.38% because half of emissions are KPI-gated and don’t hit circulating supply unless unlocked.

• Emissions are adaptive to onchain performance (drop in slow periods; rise when growth warrants builder funding). Annual check-ins plus quarterly adjustments are planned.

• Clear, time-boxed governance process and voting window were added (see “Timeline & process”).

Emissions, staking APR, and DeFi “boost”

• 50% of emissions → staking; 50% → Accelerator (KPI-gated). Base staking APR expected to start ~9.2% and stay relatively stable.

• Within the Accelerator half, 20% of total emissions is reserved for a DeFi stimulus users can opt into for additional yield above base staking.

Fees, burns, and buybacks

• Base transaction fee split starts 90% to smart-contract owners / 10% burn, shifting 5% toward burn each year to land at 50/50 after 8 years. Goal: reward builders now, increase burn over time.

• Apps receiving 90% can subsidize user fees (users pay ~10%), stimulating on-chain activity while burn still scales with usage.

• Protocol revenue buybacks: non-EGLD revenues from MBX apps are programmatically converted to EGLD on the open market (rules-based smart contracts).

Priority fees & scalability

• When load is high, a priority fee (tiny user impact ~$0.01) goes to staking providers; if priority fees spike (~4× base fee), add a shard rather than price users out.

• Spam/abuse concern: only the lead validator captures the priority fee, making coordination for profit impractical; modeled attack costs were about $1,200/day with no reliable upside.

Accelerator DAO

• Community-governed Accelerator controls the KPI-gated buckets of emissions for builders and growth.

• Exact DAO design and seat counts will be decided in a separate vote.

• Buckets inside the Accelerator include: Ecosystem Growth Fund (builder incentives DAO-governed), Growth Dividend (user-facing DeFi strategies, DAO-governed), and Protocol Sustainability (core R&D/ops, ~10%).

Reflexive Strategic Investment (RSI) instruments

• Three price-triggered instruments—DAT, U.S. LLC, ETF—activate only under predefined conditions, with advance public notice and reporting. These are regulated structures (NYSE/Nasdaq context) and won’t proceed until contracts are in place.

• DAT aims to accumulate EGLD via a loop (public-markets premium → borrow → buy more EGLD), managed with risk controls; LLC focuses on major integrations/ops (e.g., top stablecoin), and ETF provides a public-market vehicle.

Timeline & process

• Grand Assembly (full-proposal working session) slated for Monday, followed by drafting the final text Tuesday, and a 10-day on-chain vote Oct 15–25. More town halls will run if the community asks.

• Strong ask to vote (yes/no/abstain) and contribute edits before the final draft; this process is intentionally participatory.

Key Q&A highlights

• “What will my APR be?”
  ~9.2% base APR from the staking half of emissions; users may opt into DeFi strategies for higher yield.

• “Is xAlliance running the Accelerator?”
  No. The community will govern the Accelerator via a separate DAO vote; xAlliance is not part of nor controlled by the foundation but an independent collective of builders and contributors.

• “Could validators farm priority fees by spamming?”
  Not feasibly. Only the lead validator earns that fee; modeled abuse would cost ≈$1,200/day with no reliable capture of rewards.

• “What happens after the 3-year lock?”
  They unlock after 3 years. DAT is structured to accumulate/borrow, not sell. For each of the other entities including the LLC, all movements are onchain/transparent.

• “Are the emissions and allocation percentages fixed forever?”
  No. Annual governance check-ins (with quarterly metrics) can rebalance shares between staking, DeFi, builders, sustainability—or add new buckets as needs evolve.

Participation reminder

Vote onchain (even to abstain) and, if you have concrete improvements, show up to the working sessions with proposals and math. This process is intentionally designed for community authorship.

You can listen to the space here.

The very brief Part II including a short clarification on decentralized governance mechanisms can be found here.

We are building the next generation of builders in Nigeria.

On our mission to discover, develop, and deploy talent, we’re partnering with American Spaces Nigeria to bring MultiversX educational programs and workshops into universities—providing students with the tools and resources to build.

American Spaces are innovation hubs supported by the U.S. Department of State in partnership with local institutions. They offer free access to training in entrepreneurship, international affairs, emerging technologies, and leadership.

By integrating MultiversX content into this network, we are creating fertile ground for community-driven innovation and growth.

Students gain:

• Exposure to blockchain technology in a hands-on, collaborative environment

• Access to global builders, mentors, and contributors from the MultiversX ecosystem

• Opportunities to prototype projects with real-world impact and international reach

We’re kicking off this collaboration with the MultiversX Ideathon on September 30th at Window on America, Federal University of Technology Minna Library.

This is an open call for students to Decode, Dream, and Build.

From idea to action, the journey begins on campus.

It’s time to build. Together.