profile
viewpoint
Micah Zoltu MicahZoltu @AugurProject Philippines

ethereum/EIPs 5531

The Ethereum Improvement Proposal repository

ethereumjs/ethereumjs-blockstream 64

Reliable stream of Ethereum blocks

ethereumjs/ethereumjs-ledger 15

[DEPRECATED] A wrapper library around the Ledger line of devices that attempts to simplify usage and handle various failure modes/problems.

AugurProject/Solium 4

A customizable, stand-alone linter for Ethereum Solidity

MicahZoltu/browser-es-modules-template 4

Template project that shows how to use ES modules in a browser.

AugurProject/rep-migration 2

REP migration scripts

MicahZoltu/augur-docker-swarm 1

A docker swarm setup for an Augur development environment.

push eventethereum/EIPs

Alberto Cuesta Cañada

commit sha f532c753d2b0ca65b47a23a0f3ee5cee28c20a8d

Automatically merged updates to draft EIP(s) 3156 (#3217) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft, Review, or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing

view details

push time in 8 hours

PR merged ethereum/EIPs

Erc3156 - typos

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

+3 -3

0 comment

1 changed file

albertocuestacanada

pr closed time in 8 hours

PR opened ethereum/EIPs

Erc3156 - typos

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

+3 -3

0 comment

1 changed file

pr created time in 8 hours

push eventethereum/EIPs

Dror Tirosh

commit sha 5fd5c6b855a9e3dad2d3ba6289c8e000a9967fdb

Automatically merged updates to draft EIP(s) 2771 (#3216) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft, Review, or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing

view details

push time in 10 hours

PR merged ethereum/EIPs

fix sample implementation, to match description

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)

+5 -5

0 comment

1 changed file

drortirosh

pr closed time in 10 hours

PR opened ethereum/EIPs

fix sample implementation, to match description

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)

+5 -5

0 comment

1 changed file

pr created time in 10 hours

pull request commentethereum/EIPs

Update eip-1559.md

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!!!

edocodi

comment created time in 11 hours

pull request commentethereum/EIPs

After two weeks in "Review", change status of ERC-681 to "Last Call"

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
nagydani

comment created time in a day

Pull request review commentmsagansk/Augur.Guide

Add "migration of the objects" to Fork section

