Parity Technologies

The first Polkadot Solidity Hackathon, organized by @openguildwtf in partnership with @Web3foundation, has concluded. More than 260 teams and 850 hackers participated, building with Solidity on Polkadot Hub across EVM and PVM environments. We thank all participants for their contributions. 🧵

Systems that treat storage as permanent inevitably face challenges with state growth. In some cases, this leads to apps following a hybrid, what we call a “Web 2.5 model”, where sacrifices are made to deliver an app on par with user expectations. Ephemeral storage is one approach to managing that problem while keeping infrastructure sustainable. Bulletin Chain is an experiment in that direction and is being explored as part of Polkadot’s broader data infrastructure.

This model enables a different class of decentralized applications where data has a natural lifecycle, think about: • event announcements • messaging systems • temporary file sharing • real-time feeds • cross-chain message buffers Data exists when it’s needed and disappears when it isn’t. 🤌

Every blockchain eventually hits the same problem of state bloat. Applications want to publish data on-chain… but permanent storage is expensive and unnecessary for most use cases, and, ofc, not everything needs to exist forever. This problem becomes especially prevalent when building fully on-chain applications with rich media that aim to provide users with an experience on par with what they are used to in their current apps. Bulletin Chain introduces ephemeral storage for Polkadot, where data is available long enough for verification and usage, then automatically removed to create a cleaner chain, lower costs, and enable builders to create new classes of applications. Let’s dive in 🥽

I went into the @Polkadot Solidity Hackathon planning to add one component. Ended up building an entire IDE. Relaycode was made with modularity in mind - every pallet parameter gets its own input. So Revive pallet just needed a Solidity editor component. Simple, right? Except the interface felt way too small for writing actual contracts. Two days before the deadline, I scrapped the plan. And built Relaycode Studio instead. 👇

Polkadot is often misinterpreted as just another blockchain bridged to other chains, but that framing misses the architecture completely. Polkadot provides shared infrastructure: security | consensus | data availability | cross-chain messaging But sadly, many people still picture Polkadot like this: Chain ├ parachain ├ parachain ├ parachain That mental model is wrong, or at least unfinished, and it makes Polkadot look like many independent chains loosely connected, which conceals the real innovation of shared security & shared infrastructure. Without this understanding, people ask the wrong questions, like… “Why does the Polkadot Relay Chain show so few transactions?” “Which parachain competes with Ethereum?” “Which parachain is the main chain?” A better question would be. What functionality does the Polkadot Network provide? It provides: Launching application-specific blockchains Deploying smart contracts Cross-chain functionality and asset transfers Running decentralized governance systems Some of these capabilities run directly on Polkadot Hub, while others are implemented by chains built on the network. But straight out of the box, Polkadot contains all the components that make this possible.

Final call: The @Polkadot Solidity Hackathon 2026 submissions close tomorrow. If you’ve been building on Polkadot Hub using Solidity, now’s the time to ship. An essential moment for: • onboarding EVM developers • testing app-first workflows • turning ideas into live applications Next signal: what gets built and what happens after. Huge thanks to @openguildwtf and @Web3foundation.

Cross-chain shouldn’t mean fragile bridges and external trust. The @Polkadot docs now clearly explain native chain interaction, how chains communicate, how assets are transferred, and how they coordinate securely. This isn’t an add-on. It’s part of the design. 👉 docs.polkadot.com

Instead of compressing everything into a single gas value, these are tracked across multiple dimensions, giving developers more visibility into trade-offs while maintaining compatibility with existing workflows. As execution models mature (e.g., PVM), these dimensions can become more explicit.

@paritytech It would be great to add what this means for developers rather than just describing the implementation and how estimation differs if choosing PVM

Ethereum measures execution with a single gas value. Polkadot measures resources differently. On Polkadot Hub, developers interacting through Ethereum wallets still see familiar gas values. Under the hood, however, the runtime tracks resources across multiple dimensions: • ref_time → computational time • proof_size → state data validators must verify • storage → persistent on-chain state, requiring deposits to reserve space Because Ethereum tooling expects a single gas value, exposing this model directly would break compatibility. Challenge accepted 🧑‍💻 Polkadot Hub solves this through gas mapping. At the RPC layer, Ethereum-style gas is translated into Polkadot’s internal weight and storage deposit model. When a wallet calls eth_estimateGas, the system performs a dry-run of the transaction to measure: • computation • state verification • storage footprint These resources are then mapped to gas, presenting the user with a familiar value while developers use familiar Ethereum wallets and tooling. Meanwhile, the runtime tracks computation, state verification, and storage usage separately. Ethereum compatibility on the outside. Multi-dimensional resource metering underneath.

🚧 Please be advised that the Polkadot community is currently voting on upgrading the Polkadot system to v2.1.1. This is a major runtime upgrade that provides support for Phase 1 of the Dynamic Allocation Pool (DAP), an issuance buffer configured as a multi-asset account (or sets of accounts) that collects all newly minted DOT and protocol revenue, enabling specific outflows in both DOT and other assets. 🔴Important note for Ecosystem participants: This release introduces numerous changes around staking and issuance which will stop treasury burns and redirect slashes in the first instance. This release also provides the prerequisites for making nominators non-slashable, allowing them to unbond funds in two eras, and enforcing a minimum self-stake and a minimum commission for validators. All these new parameters will be activated through subsequent OpenGov referenda. Additional note for Ecosystem builders: A Polkadot Technical Fellowship calendar has been set up to log basic information about upcoming runtime releases. You can subscribe to the Google calendar to access advance notices in real time. The projected enactment date for this runtime upgrade is around 26th March 2026.

@Polkadot Start building ↓ wizard.openzeppelin.com/polkadot

@Polkadot In this walkthrough: • Explore the wizard UI • Generate an ERC-20 with common extensions • Deploy to Polkadot using Remix or your preferred workflow youtu.be/WtkamOUxSms?si…

Ethereum-compatible smart contracts are expanding across the @Polkadot ecosystem. The OpenZeppelin Contract Wizard now lets developers generate Solidity contracts ready for deployment on Polkadot.

The first reduced issuance event happened today. You can see here, compared to the previous era, a much smaller amount of DOT was minted.

It’s happening. March 14, Pi Day, marks the issuance model change for Polkadot. One of the specifications is the maximum supply of DOTs, which is visualised below.