Add EIP-6228: Extreme EIP-20 (meta-transaction token MTT) #6228

SamPorter1984 · 2022-12-28T06:37:29Z

This standard proposes a solution in which meta-transaction fees are deducted directly from the user' token transfer amount, no liquidity for keeper incentives required.

eth-bot · 2022-12-28T06:38:18Z

Hi! I'm a bot, and I wanted to automerge your PR, but couldn't because of the following issue(s):

(pass) eip-3561.md

classification
`updateEIP`

passed!

(fail) eip-6228.md

classification
`newEIPFile`

File with name EIPS/eip-6228.md is new and new files must be reviewed
This PR requires review from one of [@axic, @SamWilsn, @Pandapip1]

(pass) assets/eip-3561/README.md

classification
`ambiguous`

file assets/eip-3561/README.md is associated with EIP 3561; because there are also changes being made to EIPS/eip-3561.md all changes to corresponding assets are also allowed

(pass) assets/eip-3561/TrustMinimizedProxy.js

classification
`ambiguous`

file assets/eip-3561/TrustMinimizedProxy.js is associated with EIP 3561; because there are also changes being made to EIPS/eip-3561.md all changes to corresponding assets are also allowed

(pass) assets/eip-3561/contracts/MockLogic.sol

classification
`ambiguous`

file assets/eip-3561/contracts/MockLogic.sol is associated with EIP 3561; because there are also changes being made to EIPS/eip-3561.md all changes to corresponding assets are also allowed

(pass) assets/eip-3561/contracts/TrustMinimizedProxy.sol

classification
`ambiguous`

file assets/eip-3561/contracts/TrustMinimizedProxy.sol is associated with EIP 3561; because there are also changes being made to EIPS/eip-3561.md all changes to corresponding assets are also allowed

(pass) assets/eip-3561/fixtures.js

classification
`ambiguous`

file assets/eip-3561/fixtures.js is associated with EIP 3561; because there are also changes being made to EIPS/eip-3561.md all changes to corresponding assets are also allowed

Pandapip1 · 2023-01-04T22:21:29Z

EIPS/eip-3561.md

+## Test Cases
+
+[Unit tests](../assets/eip-3561/).
+


Please make these changes in a separate PR.

SamWilsn · 2023-02-07T15:33:27Z

EIPS/eip-6228.md

+title: Extreme ЕRС-20
+description: meta-transaction token (MTT)


These are both way too vague. You need to give readers some kind of idea about what your proposal is about.

SamWilsn · 2023-02-07T15:34:21Z

EIPS/eip-6228.md

+
+## Abstract
+
+This standard proposes a solution in which meta-transaction fees are deducted directly from the user' token transfer amount, no liquidity for keeper incentives required.


Suggested change

This standard proposes a solution in which meta-transaction fees are deducted directly from the user' token transfer amount, no liquidity for keeper incentives required.

This standard proposes a solution in which meta-transaction fees are deducted directly from the user's token transfer amount, no liquidity for keeper incentives required.

SamWilsn · 2023-02-07T15:34:55Z

EIPS/eip-6228.md

+This EIP is based on these assumptions:
+
+- That meta-transaction signatures need to be public in order to speed up blockchain adoption. The EIP assumes that token dApps will feature a public pool of signatures similar to Coinbase or Etherscan, which will resemble regular Ethereum transactions but with reduced user friction.
+- Meta-transactions must become standard procedure when interacting with smart contracts.
+- Gas efficiency is in no way less important when it comes to optimistic and zero knowledge roll-ups. If anything, lower network fees enable more automation, which is about to become essential in such a hyper-competitive industry.
+- Full automation can easily be too costly for project funding. Therefore, meta-transactions fees should be deducted directly from the transfer amount.
+
+An example:
+Alice has never had a wallet before but is eligible for an airdrop on Arbitrum. All she needs to do is install a wallet, sign the data, and then she has airdrop tokens minus the keeper fee. She does not have to make any transactions or possess any ETH. She is not limited in any way more than Bob, who is transacting on his own. Alice can vote, stake, claim rewards, trade on Uniswap. In fact, she can do more than Bob, such as subscribing to staking rewards to get them automatically every month, a part of these rewards then automatically sent to pay her bills and support her favorite content creators.


