This article is published at the same time on the Cardano Forum at https://forum.cardano.org/t/fundamental-critcism-of-the-budget-process/143519 and in my dRep GitHub repository at https://github.com/HeptaSean/cardano-drep/blob/main/articles/2025-02-24-Budgets.md.
Fundamental Critcism of the Cardano/Intersect Budget Process
I’ve tried it months ago in https://forum.cardano.org/t/shaping-cardanos-future-a-deep-dive-into-the-2025-budget-process/138515/4 without ever getting the promised answer and in discussions in the (horribly chaotic) Intersect Discord server, so I’m trying it again.
A lot of people have voiced concerns about the budget process in recent months. As is sadly usual in Cardano – from years of Catalyst via CIP-1694 to the constitution – such concerns were seldomly taken serious, they were ridiculed, sidelined, knocked back with: “If you don’t like it, just propose something better!”
Ironically, while I was still in the process of writing this, the concerns suddenly became valid by an X post (https://xcancel.com/IOHK_Charles/status/1893428390411280441) and later space by the supreme leader himself. (It’s sad that the Cardano community at large – despite all the cheap talk about “Do your own research!” and how “science-driven” especially Cardano supposedly is – only believes something if this one very questionable person says it – even if it is a sudden and unexplained 180° turn compared to what he said previously.)
Net Change Limit
The Intersect Budget Committee claims that they interviewed “experts” to come up with their proposal for a net change limit of 350 MADA in https://forum.cardano.org/t/net-change-limit/143118.
So, let’s look at the data. Check out @werkof’s excellent thread https://xcancel.com/C1cADA_Markus/status/1636023354334347265 on how reserves, treasury et al. work together.
| Epoch | Beginning | Reserves | Treasury | Withdrawals/Inflow |
|---|---|---|---|---|
| 240 | 2021-01-05 21:44:51 | 12_706_064_600_811_922 µADA | 247_808_783_829_569 µADA | 2_591_730_782_382 µADA |
| -1_654_433_067_157_250 µADA (13.02%) | +515_312_754_028_165 µADA | 517_904_484_810_547 µADA (4.08%) | ||
| 313 | 2022-01-05 21:44:51 | 11_051_631_533_654_672 µADA | 763_121_537_857_734 µADA | 81_108_350_923_444 µADA |
| -1_392_018_527_129_520 µADA (12.60%) | +356_447_552_699_298 µADA | 437_555_903_622_742 µADA (3.96%) | ||
| 386 | 2023-01-05 21:44:51 | 9_659_613_006_525_152 µADA | 1_119_569_090_557_032 µADA | 58_931_404_863_383 µADA |
| -1_173_311_491_823_417 µADA (12.15%) | +331_673_639_745_641 µADA | 390_605_044_609_024 µADA (4.04%) | ||
| 459 | 2024-01-05 21:44:51 | 8_486_301_514_701_735 µADA | 1_451_242_730_302_673 µADA | 154_280_000_000_000 µADA |
| -990_527_603_116_362 µADA (11.67%) | +190_413_598_882_157 µADA | 344_693_598_882_157 µADA (4.06%) | ||
| 532 | 2025-01-04 21:44:51 | 7_495_773_911_585_373 µADA | 1_641_656_329_184_830 µADA | 0 µADA |
The creation of this table is implemented in 2025-02-24-Treasury-History.py.
The reserve and treasury values at the beginning of the epochs are taken from https://api.koios.rest/#get-/totals. For Epoch 240, the reserve is corrected by the withdrawals from https://api.koios.rest/#get-/reserve_withdrawals to get a view closer to what happens due to the regular operation of the chain.
The treasury withdrawals are taken from https://api.koios.rest/#get-/treasury_withdrawals. For each year, those have to be added to the net increase of the treasury to get the real inflow to the treasury in that year.
The percentages are percentages of the reserves at the beginning of the year. Observe that the depletion of the reserves is much slower than the theoretical maximum depletion of 100% – 99.7%^73 = 19.69% would be. On the other hand, this leads to a slightly larger treasury inflow (since later in the year more of the reserves are left and used as input for the pots from which the treasury gets 20% each epoch). The transaction fees also play a role, although a very minor one.
Based on the treasury inflow of around 4% of the reserves at the beginning of each year, I project an inflow of 4% × 7.5 GADA = 300 MADA (even a little less) for 2025. So, the guesstimate of 350 MADA by the Intersect Budget Committee is already too high to serve their stated goal of at least preserving the current treasury stock.
I am going to vote “No” on any net change limit higher than 300 MADA.
I urge every dRep – especially those that have pledged to pursue a conservative approach on treasury spendings – to consider similar red lines.
Based on an assumed reserve depletion of 11.5% and again a treasury inflow of 4% per year, a net change limit of 300 MADA would lead to the following development over the next eight years (two cycles if you believe in cycles):
| Year | Reserves | Treasury | Withdrawals/Inflow |
|---|---|---|---|
| 2025 | 7_495_773_911_585_373 µADA | 1_641_656_329_184_830 µADA | 300_000_000_000_000 µADA |
| -862_013_999_832_317 µADA | -169_043_536_586 µADA | 299_830_956_463_414 µADA | |
| 2026 | 6_633_759_911_753_056 µADA | 1_641_487_285_648_244 µADA | 300_000_000_000_000 µADA |
| -762_882_389_851_601 µADA | -34_649_603_529_878 µADA | 265_350_396_470_122 µADA | |
| 2027 | 5_870_877_521_901_455 µADA | 1_606_837_682_118_366 µADA | 300_000_000_000_000 µADA |
| -675_150_915_018_667 µADA | -65_164_899_123_942 µADA | 234_835_100_876_058 µADA | |
| 2028 | 5_195_726_606_882_788 µADA | 1_541_672_782_994_424 µADA | 300_000_000_000_000 µADA |
| -597_508_559_791_520 µADA | -92_170_935_724_689 µADA | 207_829_064_275_311 µADA | |
| 2029 | 4_598_218_047_091_268 µADA | 1_449_501_847_269_735 µADA | 300_000_000_000_000 µADA |
| -528_795_075_415_495 µADA | -116_071_278_116_350 µADA | 183_928_721_883_650 µADA | |
| 2030 | 4_069_422_971_675_773 µADA | 1_333_430_569_153_385 µADA | 300_000_000_000_000 µADA |
| -467_983_641_742_713 µADA | -137_223_081_132_970 µADA | 162_776_918_867_030 µADA | |
| 2031 | 3_601_439_329_933_060 µADA | 1_196_207_488_020_415 µADA | 300_000_000_000_000 µADA |
| -414_165_522_942_301 µADA | -155_942_426_802_678 µADA | 144_057_573_197_322 µADA | |
| 2032 | 3_187_273_806_990_759 µADA | 1_040_265_061_217_737 µADA | 300_000_000_000_000 µADA |
| -366_536_487_803_937 µADA | -172_509_047_720_370 µADA | 127_490_952_279_630 µADA | |
| 2033 | 2_820_737_319_186_822 µADA | 867_756_013_497_367 µADA | 300_000_000_000_000 µADA |
The (rather simple) creation of this table is implemented in 2025-02-24-Treasury-Projection.py.
Of course, we will probably adapt the net change limit in these years. Maybe, we get enough of a bull market that a lot less is needed. Maybe, some larger development projects that are defined well enough are needed that justify taking more from the substance. Maybe, ADA establishes a higher low in the next bear market, so that we are comfortable with less capital stock in the treasury. …
Treasury Withdrawals
During the discussions about CIP-1694 and governance in general, I always thought of treasury withdrawals as specific withdrawals for specific projects where we as dReps will have the possibility to decide if we trust this entity – company, group, DAO, whatever – to perform this task for these ADA.
I was mildly and unpleasantly surprised when the plans for an Intersect budget process were unveiled last summer: https://committees.docs.intersectmbo.org/intersect-budget-committee/a-comprehensive-annual-budget-process-for-decentralized-governance This process is quite the opposite:
- The only on-chain votes are very large buckets with a lot of different projects – some only roughly defined – and the ADA are withdrawn early into the custody of Intersect (or its strange tax haven subsidiary).
- They pinky-swear to “professionally” manage those funds with decisions left to the “committees” which are elected by the Intersect members (not by the ADA holders).
- Who actually executes the projects is only later decided by a “tender” process within Intersect where entities can apply to be chosen by the “committees” and if chosen have to enter a contract with Intersect.
That all still is not at all how I would want a decentralised treasury funding process to look like.
What I would like to see:
- A treasury withdrawal proposes a concrete project to be realised by a concrete entity in a specified amount of time with specified milestones.
- The proposal also names which persons (or entities) are responsible for checking if the milestones are fulfilled, the reported usage of the funds checks out, and the next chunk of ADA can be paid out. A payment for these auditors/administrators is included in the withdrawal.
- dReps can decide for each individual treasury withdrawal governance action if they deem the project worth funding, if they think that the proposer is capable of executing it, and if they trust the proposed auditors/administrators.
- If the auditors decide that a project shall not be continued, the remaining ADA must, of course, be transferred back into the treasury.
This can be implemented in a rather simple Plutus contract potentially reusable for many or all of the treasury-funded projects:
- The address of the proposer, the schedule of the chunks with their earliest pay dates, the keys of the auditors, and the number of auditors needed to pay out a chunk are configured in the datum of the UTxO from the treasury withdrawal to the contract.
- The milestone report and the opinions of the auditors are not relevant for the contract/validator code itself and can be included as transaction metadata.
- As a safe-guard against the auditors disappearing, the contract allows anyone to execute a transaction transferring all remaining ADA back into the treasury after a slot long enough after the planned end of the project.
Should nobody feel able to implement this in time, we can also start with just a k of n multi-sig address of the auditors.
To keep the workload for the dReps manageable, these projects should not be too many and too small. For smaller undertakings, Catalyst – and/or hopefully better alternative funding schemes – remain more appropriate than direct treasury withdrawals. Such funding schemes can themselves then be funded from the treasury as one large project.
Still, the risk in this approach is limited. If a proposer or an auditor turns out to do a visibly bad job, dReps will hopefully never approve a withdrawal to them again. The risk is much bigger if we follow Intersect’s idea of a large bureaucracy as “administrator”.
I will only vote for treasury withdrawals that are sufficiently narrow in scope and that state explicitly which entity is executing which project audited by whom.
“Audited by whom” leaves some room for interpretation. I would prefer a concrete list of persons known in the Cardano community for their expertise and declaring possible conflicts of interest. But if the time is too short and the project is urgent (only very few really are), “audited by Intersect’s Foo Committee” might be okayish for the time being.
But “narrow in scope” is still indispensable. Don’t give me a large blob of everything someone always wanted to do that has something to do with Cardano and I can only say “Yes” to all or “No” to all!
“Budgets”
The net change limit and treasury withdrawals with narrowly specified purposes paid to contracts ensuring oversight by defined auditors as sketched above would – for me – be totally sufficient as a treasury management framework.
But the wisdom of the masses (or maybe rather the powers that be, the stage directors of the constitution process) wrote “one or more budgets” into the constitution (https://ipfs.io/ipfs/bafkreiazhhawe7sjwuthcfgl3mmv2swec7sukvclu3oli7qdyz4uhhuvmy, Article IV and Appendix I 3.) – albeit without defining what a budget should actually look like.
The currently predominant interpretation is that a budget consists of very detailed line items defining (more or less precisely) things that will then be tendered by Intersect’s “committees” – prepared by their bureaucracy which therefore becomes incredibly powerful in the process. The committees may vote on the answers to the tender, but if the bureaucrats tell them “Oh, no, we can’t do a contract with them for this and that obscure reason. The legal department told us that!”, will the committees have the balls to oppose?
When I first heard the idea that there has to be a “budget”, my first conception was more of a high-level budget – just a list of large buckets for different topic areas. This might have to do with my belief that the details should be specified in the paticular treasury withdrawals as sketched above. But I still think that it would be a good idea.
Currently, an unmanageable plethora of details is discussed regarding the proposed budget(s). This is the ideal setup for people getting their favourite pet project in – probably one where they hope to win the tender – if they manage to be loud enough in the right corner of the maze that is the Intersect Discord server. That can’t be it!
I really think that it would be much more valuable if we would just create – starting from the net change limit – a high-level bucket distribution of topic areas that we want to fund from the treasury – “core software maintenance and incident management”, “wallet apps”, “research and development”, “governance services”, “marketing” etc. pp., but do not yet conclusively define all projects that are in or out. Just the maximum and some guardrails: “For incident management, only one team is funded at any given time.”, “Withdrawals need at least three auditors, for more than 1 million ADA at least five.”, “Half of the budget may only be withdrawn after Epoch XXX to prevent everything being already grabbed by the fastest proposers.”, …
In any case:
I will not vote for “budgets” that contain a wild mix of “line items” of varying quality and force me to greenlight all or none of them.
If you cannot realise a change to a more sane process in time, give me one or more minimal budgets with only the absolutely necessary funds to keep the lights on, so that we keep enough of the net change limit open for later budgets that are carefully created.