ParaSpace fully believes in the importance of trustless, permissionless, and ultimately immutable transactions as the future of commerce. To that end we have invested heavily in External Audits to ensure our code performs as intended and keeps the protocol's users' assets safe.
As a fast-growing protocol with important ongoing feature development, however, we have implemented our protocol using upgradeable contracts. This means that the protocol may change certain smart contracts in order to build additional features and address any potential security fixes as they arise.
We nonetheless want to ensure ParaSpace users we will not change key aspects of the code without forewarning, and we have adopted a Timelock contract which sets a minimum time for which any changes must wait until implemented.
Users may themselves see there is a built-in delay for any contract changes from launching to the ParaSpace protocol. We will likewise announce important changes via our ParaSpace Twitter account and Discord server to ensure users have adequate time to respond to any and all changes in the protocol's smart contracts.
Smart contract delay implementation displayed in seconds. This figure tells you the minimum amount of time which must pass before any code changes to the affected smart contracts may be deployed.
While getDelay may be lengthened or shortened by the Timelock Admin, the MINIMUM_DELAY represents an immutable bare minimum for the smart contract Timelock delay.
Similar to MINIMUM_DELAY, this is an immutable value which represents the longest Delay available for the Timelock.
Once the Timelock Delay has passed, this is the amount of time which may elapse in which smart contracts may be changed.
This call returns the current admin for the Timelock contract. Unless specified otherwise this will always be a multisig contract wallet to maximize safety and resistance to compromises.
If Admin changes the Admin address, this function displays the pending Admin subject to the same Timelock delay as above.