This doesn't belong in the abstract. The abstract should be a terse technical summary of the EIP.

SamWilsn · 2023-02-07T15:37:35Z

EIPS/eip-6228.md

+- All existing solutions rely on funding/supporting a relayer/keeper network, which makes innovation more dependent on external funding.
+
+## Specification
+


You should try to use the MUST/SHOULD/etc. terms and include the blurb from eip-template.md.

SamWilsn · 2023-02-07T15:39:00Z

EIPS/eip-6228.md

+
+## Specification
+
+Signatories can create executable signatures for transactions of any kind. As long as signatory `address(this)` token balance or `returnToken`(token returned after after execution) balance is higher than keeper fee of a transaction at hand, and as long as remaining value after keeper fee transaction is above `minOut`, it is executable.


While I'm generally ok with jumping straight into technical content, reading EIP-20 and the text of this proposal up to this point doesn't give enough background for me to understand all the terms you're using. Are these terms/patterns common in the meta-transaction world? I'd really like to see some definitions and background information included if possible.

SamWilsn · 2023-02-07T15:45:40Z

EIPS/eip-6228.md

+        uint initGasLeft = gasleft();// gas comes first
+        uint gasPrice;
+        assembly {
+            gasPrice := gasprice()
+        }
+        require(!users[reqt.signer].forbidAll, 'forbid all is active');
+        _verifySig(reqt);
+        // check if allowed to use this signature
+        require(block.number > users[reqt.signer].indexLastClaims[reqt.index] + reqt.interval, 'sig cant be valid yet');
+        require(users[reqt.signer].forbiddenSaltsBitMap[reqt.salt / 256] & (1 << reqt.salt % 256) == 0, 'forbidden salt');
+        require(reqt.interval >= 86400);// in seconds, this is to avoid griefing
+        // record state change if any
+        if (reqt.interval > 0) {
+            users[reqt.signer].indexLastClaims[reqt.index] = block.number; // its a subscription, track last execution time
+        } else {
+            _forbidSalt(reqt.signer, reqt.salt);// it was a one time transaction, forbid this salt
+        }
+        // call
+        // if data is 0, subtract keeper reward from user balance here
+        // otherwise data should return amount which is then being split between the user and the keeper
+        bytes memory data;
+        bool success;
+        if (reqt.needsHelper) {
+            (success, data) = I(_ab.helper).handle{value: msg.value}(reqt);
+            require(success == true, 'helper failed');
+        } else {
+            (success, data) = reqt.callee.call{value: msg.value}(abi.encodeWithSelector(reqt.selector, reqt.callData));
+            require(success == true, 'direct call failed');
+        }
+        // take fee and complete
+        uint amount; // compute amount from data bytes
+        assembly {
+            amount := mload(add(data, 0x20))
+        }
+        uint approxGas = (initGasLeft - gasleft() /*+ 21000 */) * gasPrice;
+        uint keeperReward = _calculateAmountInNativeToken(reqt.returnToken, approxGas + reqt.tip);
+        require(amount - keeperReward >= reqt.minOut);
+        if (reqt.returnToken == address(this)) {
+            users[msg.sender].balance += keeperReward;
+            users[reqt.signer].balance += amount - keeperReward;
+        } else {
+            if (reqt.returnToken == address(0)) {
+                (success, data) = payable(msg.sender).call{value: keeperReward}('');
+                require(success);
+                (success, data) = payable(reqt.signer).call{value: amount - keeperReward}('');
+                require(success);
+            } else {
+                I(reqt.returnToken).transfer(msg.sender, keeperReward);
+                I(reqt.returnToken).transfer(reqt.signer, amount - keeperReward);
+            }
+        }


Suggested change

