Smart Contracts and Cardano budgets

This blog post highlights the growing power of smart contracts in action. It introduces new treasury management tools designed to support the Intersect membership and wider Cardano community—and invites you to explore, give feedback, and get involved.

Introduction

Smart contracts are a valuable innovation of Web3, providing programmable logic to transactions. Such logic is extremely valuable when building transparent and safe mechanisms for managing Cardano’s budget(s).

Smart contracts on Cardano

Cardano’s EUTXO model differs significantly from account-based systems in terms of the architecture of smart contracts. Smart contract scripts are associated with their own addresses on-chain and are executed when UTXOs at the script address are spent.

Cardano has two types of script: native scripts, which are simple and quite limited in expressiveness, and Plutus Core scripts, which are much more expressive. The most significant smart contracts on Cardano are all built with Plutus Core.

Smart contracts allow us to enforce behavior when spending UTXOs programmatically. This ability to add arbitrary logic is extremely useful. We move to can’t be evil instead of relying on don't be evil.

Smart contracts and budgets

Cardano’s treasury funds are collectively owned and managed by ada holders via Cardano’s on-chain government. Delegated representatives (DReps) and the Constitutional Committee must explicitly vote to approve every withdrawal from the Cardano treasury within a budget.

Administrators of Cardano budgets must strive for transparency and accountability when administering treasury funds. Smart contracts are a tool that should be used to enforce transparency and desirable behaviour.

Applying smart contracts to manage treasury funds reduces the need for trusting intermediaries to control funds. Rather, treasury funds can remain at script addresses, only moving when strict conditions are met. This drastically reduces the amount of trust needed to be placed on third parties to act in desirable ways.

Funds managed via smart contracts are transparent. With data being stored on-chain, all actions are observable. Every stakeholder can view and verify funds independently. The advantage is that it allows good administrators to prove their worth while allowing any undesirable behaviour to be noticed and called out.

Furthermore, budget administrators must comply with the Cardano Constitution Article IV Section 2: ‘Development of Cardano Blockchain ecosystem budgets and the administration of such budgets shall utilize, to the extent possible and beneficial, smart contracts and other blockchain-based tools to facilitate decision-making and ensure transparency.’

When withdrawing funds from the treasury, withdrawing funds into smart contracts would benefit budget administrators, Cardano, and its government.

State of tooling

The Treasury Management Tooling Working Group under the Cardano Budget Committee has been focused on the scope and development of treasury management tooling while aiming to maximise the use of smart contracts.

The group has been actively developing tooling proposals in close collaboration with IO engineering, Sundae Labs, and Xerberous, ensuring the entire community is part of this journey.

Sundae Labs has been developing on-chain smart contracts designed for treasury management, SundaeSwap-Finance/treasury contracts, and an accompanying web-based interface for budget administrators, auditors, and vendors to interact with the smart contracts.

Xerberous has been building tooling to create dashboards and analytics tracking budget funds and smart contracts, enhancing the transparency of on-chain data.

Design

The current design thinking aims to

Build smart contract-based tooling to support the management of budgeted treasury funds.
Address the needs of key stakeholders: DReps, Budget Administrators, Budget Vendors, Constitutional Committee, and the Cardano ecosystem.
Provide safe, transparent, and flexible mechanisms for allocating funding to vendor contracts.

The current design splits logic across two types of smart contracts: Treasury Reserve contracts and Vendor contracts.

(Treasury) Reserve contracts act as intermediate holding areas, receiving funds from treasury withdrawal governance actions. The logic in these contracts enforces how funds can be moved from the contract, allowing for flexible allocation to many vendor contracts without knowing all Vendor contract details ahead of time. This contract does not support staking or governance participation. Funds can only be sent to approved destinations: Vendor contracts, decentralized exchanges (for stablecoin swaps), other Treasury contracts, or returned to the treasury. This means funds cannot just be transferred to arbitrary addresses. Each reserve contract is controlled by a multi-signature (M-of-N) scheme.

Vendor contracts receive funds from a Treasury Reserve contract and represent legal agreements with individual vendors to deliver a proposal. These contracts transparently manage allocated funds, splitting UTXOs into milestone-based vendor payments. Vendors can withdraw payments within a defined timeline. Payments can be paused if a delivery has not been achieved. The contract and milestones can be completely reorganized or cancelled with the vendor's agreement, with funds returned to the Treasury Reserve contract.

There are two primary stakeholders within this proposed system. The first is the M-of-N signatories who can authorize payments from the Reserve contract, deploy vendor contracts with agreement from Vendors, and pause payments on Vendor contracts. The design allocates one of these groups per Reserve contract. It is an open question who should be included within these groups. Splitting this group by expertise makes sense with multiple Reserve contracts, with third-party auditors and administrators included.

Vendors are the other stakeholder group. Their wallet identifies them, and they can interact with associated vendor contracts. They are required to agree to initiate contract changes such as reorganizations or cancellations.

Off-chain design

Two separate off-chain interfaces are proposed.

An admin/management dashboard: This web interface allows the Oversight and Vendors to interact easily with the on-chain contracts, read on-chain data, and build transactions to enable writing.

A second off-chain application is proposed to independently read the on-chain data and generate dashboard displays for transparency.

Strengths and drawbacks of the design

Strengths

The system only allows funds to move through smart contracts; no custodian is used or needed
The system allows for funding via ada and stablecoins
The system provides for third-party auditors to control on-chain actions directly
The system allows many different individuals and entities to be in control of oversight keys, with multi-authorizations required
Transparency – All funds and contracts can be observed on-chain

Drawbacks

Places a lot of control on oversight groups, risking centralization of power – partly mitigated by splitting between slices
Choosing oversight key-holders will be a challenge.

Stay informed and engaged

The current draft design is still a work in progress, with many important open questions to be answered:

Do oversight key holders have too much control?
Who should/could be a part of the oversight key holders?
What M-of-N thresholds should there be for oversight actions?
What criteria should be used to move funds from a reserve contract back to the Cardano Treasury?

The Treasury Management working group values and eagerly awaits all feedback and designs for treasury management tooling from the Cardano community. Your input will shape the future of our ecosystem.

Please engage via the Intersect Discord under the Budget Committee