+---+title: Migration of the objects+---++{% capture glossary_path %}{{ "/" | absolute_url }}/{{page.collection}}/7-glossary.html{% endcapture %}+{% assign glossary_child_universe = glossary_path | append: '#Child_Universe' %}+{% assign glossary_creation_bond = glossary_path | append: '#Creation_Bond' %}+{% assign glossary_creator_fee = glossary_path | append: '#Creator_Fee' %}+{% assign glossary_designated_reporter = glossary_path | append: '#Designated_Reporter' %}+{% assign glossary_dispute_window = glossary_path | append: '#Dispute_Window' %}+{% assign glossary_final_outcome_ = glossary_path | append: '#Final_Outcome' %}+{% assign glossary_finalized_market = glossary_path | append: '#Finalized_Market' %}+{% assign glossary_fork = glossary_path | append: '#Fork' %}+{% assign glossary_forking_market = glossary_path | append: '#Forking_Market' %}+{% assign glossary_forking_period = glossary_path | append: '#Forking_Period' %}+{% assign glossary_initial_reporter = glossary_path | append: '#initial_reporter' %}+{% assign glossary_invalid_outcome = glossary_path | append: '#Invalid_Outcome' %}+{% assign glossary_losing_universe = glossary_path | append: '#Losing_Universe' %}+{% assign glossary_market = glossary_path | append: '#Market' %}+{% assign glossary_market_creator = glossary_path | append: '#Market_Creator' %}+{% assign glossary_non_finalized_market = glossary_path | append: '#Non-Finalized_Market' %}+{% assign glossary_outcome = glossary_path | append: '#Outcome' %}+{% assign glossary_parent_universe = glossary_path | append: '#Parent_Universe' %}+{% assign glossary_participation_token = glossary_path | append: '#Participation_Token' %}+{% assign glossary_reputation_token = glossary_path | append: '#Reputation_Token' %}+{% assign glossary_smart_contract = glossary_path | append: '#Smart_Contract' %}+{% assign glossary_share = glossary_path | append: '#Share' %}+{% assign glossary_unfilled_order = glossary_path | append: '#Unfilled_Order' %}+{% assign glossary_universe = glossary_path | append: '#Universe' %}+{% assign glossary_validity_bond = glossary_path | append: '#Validity_Bond' %}+{% assign glossary_winning_universe = glossary_path | append: '#Winning_Universe' %}++# Not only REP you can migrate+You probably know you have to migrate your [REP]({{glossary_reputation_token}}) by yourself when a [fork]({{glossary_fork}}) occurs. But REP isn't the only one that can be migrated. On this page, we dive a bit deeper into the migration of REP and other migratable objects in the [universe]({{glossary_universe}}).++**Note:** This page does not cover all objects in the universe, but only those that are likely to directly affect end users.++# Hierarchical Relationships between Objects+Before you understand the migration of the objects, let's understand the relationships between them, it could make it easier to understand the migration.++The objects in the [universe]({{glossary_universe}}) form a hierarchical relationship with the universe as a top.+{% capture image_src %}{{ "/" | absolute_url }}assets/images/{{page.collection}}/fork/migration-of-the-objects/relationships-between-objects.svg{% endcapture %}+{% include zoom-image.html src=image_src caption="Figure 1. hierarchical relationships between objects" %}++The universe has [REP]({{glossary_reputation_token}}), [Market]({{glossary_market}}), and [Dispute Window]({{glossary_dispute_window}}) attached. And Market and Dispute Window have some attached objects, while REP doesn't have any attached object. The point is that **when forks occur, the lower objects migrate where their upper object migrates, and if the upper object may not migrate then their lower objects may not migrate**. Of course, there are some exceptions, but this principle might help you understand the migration of the objects.++# Overview+The following figure shows where the objects in the [parent universe]({{glossary_parent_universe}}) are migrated after a fork. (Click to enlarge)+{% capture image_src %}{{ "/" | absolute_url }}assets/images/{{page.collection}}/fork/migration-of-the-objects/outline.svg{% endcapture %}+{% include zoom-image.html src=image_src caption="Figure 2. overview of migration" %}++The red objects can only be migrated to the [winning universe]({{glossary_winning_universe}}), the blues can only be migrated to the [losing universe]({{glossary_losing_universe}}), the purples can be migrated to one of the [child universes]({{glossary_child_universe}}), and the greens cannot be migrated to any child universe.++Before a [fork]({{glossary_fork}}), all objects are in the parent universe. After a fork, in the parent universe, there are the [finalized market]({{glossary_finalized_market}}), [dispute window]({{glossary_dispute_window}}), and the objects which are attached to them. The winning universe and the losing universe are created, and the [forking market]({{glossary_forking_market}}), [non-finalized market]({{glossary_non_finalized_market}}), and [REP]({{glossary_reputation_token}}) are migrated to them. ++Those can be summarized as follows:++  - The migratable objects are:+    - Forking market+    - Non-Forking Market+    - REP+  - The un-migratable objects are:+    - Finalized Market+    - Dispute Window +  - The winning universe receives:+    - Forking market and its attached objects+    - Non-Forking market+    - REP+  - The losing universe receives:+    - Forking market+    - REP++# Who creates child universes?+As mentioned above, some objects in the [parent universe]({{glossary_parent_universe}}) can be migrated to a [child universes]({{glossary_child_universe}}), but who creates the child universe? Is it created by Augur [contracts]({{glossary_smart_contract}}) automatically? No, it is created by [REP]({{glossary_reputation_token}}) holder. The REP holder who *first* migrates their REP to the child universe creates the child universe. When REP in the parent universe first migrated to a child universe, the child universe is created. A child universe is not created until someone migrates their REP to the child universe. Even if the [forking market]({{glossary_forking_market}}) has [finalized]({{glossary_finalized_market}}) or the [forking period]({{glossary_forking_period}}) ends, the child universe is not created without migrating REP.

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

