This SIP introduces minimal modifications to the system that will only allow users to interact with SNX, as well as synths, via their proxies, and stop allowing transfers via their implementations.
\nSince our proxies use call instead of delegatecall, the state of our tokens such as the balances mapping does not reside in the proxies, but in contracts specifically designed to hold token states. Whenever a token is upgraded, the previous implementation is discarded, and a new one is connected to the proxy, as well as the token state contract. This results in the fact that two different token addresses represent the same token. We always recommend people to use the proxy address, which never changes, but nothing stops users from interacting with the active implementation. Doing so is identical to interacting via the proxy.
The ability to transfers our tokens via two different entry points can cause accounting issues in smart contracts that are designed to track state for tokens via a single entry point (by using custom internal balances accounting instead of using balanceOf calls on the tokens). By restricting transfers to the proxy only, we mitigate such possible accounting issues in protocols that use Synthetix tokens.
Balancer forum post describing their medium severity issue: https://forum.balancer.fi/t/medium-severity-bug-found/3161
\nERC20 Transfer (transfer, transferFrom) on all ERC20 tokens, including SNX and all synths, will be modified to only allow interactions via their corresponding proxies.
In order to allow Synthetix internal contracts to still call those functions on implementations (to avoid having to upgrade them all, some of which are legacy), the specific internal contracts will be whitelisted by their AddressResolver name (e.g. \"SynthetixBridgeToOptimism\").
Copyright and related rights waived via CC0.
"}},"pageContext":{"id":"368adea9-3b55-55e5-b288-3ea02b9437df","frontmatter__sip":238,"__params":{"frontmatter__sip":"238"}}},"staticQueryHashes":[]}