Date: Tuesday, 18 August 2026, 14:00 UTC
Host: Jesse Chejieh (@jessechejieh:matrix.org), Rank II
Agenda: help-center#20
Clara van Staden (Snowfork) presented RFC 166, Snowbridge Emergency Pause. Snowbridge can currently only be halted through an OpenGov referendum, which takes hours to days and is too slow against a live exploit; a possible emergency situation around April or May made that concrete. The RFC adds a pallet that lets anyone freeze the bridge by placing a deposit, configurable and currently pencilled in at around 100,000 DOT, after which OpenGov decides whether to refund it or slash it. The hold reaches three places, the Ethereum side, Asset Hub, and the Ethereum light client, and any of the three that fails is retried in on_initialize. The halting machinery itself already exists and is gated behind the root origin, so most of the work is in who is allowed to call it. Clara said the urgency felt higher earlier in the year and has since receded, but the bridge still secures roughly $20 million, and the reputational cost of a successful exploit runs well past the number itself.
Bastian Köcher tied the proposal to the earlier work on safe mode and transaction pause for Asset Hub, which uses the same deposit-triggered pattern, and asked Domenico Valles to restate the objection he had raised then. Domenico was against it there and still is: a well-funded actor, a nation state in his framing, would find the deposit cheap for the ability to shut down economic activity across the network. He is more comfortable with it on a bridge, where the exploit history is long and the consequences of a compromise are severe, and expects it to be replaced once the tooling allows, perhaps by proof of personhood plus a small democratic quorum. Clara put it as a trade-off against censorship, and noted that the obvious alternative, giving the Fellowship the power to hold the bridge, introduces problems of its own. Bastian agreed the Fellowship should not hold it, because that puts legal exposure on individual members who would be badly placed to refuse a government that came knocking, which leaves a permissionless call backed by money at stake as the only workable shape. He also pushed on the personhood argument: it does not defend against an attacker willing to burn both an identity and the deposit, so the cost of repeating the attack is doing the work either way. Nobody offered a fourth option, and the room landed on the deposit as the best currently available answer for a bridge, with the broader question of the pattern left open.
Domenico asked whether implementation was under way, having thought he saw code go by; Clara corrected him, her team has been on other security work and has not started. She also has a second RFC covering circuit breakers, which would detect anomalous flows through the bridge and delay the transactions rather than react after the fact. It is considerably more complicated and she deferred it to a later call.
I then opened the floor to the repository permissioning friction raised in the chat room, where parts of the individuality integration cannot be tested because one of the repositories belongs to Parity rather than the Fellowship. Domenico asked whether anyone at Parity is building a Polkadot-native, non-public Git host the Fellowship could permission against. Bastian knew of a prototype from around the turn of the year but sees no active effort, and said Radicle does not appear to support private repositories at all. On shape, his rule of thumb is to put on chain only what genuinely needs global consensus, which for a Git host means user management and permissions and little else; he pointed to the bulletin chain as intermediate storage and the statement store as a way to discover who currently holds a given repo, to name two pieces of the existing stack, and observed that with enough Fellowship members online at any time a peer-served model is plausible. He rated the existing GitHub Actions integrations that read on-chain Fellowship data as limited by comparison. Domenico said he had time and would look into feasibility. Bastian closed the thread by noting that the draft PR which prompted the chat discussion would be opened up before it merged, alongside the existing community repo, though not as quickly as people would like.
Sergej Sakac presented RFC 175, On demand as core scheduling. It follows RFC-32, Minimal Relay by moving on-demand coretime sales off the relay chain: orders are placed, priced and paid on the Coretime chain, the broker commits individual blocks as one-shot core assignments through the same channel bulk coretime already uses, and the relay chain’s on_demand pallet is removed. Bastian first read it as keeping scheduling logic on the relay chain and objected on that basis. Sergej clarified the distinction: the existing assignment path holds a core for a task until something else is assigned to it, whereas a one-shot assignment covers a single block, after which the core goes idle or continues with whatever else is queued on it. Bastian withdrew the misreading and said the direction matches JAM, where the core side stays deliberately simple, taking authorizer hashes and a point in time at which the assignment is forwarded, with everything about when work gets scheduled living on the Coretime chain. Asked whether the approach would adapt cleanly to JAM once it lands, he declined to answer off a skim and committed to reading the RFC in full. No one else on the call had read it yet, so it stands open for review.
Outside Fellowship business, Domenico flagged recent work by Ross Bulat, who maintains the Polkadot staking dashboard, on validator retention metrics that show which validators immediately liquidate the DOT they are paid. His argument is that liquidation is a signal about who is invested in the network’s long-term security, and that surfacing it should move behaviour. Bastian pushed back: validators have real infrastructure bills, that is what the payment is for, and the better fix is paying them in a stable asset that covers costs with DOT on top to keep them in the system, rather than penalising liquidation. Domenico’s reply was that publishing the metrics creates a market that discovers the true cost of running a validator, since competition should push each operator toward retaining only what their infrastructure actually requires, instead of a monthly figure someone sets by decree. Bastian’s counter was that any flat fee still has to be agreed by the people paying and being paid, and that the forum discussion has tended to generalise from whichever corner of the world happens to be cheapest. Neither conceded and the exchange ended there. Ross was not on the call.
Bastian closed with an update on the parachain service design for JAM, the piece that gets parachains running on it. He had considered the design finished some time ago, but writing a Quint formal specification alongside the written spec surfaced a run of small issues and corner cases and left the requirements for the system materially clearer. There were no questions, and I asked to give it a proper slot on the next call.
Tell us what to change in the feedback form. Next call: Tuesday, 15 September 2026 · agenda thread opens next week.