CrystalBallBe

comment created time in a day

issue openedmsagansk/Augur.Guide

Simplify sentences in "migration of the objects"

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

created time in a day

push eventmsagansk/Augur.Guide

CBB

commit sha a91821e63bdda00dd542a84d939d611648afde73

Add "migration of the objects" to Fork section This pull request is not all of the contents of `4-migration-of-the-objects.md`. To make easier to review and modify, I will submit the rest of 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 submmit next pull request.

view details

CBB

commit sha 2b74365051197322b6003d375c68bcb665875bd6

Update collections/_version2-english/9-fork/4-migration-of-the-objects.md Co-authored-by: Micah Zoltu <micah@zoltu.net>

view details

CBB

commit sha 4ebae5b1fdefde475cf19e077bca0f37614e648e

Update collections/_version2-english/9-fork/4-migration-of-the-objects.md Co-authored-by: Micah Zoltu <micah@zoltu.net>

view details

CBB

commit sha 5c7473a53cdff9220193a3262b7a1f2f6a968142

Update collections/_version2-english/9-fork/4-migration-of-the-objects.md Co-authored-by: Micah Zoltu <micah@zoltu.net>

view details

CBB

commit sha d0ddf52af55c260ebe2de03e3ac7084dab9839d0

Update collections/_version2-english/9-fork/4-migration-of-the-objects.md Co-authored-by: Micah Zoltu <micah@zoltu.net>

view details

CBB

commit sha 61944c99a19b39b5af120357c80b08567136ac57

Update collections/_version2-english/9-fork/4-migration-of-the-objects.md Co-authored-by: Micah Zoltu <micah@zoltu.net>

view details

CBB

commit sha 9d4e1202341f8b4a3d16ba6938f97ea3a6ab064a

Update collections/_version2-english/9-fork/4-migration-of-the-objects.md Co-authored-by: Micah Zoltu <micah@zoltu.net>

view details

CBB

commit sha e9a2c45d7128f846a064415e9dcaac49b5a202c7

Update collections/_version2-english/9-fork/4-migration-of-the-objects.md Co-authored-by: Micah Zoltu <micah@zoltu.net>

view details

CBB

commit sha d1fb73ca8d1c82656ba9bcc4b3351e7e47521679

Merge pull request #50 from CrystalBallBe/master Add "migration of the objects" to Fork section

view details

push time in a day

PR merged msagansk/Augur.Guide

Add "migration of the objects" to Fork section

@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.

+84 -0

2 comments

3 changed files

CrystalBallBe

pr closed time in a day

pull request commentmsagansk/Augur.Guide

Add "migration of the objects" to Fork section

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!

CrystalBallBe

comment created time in a day

Pull request review commentmsagansk/Augur.Guide

Add "migration of the objects" to Fork section

