How the Oversight Committee Works
Guide Overview
The Oversight Committee plays a critical role in ensuring transparency, accountability, and constitutional compliance across all smart‑contracted funding flows.
This page walks you through the key assurance tasks the Oversight Committee performs, the end‑to‑end process for smart‑contracted projects, and the considerations that shape how oversight works.
Oversight Committee Assurance Tasks
The following page outlines how the assurance tasks will be undertaken by the OC.
1. Review and Approve Project Specific Smart Contract (PSSC) Funding:
The OC shall review and approve any funding actions of PSSCs from Treasury Reserve Smart Contracts (TRSC)s, as requested by Intersect from time to time.
For funding actions, the OC shall specifically check the consistency of the following data points:
The vendor name or organization in the funding action matches a previously approved on-chain governance action.
In exceptional cases, if there has been a change (e.g., a corporate name change), the OC may determine that the team behind the previous action and the current vendor are the same, and consider it a valid match.
The Quorum required is 2 out of 5 OC members.
During the early phases of the budget cycle, the expected occurrence is most common, when funds are approved through on-chain governance and processed by Intersect’s Administration. After that, it may occur occasionally based on disbursements or proposals not covered by the current Intersect budget.
2. Review and Approve TRSC Disbursements:
The OC shall review and approve any disbursements from the TRSC to a destination outside of the smart contract framework, as requested by Intersect from time to time. For disbursement actions, the OC shall specifically check the consistency of the following data points:
The wallet/destination address matches the provided hashed rationale.
The hashed rationale is signed by the Executive Director at Intersect and the vendor where relevant (example: Vendor A requesting stablecoins).
The Quorum required is 3 out of 5 OC members.
The expected occurrence is infrequent and on a case-by-case basis. Example use cases are to leverage stablecoins and/or upgrading the smart contract framework if a fix or feature is needed.
3. Review and Approve PSSC Modifications:
The OC shall review and approve any PSSC modifications (e.g. change in milestone, delivery date, payment schedule), as requested by Intersect from time to time. For modification actions, the OC shall specifically check the consistency of the following data points:
Confirm the vendor’s receiving address is valid and controlled by the vendor or contracting party (with supporting explanation).
Note:
i) The value of a vendor smart contract cannot be increased after creation
ii) Any changes must also be approved on-chain by the vendor
The Quorum required is 2 out of 5 members are required to sign.
The expected occurrence is infrequent and on a case-by-case basis.
4. Review and Approve Unspent Transaction Output (UTXO) Reorganization:
The OC shall review and approve any reorganize UTXO actions for TRSCs or PSSCs, as requested by Intersect from time to time. For reorganize UTXO actions, the OC shall specifically check the consistency of the following data points:
Check that the UTXO details are correct and properly formatted
Confirm that metadata is included
The Quorum required is 3 out of 5 OC members.
The expected occurrence is infrequent and on a case by case basis.
5. End-to-end process
Within the context of the budget process to date, the following flowchart illustrates an indicative, high-level end-to-end process for smart contracting, administration, and the oversight committee.

Bulleted explanation
Treasury Withdrawal governance action outlines several proposals to receive funding. Treasury Contracts and oversight committee(s) are created with permissions to control them.
Funds are distributed into these holding Treasury Contracts based on the success of the Treasury Withdrawal governance action.
Written legal contracts are pursued and agreed upon with prospective vendors off-chain (constitutionally, these are required)
On-chain Vendor Contracts are created once the governance action passes, and a written legal contract is signed.
Vendor commences delivery as per the schedule in the contract
As per the schedule, the vendor provides attestation of milestone completion to Intersect and on-chain.
Intersect undertakes its role as the administrator of the oversight committee, and as permissioned, provides necessary checks and balances on the administrator.
Once a milestone matures and reaches its due date, the vendor can withdraw the funds associated with that milestone. They may specify where the funds go using their credential provided within the legal contract.
Narrative explanation
Following or during the on-chain Treasury Withdrawal governance action (1), a number of Treasury Contracts will be defined (2). These will outline the budgets or funding themes requested within the original on-chain action. This allows the partitioning of smart contract funds, assisting transparency on-chain.
Partitioning the Treasury Withdrawal has several benefits; it enhances community observability by breaking funds down into more manageable and meaningful groupings, allowing for different sets or granularities of oversight committee permissions between partitions, and improving security by not having all of the total budget in one transaction or account.
The treasury funds stay here until Vendor Contracts are agreed upon. At this point, the funds are held in the smart contract and cannot be delegated or staked, which satisfies provisions within the constitution.
Required by many vendors and to satisfy constitutional requirements, legal contracts (3) will be created between the CDH and the vendors whose proposals have been approved by DReps in the treasury withdrawal governance action.
Following the signing of the written legal contracts, Intersect, as the administrator, will create a back-to-back smart Vendor Contract for individual projects (4).
At this stage, the vendor has a legally written contract that contains constitutional requirements, such as dispute resolution, and a tailored Vendor Contract for the specific project. The vendor now delivers according to the agreed-upon project schedule (5).
Defined by the milestones within a Vendor Contract, the vendor submits and attests milestone acceptance to the community and Intersect (6). Tooling will be configured to link these attestations to the on-chain milestone.
As per the permissions outlined in the Treasury Contract, which is associated with the Vendor Contract, the oversight committee will undertake oversight capabilities for Intersect, the previously described Fund, Modify, and Disperse (7). This assures that in these circumstances, Intersect cannot act unilaterally. As needed, once the ‘M-of-N’ permissions associated with these actions are met, they are enacted and recorded transparently on-chain.
Once a milestone date has matured or reached its due date, the vendor can withdraw the specified milestone amount (8). The process ‘fails open’ to protect vendors should the oversight committee fail in any way. The vendor withdrawal is captured on-chain, so it becomes auditable.
Timeouts are configured so that, at the end of a contract, any unclaimed or locked funds ultimately return to the Cardano Treasury, allowing on-chain governance to decide their use again.
The Treasury Contract and permissions, the Vendor Contracts and permissions, milestones, and vendor payment withdrawals are all captured, transparent, visible, and auditable on the chain.
Considerations
Given the novel decentralized approach to oversight and the constitutional requirement for traditional written contracts, several considerations must be understood.
Most importantly, it should be understood that these smart contracts effectively hold money in a transparent on-chain ‘escrow.’ When held in these smart contracts, the treasury funds are never initially in an Intersect account or wallet. These smart contracts lock the ability to stake and delegate.
Vendors must be aware of how oversight works before signing any contract and how it may affect disbursement or modification. They are consulted before the oversight committee agrees on their particular partition/treasury contract and/or vendor contract.
Vendors have representation in smart contracts. Not all smart contract actions can be unilaterally undertaken against a vendor. There needs to be a mutual agreement with vendors before smart contracts can be agreed upon, funded, and modified. Some specific actions require a vendor signature via a key before they can be enacted.
Each escrow environment or treasury contract may have a unique oversight committee makeup and unique permissions. This allows for a level of future-proofing. These smart contracts enable more unique use cases as needed, which can be legally permitted over time.
Further Information
The smart contract framework is evolving. Vendors can contribute ideas or feature requests here
Smart contracts were developed by Sundae Labs with support from Input Output Engineering and Intersect.

Navigate to Your Support Center
Explore the Vendor, Assurer, and Community Support Centers to begin your journey.
Key Areas in this space
Last updated



