A node does not recode on the first shard.
mump2p waits until the local set crosses a forward threshold. Docs tie that to the shred factor. Below it, you are still collecting. Above it, you mix a new combination and push it to mesh peers.
That threshold is the difference between helpful forwarding and noise. Too early and you spray dependent shards. Too late and the next hop sits idle while you wait for a full block you do not actually need.
Mesh size is capped the same way GossipSub already does it. A target peer count, graft if you are under, prune if you are over. Coding changes the payload, not the habit of keeping the mesh from turning into a flood.
Publisher side is separate. It shreds, multiplies the initial shard count, and round-robins them out. Intermediates only join once they have enough to make a new equation worth sending.
@get_optimum
Tokenized IP was supposed to pay the artist when the song was played. Most of the time it pays a stack of companies, months later.
The play happens in one app. The report lands in another. A distributor, a publisher, a collection society, then a platform each take a cut before anyone writes the number down. The chain, if it is involved at all, only sees the last transfer.
That is the same middleware problem with a song attached. Opaque reporting is not a music bug. It is what you get when every hop sets its own books.
On Rialo the play can be the event. An app reports it through a native web call. A reactive transaction settles the split when the condition is met. The artist’s share does not wait on a quarterly statement, and it does not pass through four invoices to become real.
No hidden cut for a keeper. No separate silo for the payout. The right is only useful if the money can follow the play.
@RialoHQ
Ammora powers token markets on GIWA.
You can verify their fees and liquidity onchain.
Join the waitlist, earn points early, and discover your next alpha.
ammora.org/waitlist?ref=a540…
@GIWA_by_Upbit @AmmoraHQ #Ammora #AmmoraD1_WTZ26CKJ
A coded shard is not trusted just because it arrived.
mump2p mixes the block into random linear combinations, so a peer can forward a new one before it has the full message. That is also the attack surface. A bad peer can push junk combinations and waste the decode.
Docs handle it on decode, not on every hop. The shards are checked against a hash and the publisher signature bound to the original data. If the rebuild fails that check, the sender's reputation drops and the peer gets isolated.
Until then the mesh still moves fast. Independence is checked as shards land. k independent ones are enough to invert and rebuild. Fail the signature and that set is useless, and the node that fed it pays for it.
Same libp2p mesh. Different payload rules.
@get_optimum
Gas is the cost people argue about. It is rarely the cost that kills the app.
A feed, a keeper, an indexer, an RPC, a bridge. Each one looks small on its own invoice. Each one also sets its own price, without caring what the layer above or below is already charging.
That is an old supply-chain problem. Double marginalization. In crypto it stacks, so the sharper name is compound marginalization. The user price rises. Demand falls. Total profit falls with it. What survives is whatever can ignore the fee: a liquidation bot, a whale loop. Ordinary apps get priced out.
Rialo’s answer is not a cheaper plugin. It is to stop renting the plugin. Data, automation, web calls, and the cross-chain hop sit in the protocol, so those markups are not set four times.
One system. One price. The middleware bill is the thing being designed out.
@RialoHQ
A block does not have to travel as a block.
mump2p shreds it and encodes the pieces as equations. Random linear combinations. A peer is not waiting on packet 7 of 12. It is collecting enough independent equations to solve for the original.
That is the flexnode job in the current product. Get more equations, and more variants of those equations, to the nodes that still need them. Propagation latency is basically how fast the last validator crosses that threshold.
The buffer stays bounded on purpose. Hold enough to recover a loss, then stop. Not an open pile of copies.
DeRAM and DeROM are the next layer in the docs, reads and writes on the same coded network. Not what you run today. Today is mump2p, beside the client you already have.
No consensus change. No client fork.
Data movement sets the ceiling. Optimum raises it.
@get_optimum
Chains got fast. The apps on them still wait.
A price moves, a payment clears, a ship scans in. Someone still has to notice, package that into a transaction, and hope a keeper is awake. The chain itself is sitting there until a person, or a bot, knocks.
That is the odd part. We built systems that can settle value, then left the "when" to a script outside the system.
Rialo keeps the condition onchain. Time, balance, an outside event. When it is true, the transaction runs. Same check on every validator. No one has to be online for it.
Not a new slogan. Just a chain that does not need a babysitter for ordinary work.
@RialoHQ
Building Rialo Bounty has been a great experience, and I'm happy to share what we've been working on.
The idea was simple: create a platform where companies can post bounties, developers can solve real problems through GitHub PRs, and rewards are handled transparently on-chain.
But we wanted to take it further than a traditional bounty platform.
With Rialo, each bounty has its own on-chain vault, reactive transactions manage the bounty lifecycle, and funds can be refunded automatically if no solution is submitted.
We also integrated REX to verify GitHub PRs through Rialo nodes, creating an on-chain proof of the result. On top of that, Latch powers AI-assisted code reviews, helping evaluate requirements, security risks and CI results before a payout.
Beyond the core mechanism, we've built a wallet with GitHub-based onboarding, a project showcase, a leaderboard, points and Rialo Quest with on-chain NFT badges.
What I like most about this project is that we're not just talking about what Rialo can do. We're building something that puts these capabilities into practice.
On-chain execution, external data verification and AI-assisted evaluation all come together in one application.
Rialo Bounty is open source and live on Rialo devnet. There's still more to improve, and I'm looking forward to seeing how developers use it and what feedback we receive.
If you're building on Rialo, give it a try and let us know what you think.
Stay with @RialoHQ.
@ericargent31113
We built Rialo Bounty together with @0xFAlpha. It's an open-source bounty platform running on Rialo devnet.
Companies lock native RLO into a bounty, developers solve it with a GitHub PR, and payment happens automatically. No middlemen, no need to trust me.
How a bounty works
• Every bounty has its own on-chain vault (PDA). No one can move that RLO manually.
• A reactive transaction acts as the bounty's heartbeat. It tracks the deadline, the decision, the payout and the refund.
• If no solution comes in, the RLO automatically returns to the company.
Where REX comes in 🔍
Before payout, a REX component calls the GitHub API from Rialo nodes. It checks that the PR was merged and that the PR author is the GitHub account linked to the winning wallet.
All nodes must return the same result, and the result is written on-chain as a Proof.
Where Latch comes in 🔐
The AI review reads the PR changes, checks every requirement, looks at security risks and the CI result, then gives a score from 0 to 100.
Since the model runs through Latch, the API key stays encrypted. If the company doesn't pick a winner, the highest AI score wins.
What else is there
• Built-in wallet, no extension needed. Sign in with GitHub on any device: one GitHub account = one wallet.
• Project showcase. AI scans the repo's code and README.
• Points and a leaderboard.
• Rialo Quest, a 60-second mini game with on-chain NFT badges.
• Public transaction log and a TR/EN interface.
It's all live on Rialo devnet. Open a bounty, submit a PR, or just play Rialo Quest 🎮
Open to feedback.
Stay with Rialo💪
@RialoHQ
@ericargent31113
@slymnogunc
@ecelannister
🔗 cagdasozsahin.github.io/rial…
People hear "new network" and assume a new client. That is not the flexnode model.
A flexnode sits beside the client you already run. It speaks the coded gossip, keeps a bounded buffer of RLNC shards, and can still peer with libp2p and GossipSub where that is useful. Docs describe it as permissionless. Anyone can operate one next to an existing P2P stack.
The buffer is the practical part. It is not an open-ended mempool of copies. It holds enough coded frames to recover a loss and smooth the tail, then it stops. Encode, decode, forward. Memory requests on the side.
That is also why L1 and L2 teams are in the intended-user list, not only validators. Faster block and blob propagation without a protocol rewrite. The Gateway is the on-ramp. mump2p is what the node actually speaks.
No consensus change. No client fork.
Data movement sets the ceiling. Optimum raises it.
@get_optimum
Every Builder Hub session reminds me why I enjoy being part of the Rialo community.
It’s not just about the tech or the projects we build. It’s also about the people sharing ideas, helping each other, and turning those ideas into something real.
Happy to be on this journey with you all. Still learning, still building, and excited to see what comes next. 💚
@RialoHQ
Pantera’s investment in Rialo feels less like a bet on another L1 and more like a bet on where onchain infrastructure is heading.
The interesting part is Rialo’s attempt to make real-world systems, external data, interoperability and execution feel native to the protocol.
That matters because the next wave of blockchain adoption won’t come from putting more things onchain.
It will come from making onchain systems actually work with the world outside them.
That’s the part of Rialo I’m most excited about.
@RialoHQ
mump2p is now live on Ethereum mainnet, and this is a big milestone for @get_optimum.
2-3x faster data propagation, $3.4B in ETH stake already boosted, and free access opening up for all Ethereum node operators.
Better networking means better performance for the entire network. This is the kind of infrastructure progress Ethereum needs as it continues to scale.
The Optimum team is pleased to announce our first mainnet deployment, mump2p on Ethereum. With mump2p, data moves across all of Ethereum 2-3x faster, boosting validator performance and network health.
$3.4B of Ethereum stake is already being boosted by mump2p, and we’re now opening up free access for all Ethereum node operators.
mump2p is not a new gossip stack sitting next to libp2p. Docs call it Galois Gossip. Same libp2p host, same mesh, same GRAFT and PRUNE. What changes is the payload.
GossipSub forwards the full message. mump2p shreds it into k fragments and sends random linear combinations. A peer does not need a specific shard. k independent ones are enough to invert the matrix and rebuild the block.
Once that happens, it can send IDONTWANT. Peers stop pushing shards for a message you already decoded. That is the part people miss when they only talk about speed. The mesh also stops wasting the rest of the slot on copies you no longer need.
Recoding sits in the middle. If a node is holding more shards than the forward threshold, it mixes a new one and sends it on before it has the whole block. Flexnodes keep that set in a bounded buffer, so a loss does not turn into a full resend.
There is a security catch too. A random combination is only useful if it is the publisher’s data. Shards are checked against a hash and signature on decode. Fail that and the sender’s reputation drops.
Same client. Gateway beside it. No consensus change.
Data movement sets the ceiling. Optimum raises it.
@get_optimum
Ethereum’s post-quantum migration highlights how difficult it can be to adapt an established ecosystem. QMS takes a different approach by starting with two settled layers, building its foundation with quantum resistance in mind from the beginning rather than treating it as a distant upgrade.
A proactive approach could make the transition more manageable as quantum computing advances.
#QMS1002
Parallel execution is not one setting. A social feed and a liquidation queue do not collide the same way.
Optimistic mode runs transactions immediately and retries on a clash. That fits low-conflict work, where most transactions never touch the same accounts. Pessimistic mode locks the contested resource first, so a high-conflict financial access lands once instead of thrashing.
Rialo switches between them with the workload. The runtime does not assume every block looks like a DEX, or like a feed.
That matters once reactive transactions and web calls sit in the same block. A scheduled liquidation and a batch of unrelated updates should not share one concurrency policy.
Speed is the easy claim. Getting the conflict model right is the part that keeps the block from falling over.
@RialoHQ
A late block is not only a missed attestation. It is also a bandwidth bill.
Gossipsub keeps copying the payload until enough peers have it. On a clean path that is wasteful. On a lossy path it gets worse, because the missing piece is requested again as the same packet.
RLNC does not resend that packet. The block is split and mixed into random linear combinations. If one shard drops, another independent combination can close the gap. A node can also mix what it already holds and forward a new shard before the full block is in.
That is why the bandwidth cut is the quiet part of the Hoodi numbers. About 150ms average propagation, at least 6x under Gossipsub, and roughly 90 to 95 percent less data on the wire.
mump2p sits beside the CL client you already run. No fork. No consensus change.
Data movement sets the ceiling. Optimum raises it.
@get_optimum
Most chains only run when someone sends a transaction.
Rialo also runs when a condition becomes true.
A reactive transaction is two parts: → a predicate (time, balance, price, external event) → a payload (what executes when it hits)
Validators evaluate the predicate against the same state at the end of every block. If it holds, the transaction is queued inside consensus. No keeper. No bot. No cron.
Chain those together and you get a workflow: liquidations, subscriptions, agent payouts. Asynchronous, onchain, deterministic.
That’s the difference between a ledger and a system that can react to the real world.
@RialoHQ
