The last update on our mainnet smart contract demonstration. As introduced on Monday in a brief blog post, followed up yesterday with additional details here, we detail the final phases of this demonstration today.  

The mainnet demonstration is part of the final preparations as we move closer to submitting Treasury Withdrawal governance actions. 

Recap so far

Our initial blog outlined the purpose of this demonstration, how it will work, and why this was important to Cardano Governance. Yesterday, we went through the setup of a treasury reserve contract and some of its key features.

What has happened today

A vendor contract has been funded on the mainnet, and we were able to withdraw the funds for completed milestones. 

Funding

This is evident in the following funding transaction:

273673a255a844563b73883fe9181891185fdb7b0fefbcb7915886893062ed74

Within this transaction, we allocate the 500 ada UTXO earmarked from the registration transaction to the vendor contract address;

addr1xxs825s7y67fulqqqzr5k5p0fxdcczrdd2rnd39x4kqscs4qw4fpuf4une7qqqy8fdgz7jvm3syx6658xmz2dtvpp3pq9vpd3m

We can see that the vendor contract received the exact amount of 500 ada.

We can see within the 500 ada UTXO datum that data is stored about the vendor (keyhash bytes 299....83d3) as well as UNIX timestamps and lovelace values to represent all the milestones.

The metadata associated with this funding transaction is crucial, as it shows all the details about the vendor contract, including its milestones, acceptance criteria, and withdrawal timings. This metadata (and datum) records that we have five milestones of 100 ada, each with its own maturity date.

See metadata snippet;

The datum values and the rich contextual metadata provide any observer, or downstream tooling with transparent data on where and why funds are moving.

Vendor Withdrawal

By setting the first milestone to mature ~20 minutes after vendor contract creation, allows us to rapidly test withdrawing ada for completed milestones.

Withdrawing ada for a completed milestone:

d767741f1b10bda086ebe630769c60e4957c7bfccec7cfd8f309fc4380b3c67e

We can see that Vendor (address; addr1qy5ew.....4xycm) was able to withdraw exactly 100 ada from the vendor contract independently (minus a small amount for transaction fees). And that the 400 ada for the remaining milestones is returned to the contract.

The datum that remains at the vendor script address now shows that there are only four milestones left.

Vendor milestone payments work in a fail-open system, where once the milestone maturity date expires, the vendor is able to withdraw. This prompts the oversight committee to actively intervene and pause a milestone withdrawal when a vendor fails to deliver on a milestone.

Vendor Pause

After withdrawing milestone one (labelled m0). We used one oversight committee key to pause milestones three, four, and five. This mimics a contract, where a vendor has indicated that they cannot currently deliver these milestones.

This can be seen via:

097fc072e9eeb380888c1c5c6fae7b779a7f3b623fb462c7d0ede727cf637cdf

Pausing a milestone prevents the vendor from being able to withdraw it at the time of maturation. This is hopefully not a function that is required often in real scenarios, and when it is, it should be well justified.

It is key to note here that no ada is leaving the contract; instead, just the values within the datum are being updated to indicate the paused milestones.

The metadata gives the pauser the ability to provide rationale and agreed-upon resolutions. Again, the contextual metadata aims to provide explicit context for on-chain actions, thereby promoting transparency.

Remaining Milestones

The remaining milestones, three, four, and five, will soon reach their milestone maturity date. We will then resume milestones three and four, demonstrating that expired milestones can be resumed. This scenario mimics a potential situation where milestone deliveries were delayed but have now been met.

Using our vendor key in this demonstration, we will withdraw milestones three and four, showing that a vendor can withdraw expired milestones, after a pause.

What will happen to milestone five and the remaining funds in the reserve contract?

Community Treasury Sweep!

A key part of this smart contract framework is to ensure, in any eventuality, that the community can sweep any unused or unclaimed funds back to the treasury after a sufficient contractual timeout has passed. This protects funds in the smart contract in the event that administrators, oversight committees, or vendors lose their keys or fail to collect funds.

Sweeps funds from vendor contracts and moves them to the treasury reserve contract once the vendor contract expires. Sweeps from the treasury reserve contract are sent directly back to the Cardano treasury and can be executed by anyone once the contract reaches its expiration date.

Although we have not explicitly instructed you on how to do this, it is possible with this mainnet example. Milestone 5 will be left unclaimed, and the contract timeout will be allowed to pass knowingly. Furthermore, the remaining ada in the Treasury Reserve contract (addr1x88kv….dxkrp) will be able to be swept to the treasury once the contract expires.

• Treasury Reserve Contract Expiration:  2025-06-19 20:00:00 (UTC)
• Vendor Contract Expiration:  2025-06-20 20:00:00 (UTC)

Challenge

Who will be the first to devise a method for transferring funds back to the treasury and have their name recorded immutably on-chain, in the first-ever Cardano mainnet smart contract? The challenge starts now!

Once expiration has been reached, you will need to build transactions that spend the UTxOs at the script addresses. For the reserve contract, the ada must be sent directly as a treasury donation. Hints for this can be seen via the Treasury Management CLI. This will still be quite hard.

Hint:  bun run ./cli/cli.ts 

Why This Matters for Cardano Governance

These public demonstrations are not just the culmination of our testing, but also a means for the community to be fully informed and included in the process.

They provide a way for the community to see firsthand how treasury funds will be securely and transparently managed on-chain. Following this and a short feedback cycle, Intersect will be in a position to confirm the final configuration, setup, and parameters for the treasury withdrawal governance actions. 

Stay informed and engaged

This concludes our mini-series on smart contract demonstrations on the mainnet. As details are confirmed, more blogs, explanations, and artifacts will be released regarding smart contracts and their use in our role as administrators. Stay tuned.