Contracts Timelock

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

Timelock contract on Etherscan : 0xca8678d2d273b1913148402aed2E99b085ea3F02

Definitions

getDelay

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.

MINIMUM_DELAY

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.

MAXIMUM_DELAY

Similar to MINIMUM_DELAY, this is an immutable value which represents the longest Delay available for the Timelock.

GRACE_PERIOD

Once the Timelock Delay has passed, this is the amount of time which may elapse in which smart contracts may be changed.

getAdmin

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.

getPendingAdmin

If Admin changes the Admin address, this function displays the pending Admin subject to the same Timelock delay as above.