EIP-0017 - proxy contracts

eip-0017.md

@@ -8,7 +8,7 @@
 
 ## Motivation 
 
-Outsourcing transaction generation to an external service/dApp can be useful or needed in various circumstances. For example, avoiding wallet limitations to generate any transaction on behalf of the user - [Ergo Assembler](https://github.com/anon-real/ergo-assembler) is designed for this purpose. Another example is to scale dApps to be able to fulfill many requests without double-spending or data invalidation - SigmaUSD dApp can use proxy contracts to avoid bank double-spending and ERG/USD oracle data invalidation.
+Outsourcing transaction generation to an external service/dApp can be useful or even needed in various circumstances. For example, avoiding wallet limitations to generate any transaction on behalf of the user - [Ergo Assembler](https://github.com/anon-real/ergo-assembler) is designed for this purpose. Another example is to scale dApps to be able to fulfill many requests without double-spending or data invalidation - SigmaUSD dApp can use proxy contracts to avoid bank double-spending and ERG/USD oracle data invalidation.
 
 
 ## Background
@@ -17,11 +17,15 @@ The idea of proxy contracts came to life with the [Ergo Assembler](https://githu
 During this time, the structure of proxy contracts evolved as some malicious users tried to take advantage of some minor vulnerabilities, mostly in the [SigmaUSD dApp](https://sigmausd.io/#/).
 
 ## The structure
-In the beginning, the sole purpose of proxy contracts was to protect users from losing their funds (not to be cheated) when they outsource their assets to engage with some dApp. While the initial structure succeeded to achieve this, it proved to be not sufficient for the whole dApp infrastructure to work without malicious activities. 
+In the beginning, the sole purpose of proxy contracts was to protect users from losing their funds (not to be cheated) when they outsource their assets to engage with some dApp. While the initial structure succeeded to achieve this, it proved to be not sufficient for the whole dApp infrastructure to work without malicious activities. Some examples of dApp infrastructure violations are as follows:
 
-For example, a malicious whale tried to take advantage of this simple structure by stealing UI fees from SigmaUSD web interface developers for some period of time. This happened because the proxy contracts were simply only trying to protect users from malicious activities, not the dApp infrastructure.
+- A a malicious whale tried to take advantage of this simple structure by stealing UI fees from SigmaUSD web interface developers for some period of time. This happened because the proxy contracts were simply only trying to protect users from malicious activities, not the dApp infrastructure.
 
-The same whale tried to prevent user's requests (minting/redeeming) from being executed by the assemble service by retuning their funds as soon as funds were broadcasted in the network. This happened also because of the same reasons.
+- The same whale tried to prevent user's requests (minting/redeeming) from being executed by the assemble service by retuning their funds as soon as funds were broadcasted in the network. This happened also because of the same reasons.
+
+- Moreover, the whale tried to sell SigUSD/SigRSV tokens to users by imitating the bank box. He succeeded to do that and take 2.25% fee for each request which was supposed to go to the SigRSV holders (2%) and UI devs (0.25%).
+
+The above attacks were possible because proxy contracts were not designed to preserve the integrity of the whole dApp infrastructure but only the user's funds.
 
 Generally, proxy contracts should be designed to:
 - prevent dApp developers or any other attacker from taking advantage of user's funds in any manner
@@ -66,5 +70,5 @@ The contract has three main parts:
 
 Now we will go through some parts of the above contract which are both important and ambiguous at the first glance.
 
-- `(PK("$assemblerNodeAddr") || HEIGHT > $refundHeightThreshold)`: Either dApps's specific node can refund the user (at any time) or some time has to be passed for refunding without any secrets involved. This part prevents malicious users from sending refunds to users, preventing user's request (minting, in this case) from being executed. The same logic can be used to only allow a certain (or multiple) entities to execute requests. This enables dApps to control the order of execution which makes scaling dApps possible as it allows them to control doulbe-spending and other similar problems.
+- `(PK("$assemblerNodeAddr") || HEIGHT > $refundHeightThreshold)`: Either dApps's specific node can refund the user (at any time) or some time has to be passed for refunding without any secrets involved. This part prevents malicious users from sending refunds to users, preventing user's request (minting, in this case) from being executed. The same logic can be used to only allow a certain (or multiple) entities to execute requests. This enables dApps to control the order of execution which makes scaling dApps possible as it allows them to control double-spending and other similar problems.
 - `HEIGHT < $timestampL`: This will result in different address every time the contract is compiled. This is useful from the UI perspective to be able to track user's requests in an address-specific manner.