Proxy Contracts & Timelocks

Defining a Proxy Contract

Normally, contracts on Ethereum are immutable, meaning that they can’t be upgraded once they are deployed. After all, blockchains are generally defined as an “immutable public ledger”, but devs can sidestep these limitations using the proxy contract model. A proxy contract sends (or delegates) all of its functionality to another smart contract, called the implementation contract.

In laymen terms a proxy contract at face value is simply a top layer to the original contract that allows function changes that are normally inaccessible/unchangeable! The common risk assosciated with these contracts usually involve a less than trusted team having access to proxy contracts changing core & dangerous hard-coded functions that could ultimately result in a malicious case of lost user tokens & funds.

Reasons for Proxy Contracts on Pharaoh

Here is a long list of why the internal team has chosen to utilize proxy contracts on Pharaoh Exchange:

• Solidly (ve(3,3) codebase) is a volatile and complex primitive. The list of vulnerabilities that exist in other implementations both on Arbitrum and other chains is long and unfortunately, not addressable because of the initial immutability.
• As noticed, we have a Time Lock that prevents us from upgrading anything without going through the scheduler. (Aside from good security and safe business practice for users, this is also an obvious requirement for many partners (including Beefy Finance) to ensure pools they create for their users are not endangered due to PHARAOH's upgrades).
• For transparency, our Discord has OpenZepplin's defender/sentinel activated so it sends a report to the channel anytime the Time Lock is engaged. With respect to the existing vulnerabilities mentioned , we have shared these with other partners and helped them remediate some of those still resident in their models, but, nevertheless, as security experts— our team constantly is looking for ways to ensure that users funds are SAFE and never at any contract risk. Our information security and trad-fi fintech backgrounds, combined with our years spent in DeFi are core to our team’s admittedly nuanced and obsessive approach to security. We’re proud of that.
• Since everything is behind a proxy Time Lock, there is no way for us to maliciously do anything without it being verifiably on chain for multiple hours before it can be executed. Users can use Forta, OpenZepplin's defender, or other tools to ensure they are properly notified, even if they aren't looking at our Discord notifications.
• We are extremely comfortable with moving towards an immutable model over time, but it is bad practice for Solidly implementations to make the same mistake that was made in the original Fantom Solidly. Andre Cronje had made the project immutable from day 1 and all the vulnerabilities found, that were project breaking, were unable to be remediated, thus decimating the project and putting the user's funds at risk. We deeply care about our users and the last thing we want to experience is a situation where their funds are at risk.
• We have a reputation in the space and are more than happy to do whatever it takes to ensure the ecosystem is comfortable with our decisions.

Core to our team is the motto(taken from Naval Ravikant):
Play long-term games with long-term people.

That is our intention and excitement participating here on Avalanche. We’re in this for the long-term and look forward to building a strong relationship of mutual trust and support.

Timelock Contract

"A great way to view Timelock contracts are like a failsafe for major changes via the Proxy Contracts discussed above. Once a change is pushed to a proxy contract that will then change the underlying core contract, a timelock is set in place where the changes go live for public view a set amount of time before being implemented. This allows full transparency prior to major changes in the codebase for any user to review

In order to instill further confidence during the early stages of the project, we are implementing a timelock mechanism for all necessary proxies. The inclusion of a timelock offers several benefits, as it prevents the proposer from executing any transaction to upgrade or modify the contracts until the designated timelock period has elapsed. This mechanism enhances security and provides reassurance to the users and protocols utilizing the PHARAOH platform.

To ensure transparency and community awareness, any proposed calls to the timelock will be openly shared with the community. This allows for proper notification of any changes prior to their implementation. We utilize the OpenZeppelin Defender platform to automate notifications within our Discord community. The PHARAOH team is committed to regularly providing updates and information to the community. This includes sharing insights into future upgrades, code changes, and upcoming feature implementations. We strive to maintain open communication and keep our community well-informed about the project's development and progress.