Line formatting, and incorrect parameter type on onBatchFlashLoan function signature.

Line formatting, and incorrect parameter type on onBatchFlashLoan function signature.

address is the last 20 bytes of the msg.data, not past the msg.data also, use a simplified method to avoid copying entire msg.data just to read the last 20 bytes)

address is the last 20 bytes of the msg.data, not past the msg.data also, use a simplified method to avoid copying entire msg.data just to read the last 20 bytes)

This is not Decentralized Crypto anymore, probably never has been. Only the ones on top of the PYRAMID get to make the decisions. Please STOP EIP-1559 This will hurt so much people who invested in Mining hardware. Whomever is in agreeing with this is only in it for the money, they do not care about the little MOM and POP shops like me trying to make a few bucks mining ETH. DISGUSTING!!! STOP THIS EIP-1559 PLEASE!!!

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

• Trying to change EIP 681 state from Review to Last Call

I submitted an issue https://github.com/msagansk/Augur.Guide/issues/52

Simplify sentences with the same meaning in collections/_version2-english/9-fork/4-migration-of-the-objects.md. Reference: https://github.com/msagansk/Augur.Guide/pull/50#discussion_r562469609

@MicahZoltu Could you review this PR?

Note: This pull request is not all of the contents of 4-migration-of-the-objects.md. To make it easier to review and modify, I will submit the rest of the contents dividedly. Because I think this content is too long to review and modify in a single pull request. When this pull request is reviewed and I reflect suggestions, I will submit the next pull request.

I left a few grammatical comments but this looks great overall. I love the images!

I have never been complimented so much by you, so I'm very happy 😀

One stylistic note, you may want to consider using a less conversational tone. As currently worded, it feels more like a conversational tutorial than documentation. Given that a user probably isn't going to be reading the whole guide front to back and instead will be looking at different pieces of interest to theme a more direct and to the point style may be more appropriate.

I used a conversational tone to make it more user-friendly. But I read your suggestion and I learned a conversational tone not always mean user-friendly. To reflect this suggestion, I submitted an issue: https://github.com/msagansk/Augur.Guide/issues/51. Thanks!

You repeat yourself several times in this paragraph. It may be better to simplify it down to just a simple one-sentence answer.

I'm going to submit this suggestion as an issue.

ethereum_address        = ( "0x" 40*40HEXDIG ) / ENS_NAME

I believe this is a typo, should be 40*HEXDIG?

Yes, it is a typo, you are correct.

Reference: https://github.com/msagansk/Augur.Guide/pull/50#pullrequestreview-574041260

Demo: https://crystalballbe.github.io/version2-english/9-fork/4-migration-of-the-objects.html

@MicahZoltu Could you review this PR?

Note: This pull request is not all of the contents of 4-migration-of-the-objects.md. To make it easier to review and modify, I will submit the rest of the contents dividedly. Because I think this content is too long to review and modify in a single pull request. When this pull request is reviewed and I reflect suggestions, I will submit the next pull request.

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

There are many possibilities on what will happen to Ethereum after EIP 1559 is implemented, and the only way to know for sure is to implement it. There are two things I know are certain, investors and miners both want to be paid. Apart from fan boyism, we are both investors, just coming at it from different angles. Miners provide a service, and investors provide an incentive. While it is completely possible that implementation can happen with both parties being happy, it is not the future I see for EIP 1559. My main argument for this is pure financial incentive. Investors do not want to be separated from their money in the form of fees, while miners want to be compensated for the service they provide. At the end of the day, it is not important what currency either party is involved in, they will gravitate to the currencies that work for their own personal use case. I do not mine Ethereum because it is something that I hold an emotional tie to, I mine because it is profitable to do so with the funds and equipment available to myself. If EIP 1559 is implemented, myself, and likely many other miners will migrate to where the new money is coming in. While I do believe Ethereum has reached a point it is so engrained and invested into it is not going anywhere, it does not mean it is safe from the whim of the people supporting it. If for whatever reason there was indication that Ethereum was not going to grow, or even hold its value investors would be running for the hills. It is the same way with myself, if there was indication that mining Ethereum was no longer profitable, I would switch algorithm to whatever was profitable. While there may be enough diehard Ethereum miners to keep the system going, the network performance and security will be greatly degraded. There are already complaints within the community on the slow performance of the network. With an exodus of miners, there would be even less protection from 51% attacks. For example, a mining pool could decide based on the number of miners leaving the network they would have the hashrate to successfully implement a 51% attack. With current complaints of network speed, and precedent set in Ethereum classic of 51% attacks, I do not feel that EIP 1559 will be good for the Ethereum community. Like so many other things in life people are only happy when money is being spent and people are getting paid. I do feel there is room for a middle ground, it will have to be competitive with the rest of the cryptocurrency ecosystem.

