As promised, an update from our mainnet smart contract demonstration. As introduced yesterday in a brief blog post, today we delve into the details of what is happening. 

A treasure reserve contract, one of two types of smart contracts designed to hold treasury funds initially, has been deployed on the mainnet and funded with 3500 ada (note: this demonstration has been funded from our own wallet). 

This treasury reserve contract will be established to demonstrate several key features of the contracts and tooling. 

Smart contracts have oversight permissions, controls managed by keys that Intersect can assign to others, where practically possible, to ensure Intersect, as an administrator, is acting correctly, fairly, and in the best interest of the community. Some of these permissions are also designed to stop Intersect from acting unilaterally. All of these permissions, when used, are recorded and auditable on-chain. Shortly, we will be posting a dedicated blog that explains these in detail.

What has happened so far

For the purpose of this demonstration, this treasury reserve smart contract has been with two different permission thresholds:

• for disperse permission; two of three key signatures
• for all other permissions, one of three key signatures

The decision was made to differentiate the disperse permission from the other; this is because it is the most critical function. Disperse allows the oversight keys to send ada from the reserve contract to any other address, and thus should be held to the strictest of permissions.

You can see and verify the Treasury Reserve Contract at the script address:

Addr1x88kv96gv4684srqdr4zfwvhnz3jvtjn7628nt70efjvcl70vct5set50tqxq682yjue0x9rych98a550xhuljnye3lsjdxkrp

To get to this point, the following has been undertaken:

1. Published the registry transaction: 6bdb44d4936925475c56bb9a010d68fb29f6a26ce248d7840a386d5954c98c50

The purpose of the registration transaction is to publish on-chain the parameters of the scripts (oversight permissions, expiry), and crucially, their script hashes (which can be seen in UTxO datum).

Additionally, the treasury management system enforces that specific contextual metadata is attached to this transaction. This metadata shares all contract parameters in plain text. This information is free for all to read. See via Cardanoscan.

Check the metadata of this transaction to confirm the permissions and other parameters of the smart contract.

2. Published both the treasury reserve script and vendor script bytes

• 482c80b07fa30549204a306ff021225b05291503c821a210950d79bbe5266d2a
• c609fcec0d9649321520ce1eb7754280cf91bd4032492a978f5e8a60498e7d5b

Within this step, the bytes of the treasury script and vendor scripts are stored within a reference UTxO. This ensures that subsequent transactions don’t have to upload the bytes each time; instead, they can reference script UTxOs that have been deployed here.

3. Fund the treasury reserve contract/ withdraw the funds from the treasury contract's stake account: a88413b4c998e832d6a69ec12610af68c48e65517aebf94f2dfbbfaa4974c1ec

For this step, we closely mimicked the real behaviour, attempting to withdraw funds from the script’s rewards account. For this test, we withdraw 0 ADA from the rewards address, while standing the payment credential at 3500 ADA.

Again, for all critical actions, the treasury management system enforces the attachment of contextual metadata to these transactions. We can review this via a block explorer. See via Cardanoscan.

Crucially, the metadata allows us to earmark UTxOs now held at the treasury reserve contract for different purposes. This is very useful, as it allows observers to follow the flow of funds. For this example, we created three UTxOs at the reserve contract:

• a88413b4c998e832d6a69ec12610af68c48e65517aebf94f2dfbbfaa4974c1ec#0 with 500 ada – marked for dispersion.
• a88413b4c998e832d6a69ec12610af68c48e65517aebf94f2dfbbfaa4974c1ec#1 with 500 ada – marked for funding a project.
• a88413b4c998e832d6a69ec12610af68c48e65517aebf94f2dfbbfaa4974c1ec#2 with 2500 ada – marked to be left for a treasury donation.

In summary, following the above, we now have a smart contract on the mainnet, with some funds available to test specific smart contract permissions and associated multi-signatures. We aim to highlight the added contextual metadata associated with each action to promote transparency.

Permissions demonstration

Now that we have a treasury reserve contract and some funds, we can demonstrate how the funds can move from the treasury contract.

First of all, we are going to test the strictest action, disperse. This allows us to move funds outside of a smart contract to an arbitrary address. In a real-world scenario, this is only permissible under specific conditions, such as a smart contract upgrade, stablecoin, or fiat currency conversions. 

In practice, strict metadata will always be attached to these transactions to justify this potentially dangerous action. But for this test, we have not attached such contextual data.

You can verify a disperse action of 250 ada here:  

• 31c2df71553c3c395fe3ae1ab0eb6e57aac28a0f5436ed413c3c8d2139c03a6d

The key details of this transaction that should be verified:

• This transaction correctly required two of the three signatures in order to be enacted.

• Inputs
  • the UTxO earmarked for disperse
  • an orchestrator wallet UTxO (to pay for the transaction fee)
• Outputs
  • 250 ada exactly is dispersed and goes to an address
  • 250 ada is correctly returned back to the script
  • a UTXO used for the fee is returned

What next?

Later this week, in the last blog of this mini-series, we will demonstrate the other permissions and actions associated with this smart contract.

Expect this to include funding a vendor contract, the second type of smart contract for handling treasury funds, as well as the permutations of pausing, resuming, and withdrawing payments from a smart contract. 

To wrap it all up, some of the remaining funds will be returned to the treasury following the expiry of this particular smart contract.

Why this matters for Cardano

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. 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.

These public demonstrations offer the community a chance to witness firsthand how treasury funds will be securely and transparently managed on-chain. This transparency, coupled with a short feedback cycle, will ensure that Intersect can confirm the final configuration, setup, and parameters for the upcoming treasury withdrawal governance actions, following the approval of our consolidated Budget Info Action, instilling confidence in the project's governance. 

Stay informed

Follow this testing over the coming days and look out for updates from the official @Intersectmbo, @Ryun1_, and @SundaeSwap. We’ll point out when certain types of smart contracts are created and when specific functionality is used on-chain. 

Expect one more blog in this mini-series to wrap things up and conclude our mainnet demonstration.