In a governance system, the TimelockController contract is in charge of introducing a delay between a proposal and its execution. It is a powerful tool for enabling secure and controlled transaction scheduling in the blockchain space. Protocols that have decentralized governance implement timelocks into their contract functions to prevent contract admins/owners from maliciously making contract changes without prior notice. Approved proposals also use a timelock so that users have sufficient time to prepare for contract changes.

The TimelockController is usually paired with role-based access controls (RBAC) such that only certain types of users may invoke specific functions within the contract. An AccessControl contract allows the specification and CRUD of one or more roles.

OpenZeppelin has created the canonical timelock functionality for Solidity and EVM applications. We aim to do the same for Soroban applications. Not that we cannot simply just migrate the

The main functions of the Soroban timelock contract are to enable the scheduling and execution of one or more transactions, specify a minimum time span (t_delay) between the initial scheduling (t_schedule) and the execution of the function (t_exeuction), as well as set the roles of proposer, executor, canceller. t_execution - t_schedule >= t_delay

It's important to note here that we cannot simply translate the Solidity OpenZeppelin timelock contracts into Rust/Soroban. Because Soroban has a different set of logic governing the maximum size of a contract, we have found in our research and development that many complex functions will fail, as maximum contract sizes are limited and external contract calls look to be expensive relative to how things operate for EVM execution.

Once we have created this timelock contract, we will work with the Stellar foundation to help spread awareness and get adoption from developers so that this can be a core contract build block going forward.

1. Contract design and researrch
   1. Understand Soroban resource limits and adjust contract design
   2. Deliver tech design doc
   3. 1 week (5/24)
2. Contracts:
   1. Deliver Soroban role based access control and timelock contracts with unit test coverage > 90%
   2. 4 weeks (6/21)
3. Validation on Testnet and Documentation
   1. Deliver documentation on how to utilize the timelock and RBAC contracts with examples
   2. Use a demo application that integrates the timelock functionality and show a successfully delayed execution and a failed transaction due to not meeting the minimum time delay in testnet
   3. 1 week (6/28)

In addition to the contracts and documentation we aim to deliver as part of this activation award, future roadmap for Timelock and RBAC can include 

1. Audit the RBAC and timelock contracts and address any discovered risks.
2. Spread understanding about how to adapt to the unique constraints of Soroban for existing Solidity developers
3. Dashboard to list scheduled operations for a given contract.  This dashboard could show the contract address, function name, remaining time until it can be executed, and transaction parameters. This would improve the transparency of contract calls.
4. Website for the user to schedule and execute the transaction via UI.  This can reduce the chance that the admin inputs incorrect parameters for the roles-based permission changes.