uint initGasLeft = gasleft();// gas comes first

uint gasPrice;

assembly {

gasPrice := gasprice()

}

require(!users[reqt.signer].forbidAll, 'forbid all is active');

_verifySig(reqt);

// check if allowed to use this signature

require(block.number > users[reqt.signer].indexLastClaims[reqt.index] + reqt.interval, 'sig cant be valid yet');

require(users[reqt.signer].forbiddenSaltsBitMap[reqt.salt / 256] & (1 << reqt.salt % 256) == 0, 'forbidden salt');

require(reqt.interval >= 86400);// in seconds, this is to avoid griefing

// record state change if any

if (reqt.interval > 0) {

users[reqt.signer].indexLastClaims[reqt.index] = block.number; // its a subscription, track last execution time

} else {

_forbidSalt(reqt.signer, reqt.salt);// it was a one time transaction, forbid this salt

}

// call

// if data is 0, subtract keeper reward from user balance here

// otherwise data should return amount which is then being split between the user and the keeper

bytes memory data;

bool success;

if (reqt.needsHelper) {

(success, data) = I(_ab.helper).handle{value: msg.value}(reqt);

require(success == true, 'helper failed');

} else {

(success, data) = reqt.callee.call{value: msg.value}(abi.encodeWithSelector(reqt.selector, reqt.callData));

require(success == true, 'direct call failed');

}

// take fee and complete

uint amount; // compute amount from data bytes

assembly {

amount := mload(add(data, 0x20))

}

uint approxGas = (initGasLeft - gasleft() /*+ 21000 */) * gasPrice;

uint keeperReward = _calculateAmountInNativeToken(reqt.returnToken, approxGas + reqt.tip);

require(amount - keeperReward >= reqt.minOut);

if (reqt.returnToken == address(this)) {

users[msg.sender].balance += keeperReward;

users[reqt.signer].balance += amount - keeperReward;

} else {

if (reqt.returnToken == address(0)) {

(success, data) = payable(msg.sender).call{value: keeperReward}('');

require(success);

(success, data) = payable(reqt.signer).call{value: amount - keeperReward}('');

require(success);

} else {

I(reqt.returnToken).transfer(msg.sender, keeperReward);

I(reqt.returnToken).transfer(reqt.signer, amount - keeperReward);

}

}

You shouldn't include any implementation in the specification section, only in the Reference Implementation.

SamWilsn · 2023-02-07T15:45:58Z

EIPS/eip-6228.md