Since this is your first issue, we kindly remind you to check out EIP-1 for guidance.

Simple Summary

Extending ERC20 interface for tokens with fee on transfer.

Abstract

This standard defines new interfaces a token with fee on transfer should implement, while remaining backwards compatible with ERC20. This standard adds 2 new transfer methods and 2 view methods.

• Existing transfer methods let the sender specify the source amount being sent. The new transfer methods will allow you to define the amount that will be received by the receiver.
• In addition to that, 2 new interfaces will allow you to check the expected received amount for a specific sent amount and required send amount for a specific receive amount. This will help dApps to return the exact exchange rate.
• Existing tokens with fee demonstrate the need of whitelisting options. This standard should account that matter.
• The standard will also discuss the behavior of balanceOf API for a token with fees.

Motivation

Some tokens in the Ethereum ecosystem apply transfer fees, such as DGX and CGT. The USDT token also has the fee feature which is disabled at the time of writing. These tokens implement the typical ERC20 interface. However, when calling the transfer and transferFrom methods, the actual amount the receiver will get will be smaller than the sent amount.

function transfer(address _to, uint256 _value) external returns (bool success);
function transferFrom(address _from, address _to, uint256 _value) external returns (bool success);

• This leads to incompatibility with many DeFi services that expect the received amount to be equal to the sent amount.
• Some DeFi projects have adapted by calculating the amount difference after the transfer, but this comes at the expense of higher gas usage and the returned rate is not accurate.
• In most cases, the balance of receiver will increase smaller than _value params (fee is included in the _value). The other type, the balance of sender will reduce bigger than _value params (fee is excluded in the _value). This also make harder for developer to handle all the cases.

This standard aims to create a more uniform and elegant way to handle tokens with fees.

Specification

interface IERCxxx is IERC20 {
function transferExactDest(address _to, uint _value) external returns (bool success);
function transferExactDestFrom(address _from, address _to, uint _value) external returns (bool success);
function getReceivedAmount(address _from, address _to, uint _sentAmount) external view returns (uint receivedAmount, uint feeAmount);
function getSendAmount(address _from, address _to, uint _receivedAmount) external view returns (uint sendAmount, uint feeAmount);
}

transferExactDest

Transfers _value amount of token to address _to and MUST emit the Transfer event. The balance of msg.sender will be deducted by _value + _fee. Add _value amount to the balance of the receiver. If zero fees should be applied due to whitelisting, assume the above _fee to be zero.

function transferExactDest(address _to, uint _value) external returns (bool success);

transferFromExactDest

Transfers _value amount of token to address _to and MUST fire the Transfer event. The balance of _from will be deducted by _value + _fee. If zero fees should be applied due to whitelisting, assume the above _fee value to be zero.

function transferExactDestFrom(address _from, address _to, uint _value) external returns (bool success);

getReceivedAmount

A query function that returns the amount of tokens a receiver will get if a sender sends _sentAmount tokens. Note the _to and _from addresses are present, the implementation should use those values to check for any white listing.

function getReceivedAmount(address _from, address _to, uint _sendAmount) external view returns (uint receivedAmount, uint feeAmount);

getSendAmount

Returns the amount of tokens the sender has to send if he wants the receiver to receive exactly _receivedAmount tokens. Note the _to and _from addresses are present, the implementation should use those values to check for any white listing.

