| Report Date | 2026/07/07 |
| Submitted by | Jesse Chejieh |
During this reporting period, focus remained on FRAME governance automation and treasury resilience: the permissionless scheduler moved from design to a working implementation, both open RFC implementations advanced through review, and I began hosting the Fellowship's monthly OpenDev calls.
The FRAME scheduler is privileged, so contracts and ordinary accounts cannot schedule future actions on-chain. Without a permissionless primitive, recurring payments, automated DeFi strategies like liquidations and rebalancing, and autonomous agents rely on off-chain keepers, which are trust-assumed and can silently stop. This period the scheduler moved from design to a working proof-of-concept pallet-cron for one-time and recurring RuntimeCall execution on the FRAME Task System, so any account can pay to schedule a call the runtime then executes. The open question was doing this without opening a spam or unfunded-execution vector: storage deposits go through Consideration, each run is charged at execution-time prices from prepaid funds, scheduled calls share a per-block weight budget, and call filters are re-checked at execution so a later-restricted call cannot slip through. #12227 auto-bounds RuntimeTask: From<Task<Self>> in FRAME, removing per-pallet boilerplate for pallets on the Task System.
pallet-whitelist gates high-privilege governance calls behind Fellowship approval. Today, if a referendum enacts a whitelisted call before the Fellowship has whitelisted it, the authorization is consumed and the whole referendum must be re-run, so a timing mismatch between two independent governance tracks can permanently burn a passed decision. Deferred dispatch banks the enacted call in storage instead of consuming the authorization; once whitelisting lands, anyone can trigger execution. This removes a class of governance stalls that today need manual re-coordination. This period addressed review feedback and integration testing.
pallet-treasury pays approved spends in whatever order they are claimed, so a smaller, later-approved spend can be paid ahead of a larger, earlier-approved one and drain available liquidity, leaving earlier commitments stuck until more funds arrive. FIFO-per-AssetKind ordering makes payout order follow approval order, so treasury behaviour is predictable and approval is a real commitment to pay. It overlaps with Treasury Asset Categories (#10381) on the same dispatchables and Spends migration, so this period the two implementations are being reconciled.
The Secretary Collective budget increase doubles its monthly budget to onboard a Technical Coordinator. The collective runs the Fellowship's operational load; a dedicated coordinator moves that off individual Fellows so it no longer depends on ad-hoc volunteering.
OpenDev is the Fellowship's open technical call, and it had lapsed, leaving technical coordination without a regular synchronous venue. Under the hosting pilot I resumed and now host these calls. The 2026/06/30 session centered on asset-based storage deposits and settled on migrating pallets off hardcoded Currency deposits onto Consideration.
| Ranks | Activity thresholds | Agreement thresholds | Member's voting activities | Comments |
|---|---|---|---|---|
| I | 90% | N/A | ||
| II | 80% | 100% | I have voted on 0 out of 0 referenda in which I was eligible to vote (i.e undefined% voting activity). Out of 0 referenda in which members of higher ranks were in complete agreement, I have voted in line with the consensus 0 times (i.e undefined% voting agreement). | No referenda requiring Rank II votes during this period |
| III | 70% | 100% | ||
| IV | 60% | 90% | ||
| V | 50% | 80% | ||
| VI | 40% | 70% |
Question(s):
Concern(s):
Comment(s):
Threshold