+    }
+```
+
+### Method \_calculateAmountInNativeToken(address returnToken, uint amount)


Suggested change

### Method \_calculateAmountInNativeToken(address returnToken, uint amount)

### Method `_calculateAmountInNativeToken(address returnToken, uint amount)`

use backticks for inline code

SamWilsn · 2023-02-07T15:47:05Z

EIPS/eip-6228.md

+As per previous related EIPs, replayable public signatures can be made secure enough for trust-minimized 0-liability use, which is the most economically efficient approach for start-ups.
+
+Another way to improve the user experience is to reduce the meta-transaction fee by making `address(this)` always indebted to the keepers, i.e. the keeper never receives the full fee after executing. This, however, would require at least one additional `SSTORE`, therefore requires more elaborate argumentation to consider.
+
+Adding user whitelists of allowed paths is not the best way to increase user security as of now since user whitelists reintroduce the same user friction this EIP tries to avoid. Since if a whitelist can be edited by signature, then it's practically useless, it needs an actual transaction from the user. 
+
+Global path whitelists are also ineffective unless they are made to be extremely restrictive, as a malicious signature can easily bypass them if a user is tricked into signing malicious data. Some major dApps provide functions with alterable destination address. To make the most of this EIP with restrictive global paths, it would be best to block all such dApps by default and give users the choice to enable them for personal use.
+
+A check for only authorized keepers is a way to greatly enhance security, in cost-efficient manner. However, authorized keepers then would need to KYC, which is not the most optimal solution. With pseudo-anonymous approach it looks a tiny bit better: choosing authorized keepers among those who frequently enough transact sufficient value from/to addresses of KYC-required services such as Coinbase exchange or Binance, it is still easily a questionable design solution too. Another option: only keepers with locked funds are eligible to transact on behalf of the users, however this case still requires trust for non-anonymous centralized governance, which is inefficient in many ways, and of all other things assumes liability, which is too expensive(insurance, support employees).
+
+Getting rid of method abstraction and restricting meta-transactions to predetermined token-related paths is a way to decrease overall gas cost and to protect user funds from being stolen, as long as associated contracts' functions do not have an option to alter destination address to any address. However, this will make meta-transactions a cellular phenomenon and restrict adoption of DeFi.


A lot of this reads more like Motivation, and not Rationale. The Rationale section should explain specific technical choices made within the EIP, while the Motivation section should justify the EIP as a whole.

SamWilsn · 2023-02-07T15:47:37Z

assets/eip-3561/README.md

@@ -0,0 +1 @@
+Dedicated repo with hardhat tests and easy install: https://github.com/SamPorter1984/EIP-3561-tests


Please remove any external links.

Suggested change

Dedicated repo with hardhat tests and easy install: https://github.com/SamPorter1984/EIP-3561-tests

SamWilsn · 2023-02-07T15:49:16Z

assets/eip-3561/contracts/TrustMinimizedProxy.sol

@@ -0,0 +1,188 @@
+pragma solidity >=0.8.0; //important


This is from a different EIP.

github-actions · 2023-04-26T00:17:25Z

There has been no activity on this pull request for 2 weeks. It will be closed after 3 months of inactivity. If you would like to move this PR forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

github-actions · 2023-06-07T00:19:42Z

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.

Create eip-6227.md

50c2581

SamPorter1984 requested a review from eth-bot as a code owner December 28, 2022 06:37

github-actions bot added c-new Creates a brand new proposal e-number Waiting on EIP Number assignment s-draft This EIP is a Draft t-erc labels Dec 28, 2022

SamPorter1984 changed the title ~~Create eip-6227.md~~ EIP-6227: Extreme ERC-20 Dec 28, 2022

Update eip-6227.md

bb164fe

github-actions bot removed the e-number Waiting on EIP Number assignment label Dec 28, 2022

SamPorter1984 added 4 commits December 28, 2022 09:48

Update eip-6227.md

d1315fb

Update eip-6227.md

53a532a

Update eip-6227.md

81d6321

Update eip-6227.md

180d3c9

SamPorter1984 changed the title ~~EIP-6227: Extreme ERC-20~~ EIP-6228: Extreme ERC-20 Dec 28, 2022

SamPorter1984 added 2 commits December 28, 2022 10:04

Update eip-6227.md

84c2df8

Rename eip-6227.md to eip-6228.md

6b86c4b

SamPorter1984 changed the title ~~EIP-6228: Extreme ERC-20~~ EIP-6228: Extreme ERC-20(meta-transaction token) Dec 28, 2022

SamPorter1984 changed the title ~~EIP-6228: Extreme ERC-20(meta-transaction token)~~ EIP-6228: Extreme ERC-20 (meta-transaction token) Dec 28, 2022

SamPorter1984 changed the title ~~EIP-6228: Extreme ERC-20 (meta-transaction token)~~ EIP-6228: Extreme ERC-20 (meta-transaction token MTT) Dec 28, 2022

SamPorter1984 added 10 commits December 28, 2022 10:17

Update eip-6228.md

8ccb56c

Update eip-6228.md

160f9b8

Update eip-6228.md

3ce2533

Update eip-6228.md

edb9032

Update eip-6228.md

7d17bb3

Update eip-6228.md

fab997b

Update eip-6228.md

c3f4cd2

Update eip-6228.md

6d9987e

Update eip-6228.md

61b90bb

Update eip-6228.md

614a7b6

SamPorter1984 added 16 commits December 28, 2022 12:00

Update eip-6228.md

841922a

Update eip-6228.md

0c61e8d

Update eip-6228.md

fa3783e

Update eip-6228.md

9c6e2c6

Update eip-6228.md

28b76ea

Update eip-6228.md

3b909e6

Update eip-6228.md

930df6e

Update eip-6228.md

ac893f1

Update eip-6228.md

fa3510d

Update eip-6228.md

80329ad

Create TrustMinimizedProxy.js

0c73b9b

Create fixtures.js

6a59124

Create TrustMinimizedProxy.sol

918658f

Create MockLogic.sol

18e201a

Create README.md

e844229

Update eip-3561.md

8656885

github-actions bot added c-update Modifies an existing proposal s-review This EIP is in Review labels Dec 28, 2022

SamPorter1984 added 3 commits December 28, 2022 14:30

Merge branch 'master' into master

0e1ad50

Update eip-6228.md

31b193f

Update eip-6228.md

64680ad

Pandapip1 changed the title ~~EIP-6228: Extreme ERC-20 (meta-transaction token MTT)~~ Add EIP-6228: Extreme EIP-20 (meta-transaction token MTT) Jan 4, 2023

Pandapip1 reviewed Jan 4, 2023

View reviewed changes

Update eip-6228.md

b589ac4

poojaranjan mentioned this pull request Feb 7, 2023

EIP Editing Office Hour Meeting 11 ethcatherders/EIPIP#207

Closed

27 tasks

SamWilsn requested changes Feb 7, 2023

View reviewed changes

github-actions bot added the w-stale Waiting on activity label Apr 26, 2023

github-actions bot closed this Jun 7, 2023

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add EIP-6228: Extreme EIP-20 (meta-transaction token MTT) #6228

Add EIP-6228: Extreme EIP-20 (meta-transaction token MTT) #6228

SamPorter1984 commented Dec 28, 2022 •

edited

Loading

eth-bot commented Dec 28, 2022 •

edited

Loading

Pandapip1 Jan 4, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

SamWilsn Feb 7, 2023

github-actions bot commented Apr 26, 2023

github-actions bot commented Jun 7, 2023

		title: Extreme ЕRС-20
		description: meta-transaction token (MTT)


		## Abstract

		This standard proposes a solution in which meta-transaction fees are deducted directly from the user' token transfer amount, no liquidity for keeper incentives required.

		- All existing solutions rely on funding/supporting a relayer/keeper network, which makes innovation more dependent on external funding.

		## Specification


		## Specification

		Signatories can create executable signatures for transactions of any kind. As long as signatory `address(this)` token balance or `returnToken`(token returned after after execution) balance is higher than keeper fee of a transaction at hand, and as long as remaining value after keeper fee transaction is above `minOut`, it is executable.

	### Method \_calculateAmountInNativeToken(address returnToken, uint amount)
	### Method `_calculateAmountInNativeToken(address returnToken, uint amount)`

		@@ -0,0 +1 @@
		Dedicated repo with hardhat tests and easy install: https://github.com/SamPorter1984/EIP-3561-tests

Add EIP-6228: Extreme EIP-20 (meta-transaction token MTT) #6228

Add EIP-6228: Extreme EIP-20 (meta-transaction token MTT) #6228

Conversation

SamPorter1984 commented Dec 28, 2022 • edited Loading

eth-bot commented Dec 28, 2022 • edited Loading

(pass) eip-3561.md

(fail) eip-6228.md

(pass) assets/eip-3561/README.md

(pass) assets/eip-3561/TrustMinimizedProxy.js

(pass) assets/eip-3561/contracts/MockLogic.sol

(pass) assets/eip-3561/contracts/TrustMinimizedProxy.sol

(pass) assets/eip-3561/fixtures.js

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

github-actions bot commented Apr 26, 2023

github-actions bot commented Jun 7, 2023

SamPorter1984 commented Dec 28, 2022 •

edited

Loading

eth-bot commented Dec 28, 2022 •

edited

Loading