function getSendAmount(address _from, address _to, uint _receivedAmount) external view returns (uint sendAmount, uint feeAmount);

Behaviour of existing ERC20 transfer functions

The signature and behavior of transfer and transferFrom functions will remain the same. _value parameter in those functions will reflect the _sentAmount of the token.

transfer

Transfers _value amount of token from msg.sender and MUST emit the Transfer event. Will add _value to the balance of _to, after deducting fee.

function transfer(address _to, uint256 _value) external returns (bool success);

transferFrom

Transfers _value amount of token from _from and MUST fire the Transfer event. Will add _value to the balance of _to, after deducting fee.

function transferFrom(address _from, address _to, uint256 _value) external returns (bool success);

balanceOf

Returns the exact token balance of the account, without fee considerations.

function balanceOf(address account) external view returns (uint256)

Query user balance after deducting fee

Another type of problem was encountered with thebalanceOf function. For CGT token, balanceOf returns the balance for a user after fee deduction. They try to return a balance after deducting fee for the next transfer.

The point is balanceOfWithFee actually can be different depending on the transaction sizes. Example: transfer fee is 1%, max fee is 1 token, user has 10K tokens. If he sends all tokens at once, the actual fee would be 1 token. If he sends tokens in 10 transactions, the actual fee will be 10 tokens. Due to these reasons, we choose not to add additional any API to return balanceOfWithFee.

Usage:

• When a user wants to send the exact destination amount to another person, he calls transferExactDestAmount.
• When a user wants to deposit a token to a contract or create a swap transaction: the contract calls transferFromExactDestAmount to get the exact amount from the user.
• When a DEX returns the exchange rate of a token, contract calls getReceivedAmount to get the received amount to contract, then calculate the amountOut.

Test Cases

This repository contains all the tests.

Implementations

T.B.D

Copyright

Copyright and related rights waived via CC0.

It's clear that managing a mempool of EIP-1559 transactions is non-trivial. As the spec stands today, the value that a transaction may provide the miner is actually a function of the current base_fee. This is problematic as it implies that the mempool must constantly reorder its transactions lists as the base_fee fluctuates.

The alternative that I propose is to change from using a dynamic tip to a constant tip. The constant tip has several properties that are advantageous, most notably that a mempool can easily maintain an ordered list of the most lucrative transactions, since their payouts do not depend on the base_fee.

I've done some preliminary comparisons between the dynamic tip mechanism vs. the constant tip mechanism, and shared some thoughts on how a mempool might handle the two: https://hackmd.io/@matt/HJ4YbvNcw

The main caveat is that dynamic tip transactions offered a very flexible mechanism for legacy transactions to be ported over. I believe that constant tip transactions can be similarly flexible, but require a bit more complexity. For example, I've packed the upper byte in gas_price to be used as the tip in gwei. This leaves 56 bits to specify a maximum fee_cap of 72_057_594 gwei. This should be acceptable for the foreseeable future.

We ended up deciding that i) supporting legacy transactions was a very high priority and ii) sorting dynamic tip transactions aren't as bad as originally thought. Here is a write up from @adietrichs on this topic: https://hackmd.io/UhdsNdF7RTOyELAlB6-MCA?view

BoringCrypto from SushiSwap revealed a vulnerability in the standard, that we are solving but requiring that onFlashLoan returns true, and requiring that the lender verifies that true was returned.

Aave v2 already does this, thankfully.

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

• EIP 1559 requires approval from one of (@mslipper, @afdudley, @econoar, @i-norden, @abdelhamidbakhta, @vbuterin)

After some consideration of possible sentinel values, I think that using keccak256("ERC3156FlashBorrower.onFlashLoan") is good enough.

Original spec had the starting base fee (at fork block) as 1 nanoeth, but this was unintentionally lost along the way. I believe current clients have implemented it the original way so this change shouldn't require any client changes.

Also fixed a bug in the spec that allowed the base fee to go negative by just flooring it to 0.