+---+title: Migration of the objects+---++{% capture glossary_path %}{{ "/" | absolute_url }}/{{page.collection}}/7-glossary.html{% endcapture %}+{% assign glossary_child_universe = glossary_path | append: '#Child_Universe' %}+{% assign glossary_creation_bond = glossary_path | append: '#Creation_Bond' %}+{% assign glossary_creator_fee = glossary_path | append: '#Creator_Fee' %}+{% assign glossary_designated_reporter = glossary_path | append: '#Designated_Reporter' %}+{% assign glossary_dispute_window = glossary_path | append: '#Dispute_Window' %}+{% assign glossary_final_outcome_ = glossary_path | append: '#Final_Outcome' %}+{% assign glossary_finalized_market = glossary_path | append: '#Finalized_Market' %}+{% assign glossary_fork = glossary_path | append: '#Fork' %}+{% assign glossary_forking_market = glossary_path | append: '#Forking_Market' %}+{% assign glossary_forking_period = glossary_path | append: '#Forking_Period' %}+{% assign glossary_initial_reporter = glossary_path | append: '#initial_reporter' %}+{% assign glossary_invalid_outcome = glossary_path | append: '#Invalid_Outcome' %}+{% assign glossary_losing_universe = glossary_path | append: '#Losing_Universe' %}+{% assign glossary_market = glossary_path | append: '#Market' %}+{% assign glossary_market_creator = glossary_path | append: '#Market_Creator' %}+{% assign glossary_non_finalized_market = glossary_path | append: '#Non-Finalized_Market' %}+{% assign glossary_outcome = glossary_path | append: '#Outcome' %}+{% assign glossary_parent_universe = glossary_path | append: '#Parent_Universe' %}+{% assign glossary_participation_token = glossary_path | append: '#Participation_Token' %}+{% assign glossary_reputation_token = glossary_path | append: '#Reputation_Token' %}+{% assign glossary_smart_contract = glossary_path | append: '#Smart_Contract' %}+{% assign glossary_share = glossary_path | append: '#Share' %}+{% assign glossary_unfilled_order = glossary_path | append: '#Unfilled_Order' %}+{% assign glossary_universe = glossary_path | append: '#Universe' %}+{% assign glossary_validity_bond = glossary_path | append: '#Validity_Bond' %}+{% assign glossary_winning_universe = glossary_path | append: '#Winning_Universe' %}++# Not only REP you can migrate+You probably know you have to migrate your [REP]({{glossary_reputation_token}}) by yourself when a [fork]({{glossary_fork}}) occurs. But REP isn't the only one that can be migrated. On this page, we dive a bit deeper into the migration of REP and other migratable objects in the [universe]({{glossary_universe}}).++**Note:** This page does not cover all objects in the universe, but only those that are likely to directly affect end users.++# Hierarchical Relationships between Objects+Before you understand the migration of the objects, let's understand the relationships between them, it could make it easier to understand the migration.++The objects in the [universe]({{glossary_universe}}) form a hierarchical relationship with the universe as a top.+{% capture image_src %}{{ "/" | absolute_url }}assets/images/{{page.collection}}/fork/migration-of-the-objects/relationships-between-objects.svg{% endcapture %}+{% include zoom-image.html src=image_src caption="Figure 1. hierarchical relationships between objects" %}++The universe has [REP]({{glossary_reputation_token}}), [Market]({{glossary_market}}), and [Dispute Window]({{glossary_dispute_window}}) attached. And Market and Dispute Window have some attached objects, while REP doesn't have any attached object. The point is that **when forks occur, the lower objects migrate where their upper object migrates, and if the upper object may not migrate then their lower objects may not migrate**. Of course, there are some exceptions, but this principle might help you understand the migration of the objects.++# Overview+The following figure shows where the objects in the [parent universe]({{glossary_parent_universe}}) are migrated after a fork. (Click to enlarge)+{% capture image_src %}{{ "/" | absolute_url }}assets/images/{{page.collection}}/fork/migration-of-the-objects/outline.svg{% endcapture %}+{% include zoom-image.html src=image_src caption="Figure 2. overview of migration" %}++The red objects can only be migrated to the [winning universe]({{glossary_winning_universe}}), the blues can only be migrated to the [losing universe]({{glossary_losing_universe}}), the purples can be migrated to one of the [child universes]({{glossary_child_universe}}), and the greens cannot be migrated to any child universe.++Before a [fork]({{glossary_fork}}), all objects are in the parent universe. After a fork, in the parent universe, there are the [finalized market]({{glossary_finalized_market}}), [dispute window]({{glossary_dispute_window}}), and the objects which are attached to them. The winning universe and the losing universe are created, and the [forking market]({{glossary_forking_market}}), [non-finalized market]({{glossary_non_finalized_market}}), and [REP]({{glossary_reputation_token}}) are migrated to them. ++Those can be summarized as follows:++  - The migratable objects are:+    - Forking market+    - Non-Forking Market+    - REP+  - The un-migratable objects are:+    - Finalized Market+    - Dispute Window +  - The winning universe receives:+    - Forking market and its attached objects+    - Non-Forking market+    - REP+  - The losing universe receives:+    - Forking market+    - REP++# Who creates child universes?+As mentioned above, some objects in the [parent universe]({{glossary_parent_universe}}) can be migrated to a [child universes]({{glossary_child_universe}}), but who creates the child universe? Is it created by Augur [contracts]({{glossary_smart_contract}}) automatically? No, it is created by [REP]({{glossary_reputation_token}}) holder. The REP holder who *first* migrates their REP to the child universe creates the child universe. When REP in the parent universe first migrated to a child universe, the child universe is created. A child universe is not created until someone migrates their REP to the child universe. Even if the [forking market]({{glossary_forking_market}}) has [finalized]({{glossary_finalized_market}}) or the [forking period]({{glossary_forking_period}}) ends, the child universe is not created without migrating REP.

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.

