Date: Tuesday, 15 September 2026, 14:00 UTC, OpenDev Call #4 of the hosting pilot
Host: Jesse Chejieh (@jessechejieh:matrix.org), Rank II
Agenda: help-center#21
Previous proceedings: 18 August 2026
Recording: Google Drive
Recap: x.com
Bastian Köcher presented the design of the JAM parachain service in polkadot-sdk#11883. The spec comes as a human-readable markdown document plus a Quint specification. JAM generalises the relay chain’s existing pipeline. Work packages carrying parachain blocks are processed in-core by the refine function, which sets up the environment and runs the PVF, much as backing does today. Once available, they go to accumulate, which runs on-chain, checks that the package builds on a known head and applies the result. Approval voting survives as auditing, which Bastian confirmed when a chat question was relayed. The largest change is on-chain storage. Today the relay chain’s bookkeeping is free beyond deposits for the head and code, whereas under JAM every parachain must hold a locked balance covering its state footprint; the calculation is in the document. Messaging also changes. Only 48 KB can pass from refine to accumulate, so XCM should no longer be routed through the chain and should move to off-chain messaging, following a proposal Bastian had posted the previous week. The service keeps a set of upward messages, to name a few: requesting a code upgrade by hash and length, with the preimage solicited and supplied separately because a multi-megabyte runtime cannot fit in 48 KB; soliciting and forgetting arbitrary preimages, which lets a frequently used smart contract live on-chain instead of in every work package’s PoV; assigning coretime; setting validator keys from the election that runs on Asset Hub; and upgrading the service itself, which only Asset Hub may call. Traces generated from the Quint spec can be run against the Rust implementation to check conformance. There were no questions, and Bastian asked that any that come up be left on the PR.
Sergej Sakač opened RFC 175 by saying it was a leftover from the last call. There has been no progress since it was introduced, and it is waiting for reviews. With relay chain functionality moving to the coretime chain, on-demand is one of the pieces still left on the relay chain. The RFC removes the concept of on-demand cores and instead adds a one-time schedule type to the scheduler, which the current on-demand logic would build on. No questions were raised.
George Pisaltu led the individuality session. It covered individuality-community, recently made public, which holds the pallets and reference runtimes for proof of personhood. The people, light people, members and coinage pallets, along with some supporting logic, shipped in the 2.5 release of the Fellowship runtimes; the rest are expected in the next release. Personhood provides the strong Sybil resistance that justifies on-chain benefits for people. Full people are recognised through decentralised individuality mechanisms (DIMs), which need no central authority and no disclosure of personal information. Light people are recognised by a governance-approved attester, which is weaker, so they get smaller benefits; on Polkadot, for example, they currently get half the free smart contract execution. All of these parameters are set by governance. Members are identified by Bandersnatch keys, which give each person unlinkable aliases in different contexts. The members pallet manages the rings. A new key waits in an onboarding queue so that it cannot be linked to aliases created right after it joins, though a member who has waited too long can include themselves early at some cost to privacy. Ring roots are computed on-chain, and a proof can be verified with only the root. The members pallet sits on the People chain because ring operations take a lot of block space. The members notifier and subscriber pallets share roots over XCM with sibling parachains, which lets Asset Hub verify proofs and expose personhood precompiles to smart contracts without a round trip. The chunk manager pallet holds the governance-set chunks used to build rings. An alias is just 32 bytes with no account semantics, so the alias accounts pallet on Asset Hub, which is rate limited, links an alias to an ordinary account. That account gets a sufficient reference, so it needs no existential deposit and still has a nonce for replay protection, and a transaction extension switches its origin to the alias.
No DIM is enabled yet, so nobody can currently become a person. The next release is DIM 2, a game in which players in a room mimic one another over video and then vote on each other’s personhood. The game and its peer-to-peer connections run off-chain. The game pallet is the single source of truth for scheduling and phases: registration, a shuffle into rooms of six, and voting, where each player submits a vote on every peer and a binary verdict is tallied. The score pallet tracks attendance and streaks until a person crosses the chain’s threshold and can register a personhood key. People who stop playing can be suspended; light people currently cannot. There are two incentive pallets. The pilot airdrop draws winners from VRF outputs submitted when players register for a game. The people airdrop draws from registered people at a frequency set by governance. Shawn Tabrizi added that players receive roughly 5 to 10 NFTs from the game, held under a single-key ownership model similar to coinage, and that the aim is to give them real use in applications and games. George then described coinage. Funds are held as coins of fixed denominations, each in its own single-use account. Because a coin builds up a trail as it changes hands, privacy comes from recyclers: a coin becomes a Bandersnatch voucher in a ring of same-denomination coins and is reclaimed with a proof and a nullifier as a fresh, unlinkable coin. The pallet also supports coin splitting and batching, but the host cut the session short for time.
Kian Paimani asked why reusing a coin erodes privacy, and what happens to someone who never goes to a recycler. George said a coin can no longer be transferred once its age passes a threshold, which keeps very old coins out of the system. Each transfer reveals the previous holder to the next one, and over time that trail can be combined with IP data, social circles and coins moved together to build a probabilistic web of ownership; forcing coins through the recycler breaks it. Kian also asked what the on-ramp to coinage is. George said the recycler holds the deposited DOT or other asset in its pot account while the depositor puts vouchers into the recyclers for each denomination, so coins are minted anonymously on the other side; off-ramping works the same way in reverse. Domenico Valles asked what authorises a game on-chain and what links it to the game actually being played. George said a schedule origin defined by the runtime and authorised by governance schedules games, so individuals cannot. The link to the off-chain game is only the start time, the room assignments and the connection details players post to the statement store. The runtime cares only about the votes, so the video call is one implementation among possible others that use the same rooms, schedule and voting extrinsic. Domenico confirmed that a different front end, even a dice roll, would be technically valid, and George agreed.
Bill Laboon, VP of Ecosystem at Web3 Foundation, set out what the Foundation wants to see before it votes for the next Fellowship salary proposal. The context is Referendum 1940, which asked for 4,800,000 DOT converted to HOLLAR and was cancelled by Referendum 1941 at 99.2% aye. Bill named two conditions. First, people who already receive full-time funding to work on Polkadot should not also be paid by the Fellowship, a point Bastian had already posted. Second, there should be a clearly specified mandate for what the Fellowship does and who is responsible for what. As a lesser consideration, the Fellowship could be paid in a forthcoming USD stablecoin instead of HOLLAR, if its referendum passes. Bill said the Foundation wants a funding proposal to pass and has been talking with Fellowship members about one it could support. The host asked for questions, and none were raised.
Clara van Staden presented RFC 167, a circuit breaker for Snowbridge. It is the proactive counterpart to RFC 166, merged on 7 September, which lets anyone halt the bridge by posting a large deposit; OpenGov then refunds the deposit if the halt was justified or slashes it if not. RFC 167 would delay transfers once configured caps are reached. It has been open for a couple of months and had comments from Domenico Valles, Adrian Catangiu and Clara’s own team, and she reworked it in the past week. Snowbridge traffic is asymmetric, with heavy inflows from Ethereum on some days and heavy outflows on others. The RFC therefore takes a simple approach: it counts gross rather than net flows and uses two breakers, one on Ethereum and one on Asset Hub. Each works like a leaky bucket that drains over 24 hours, with per-asset limits in token denomination set by OpenGov; the parameters in the RFC are rough and still open. Sergej asked whether someone could cycle funds to push the bridge into the delayed state. Clara said this griefing risk is covered in the RFC. She argued that fees, which go to the treasury, and caps set high enough make it unreasonable, and that the trade-off favours rate limiting, since the major bridge hacks she cited all concluded they should have had it and Hydration already does. She asked Sergej to review the RFC and assess how large the risk is. Asked about the delay, Clara said 24 hours gives alarms and maintainers time to react, but it is configurable by OpenGov and open to debate. Asked whether a special origin can act during the delay, she said the response is to halt the bridge under RFC 166, after which anyone can submit an on-chain proposal to remove or replay transactions, which is why the two RFCs go together. Kian said there is no perfect answer between safe but clunky and smooth but vulnerable. Since AI currently helps attackers more than defenders, Kian favoured accepting some friction, ideally with limits no user ever hits, and noted that a formally proven bridge would not need a breaker. Neither RFC 175 nor RFC 167 reached a decision on the call.
Tell us what to change, and whether these calls should continue, in the feedback form. Next call: Tuesday, 20 October 2026, the third Tuesday as always · agenda thread opens ~1 weeks out.