Why Proxy Contracts?

Reason for Proxy Contracts

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 Ramses 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.
Our current proxy + TimeLock approach is temporary and, in coordination with experienced counsel and strategy from great partners and advisors including Dudesahn from Yearn Finance, our plan is to achieve full decentralization. This plan is outlined in our documentation here:
One highlight of our decentralization design is that of the Emergency Council. This council will comprise top protocol representatives, trusted members, and ideally someone from Offchain Labs, so the overall Arbitrum ecosystem is considered in major decisions. This emergency council will be the sole entity empowered to make any changes to the contracts/proxies/timelocks, thus giving upgradability (similar to Arbitrum One's current beta design), while still keeping unilateral control out of the hands of the Ramses team.
With respect to the existing vulnerabilities mentioned Fixed Solidly Vulnerabilities, 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 Arbitrum. We’re in this for the long-term and look forward to building a strong relationship of mutual trust and support.

Last updated 2 years ago

Why Proxy Contracts?

Reason for Proxy Contracts

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 Ramses 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.
Our current proxy + TimeLock approach is temporary and, in coordination with experienced counsel and strategy from great partners and advisors including Dudesahn from Yearn Finance, our plan is to achieve full decentralization. This plan is outlined in our documentation here:
One highlight of our decentralization design is that of the Emergency Council. This council will comprise top protocol representatives, trusted members, and ideally someone from Offchain Labs, so the overall Arbitrum ecosystem is considered in major decisions. This emergency council will be the sole entity empowered to make any changes to the contracts/proxies/timelocks, thus giving upgradability (similar to Arbitrum One's current beta design), while still keeping unilateral control out of the hands of the Ramses team.
With respect to the existing vulnerabilities mentioned Fixed Solidly Vulnerabilities, 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 Arbitrum. We’re in this for the long-term and look forward to building a strong relationship of mutual trust and support.

Last updated 2 years ago