CrystalBallBe

comment created time in a day

pull request commentethereum/EIPs

After two weeks in "Review", change status of ERC-681 to "Last Call"

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.

nagydani

comment created time in a day

issue openedmsagansk/Augur.Guide

Use a less conversational tone on "migration of the objects"

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

created time in a day

pull request commentmsagansk/Augur.Guide

Add "migration of the objects" to Fork section

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

CrystalBallBe

comment created time in 2 days

PR opened msagansk/Augur.Guide

Add "migration of the objects" to Fork section

@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.

+84 -0

0 comment

3 changed files

pr created time in 2 days

issue commentethereum/EIPs

Possible miner exodus and 51%

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

evergreen69

comment created time in 2 days

issue openedethereum/EIPs

Possible miner exodus and 51%

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.

created time in 2 days

issue commentethereum/EIPs

ERC20 Extending: token with fee on transfer

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

ducquangkstn

comment created time in 2 days

issue openedethereum/EIPs

ERC20 Extending: token with fee on transfer

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.

created time in 2 days

PR closed ethereum/EIPs

EIP-1559 constant tip strategy stale

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.

+6 -7

7 comments

1 changed file

lightclient

pr closed time in 2 days

pull request commentethereum/EIPs

EIP-1559 constant tip strategy

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

lightclient

comment created time in 2 days

push eventethereum/EIPs

Alberto Cuesta Cañada

commit sha 4c75ca0d2be2712f3defe50012707e624f1cba4b

Automatically merged updates to draft EIP(s) 3156 (#3209) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft, Review, or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing

view details

push time in 2 days

PR merged ethereum/EIPs

erc3156: added return types to avoid vulnerability

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.

+63 -18

2 comments

1 changed file

albertocuestacanada

pr closed time in 2 days

pull request commentethereum/EIPs

Removes Resources section.

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)
MicahZoltu

comment created time in 2 days

Pull request review commentethereum/EIPs

erc3156: added return types to avoid vulnerability

 function flashLoan(     IERC20 token,     uint256 amount,     bytes calldata data-) external {+) external returns (bool) {

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

albertocuestacanada

comment created time in 2 days

push eventethereum/EIPs

Micah Zoltu

commit sha 537ef77d348e5b896676ea020e72a816518b6206

Automatically merged updates to draft EIP(s) 1559 (#3212) Hi, I'm a bot! This change was automatically merged because: - It only modifies existing Draft or Last Call EIP(s) - The PR was approved or written by at least one author of each modified EIP - The build is passing

view details

push time in 3 days

PR merged ethereum/EIPs

1559: Changes starting base fee to 1 nanoeth and floors base fee at 0.

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.

+2 -2

1 comment

1 changed file

MicahZoltu

pr closed time in 3 days

more