🇦 🇷 🇮 🇪 🇳 🪐

how a live shard stays honest. one transaction. atomic execution. then the round closes. around 600ms. true finality around 200ms. that part people already feel. the part that matters more: no node is trusting a screenshot from another node. over 3200 validators, many on low spec machines, recompute. they check signatures. they check roothashes. they walk their own trie. if the data does not match, the block does not fly. sharding is not a marketing word there. it is how you keep that check cheap enough that ordinary hardware can still do it, while the metachain notarises what the shards agreed. Why does this matter when AI can rewrite huge codebases overnight? Because the chain still needs a base that any node can verify without asking permission. public code. public state. any LLM can verify the rules. the humans and the agents both consume the same truth. We probably still need better private / confidential transactions. and better base dApps. that is the reality. but the verification layer is gud. check the code. it is public.

wonderful news from AI. more and better tooling yields in much better results for everyone. i am still asking for super fast access to the best models which can catch bugs, zero days, discrepancies, for those who make full KYC and it can be demonstrated that they use it for their own projects. that should be pretty easy to do. you can work only on repositories X Y Z because you are a core contributor to those. and here is the full cyber capabilities for this, and make your own code better. as there are obliterated open source models and api providers out there, i think, those who are contributing really should be able to use at full capabilities the frontier labs and making sure the web stays safe. let's BUIDL more!

i have been thinking about what always on agents actually need from a chain. not another chat demo. settlement. when an agent works in the background it will eventually pay another agent, or a tool, or a merchant. that payment has to be cheap, gasless if you want UX, and final fast enough that the agent can check and settle in the same breath. 600ms rounds. around 200ms true finality. relayed txs so the user is not babysitting every signature. that is why we talk about the finance computer. MultiversX + xMoney + xPortal. one API, for humans and agents too. built on Supernova and the Agentic Payments stack. What surprised me building the payment rails: the model is the easy part. the hard part is the rails. escrow. retries. who pays gas. what happens when the agent is wrong. Why? Because an always on agent without honest money movement is just a script with opinions. We probably still need better provenance on what an agent claims it read. source aware checks, not "the fact existed somewhere in the tool soup". but the base for agentic payments is there. check the code. it is public. less talk, more shipping.

seriously now: everyone ships always on agents this week. cute names. cloud workspaces. proactive research. fine. test them. but if the agent can spend, browse, and keep state overnight, the boring questions matter more than the launch video. who reviews the high risk actions. what is read only. what is auditable after the fact. can another agent verify the payment without trusting a screenshot. that is where AI and chains meet for real. not vibes. rails. i will keep testing. and keep hardening the rails on my side. the connections will be a must. mathematically demonstrating decisions.

The attacker account erd1naytrk5945udc956nw84kjjkeht7hldr6rx375qjljwv98pqv2uqfdl45l attempted a Wasmer compiled-code cache poisoning exploit targeting the official MultiversX xBridge (Ad-Astra) Ethereum Safe contract. The attacker tried to exploit a known VM vulnerability ("Stale code hash after same-transaction upgrade runs wrong code and poisons compiled/warm caches"). The goal was to force validator nodes to associate the codeHash of the legitimate Bridge Safe with an attacker-modified backdoored WASM binary containing drain functions (bridgeOut, drain). If successful, subsequent legitimate calls to the official bridge contract would execute the backdoored code, allowing the attacker to drain the bridge's vault. After the upgrade: Cache poisoning is impossible: An upgraded contract within the same transaction is compiled and cached strictly under its own hash (HMHM​). Victim contracts are safe: The legitimate contract's code hash HH (xBridge: Ethereum Safe) cannot be overwritten or aliased in the warm or compiled code cache. Execution integrity restored: Subsequent calls to the upgraded contract will execute the upgraded bytecode under HMHM​, without polluting or reading from HH. Before the upgrade: In sync, after invoking upgradeContract on child contract B, the contract immediately called ping on child contract B via executeOnDestContext. When the node's VM runtime dispatched the subsequent call on B, it resolved the Wasmer instance. Because the Bridge Safe code is an active, heavily executed mainnet contract, its codeHash H was already resident in the node's warm LRU / compiled-code store. Instead of compiling the newly supplied bytecode M, the node reused the existing compiled instance of the legitimate Bridge Safe code. Because the legitimate Bridge Safe code does not export ping, the VM halted with invalid function (not found) [ping]. The attacker tried 38 times with the first contract (using a minimal WASM stub) and 4 times with the second contract (using the full 28KB bridge WASM), but every attempt hit the same cache behavior and reverted before reaching collect. This is the unhinged reality.