New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERC 644: Token Standard for Modular and Upgradeable Tokens #644

Open
chrisfranko opened this Issue Jun 16, 2017 · 29 comments

Comments

Projects
None yet
@chrisfranko

chrisfranko commented Jun 16, 2017

Preamble

EIP: <to be assigned>
Title: Token standard for upgradeable and modular tokens
Author: christopher@expanse.tech
Type: Standard Track
Category ERC
Status: Draft
Created: 2017/06/16

Simple Summary

The idea is to abstract user balances away from the token's business logic making the tokens upgradeable, and opens the door for modular functionality to be added over time.

Abstract

As it stands now, if any ERC20 tokens were to encounter any sort of fatal flaw, ever balance on that token would be at risk and recovering from the flaw would be cumbersome at best. This ERC proposes a way to accomplish the tasks below by abstracting the user balances away from the business logic.

  • Makes tokens upgradeable
  • Allows for modular functionality
  • Creates a way to insulate user balances from exploitable code

Motivation

Protecting consumers from potential exploits.

Specification

Balances.sol

Methods

getBalances

Returns an account's token balance.

function getBalance(address _acct) returns(uint balance)

incBalance

Increases an account's token balance.

function incBalance(address _acct, uint _val) onlyModule returns(bool success)

decBalance

Decreases an account's token balance.

function decBalance(address _acct, uint _val) onlyModule returns(bool success)

getAllowance

Returns an accounts allowed balance to be spent on behalf of owner.

function getAllowance(address _owner, address _spender) returns(uint remaining)

setApprove

Allows _spender to spend from _sender's account. When the function is called it over writes the current allowance with _value`.

function setApprove(address _sender, address _spender, uint256 _value) onlyModule returns(bool success)

decApprove

Decreases an accounts allowance amount by _value.

function decApprove(address _from, address _spender, uint _value) onlyModule returns(bool success)

getModule

Returns if module _acct is active or not.

function getModule(address _acct) returns (bool success)

setModule

Sets module _acct to true or false.

function setModule(address _acct, bool _set) onlyRoot returns(bool success)

getTotalSupply

Returns the total supply.

function getTotalSupply() returns(uint)

incTotalSupply

Increases the total supply.

function incTotalSupply(uint _val) onlyModule returns(bool success)

decTotalSupply

Decreases the total supply.

function decTotalSupply(uint _val) onlyModule returns(bool success)

transferRoot

Transfers to a new account.

function transferRoot(address _new) onlyRoot returns(bool success)

Events

BalanceAdj

Triggered when balances are adjusted.

event BalanceAdj(address indexed Module, address indexed Account, uint Amount, string Polarity);

ModuleSet

Triggered when modules are updated.

event ModuleSet(address indexed Module, bool indexed Set);

Implementation

https://github.com/expanse-org/Tokens/tree/master/Token_Contracts/contracts

Copyright

Copyright and related rights waived via CC0.

@jefffreey

This comment has been minimized.

Show comment
Hide comment
@jefffreey

jefffreey Jun 20, 2017

I came for a similar thing, which is upgradeable contracts. Do we have a standard Data/Interface contracts? Should I make an EIP for this?

jefffreey commented Jun 20, 2017

I came for a similar thing, which is upgradeable contracts. Do we have a standard Data/Interface contracts? Should I make an EIP for this?

@gislik

This comment has been minimized.

Show comment
Hide comment
@gislik

gislik Jul 14, 2017

Having developed a token system I'm interested in this ERC. In addition I'm using Solidity libraries to reduce gas for deployment of the tokens and simplifying upgrades in case of bugs found or if the need for added functionality arises.

https://github.com/monerium/smart-contracts/tree/master/contracts

I'm guessing that your motivation for standardising the modules of the system is to mix-and-match different implementations of storage and business logic, am I right?

In my design I found it important to split the token not only into storage and business logic but:

  • Frontend
    This is a contract which implements the ERC20 standard by forwarding all method calls to the Controller. The main reason for this is to have a fixed address for users to interact with. This will become less important when ENS and Token registries become more widely used but for now most (if not all the wallets and other token software) uses hard coded address for token addresses.
  • Controller (ERC20Lib)
    Business logic implementation.
  • Storage (TokenStorageLib)
    This is what you call Balances. The main purpose is to keep the balances outside of the business logic and frontend so that it may be reused in case changes to the business logic is needed.

It seems that we've come up with a very comparable solution just using different terminology and I wanted to participate in defining a common set of interfaces. Unfortunately it may be too late for me to adapt my code to this standard since it has already been deployed to Rinkeby testnet and will later this year be deployed on the mainnet but I think I have something to contribute to the discussion :)

gislik commented Jul 14, 2017

Having developed a token system I'm interested in this ERC. In addition I'm using Solidity libraries to reduce gas for deployment of the tokens and simplifying upgrades in case of bugs found or if the need for added functionality arises.

https://github.com/monerium/smart-contracts/tree/master/contracts

I'm guessing that your motivation for standardising the modules of the system is to mix-and-match different implementations of storage and business logic, am I right?

In my design I found it important to split the token not only into storage and business logic but:

  • Frontend
    This is a contract which implements the ERC20 standard by forwarding all method calls to the Controller. The main reason for this is to have a fixed address for users to interact with. This will become less important when ENS and Token registries become more widely used but for now most (if not all the wallets and other token software) uses hard coded address for token addresses.
  • Controller (ERC20Lib)
    Business logic implementation.
  • Storage (TokenStorageLib)
    This is what you call Balances. The main purpose is to keep the balances outside of the business logic and frontend so that it may be reused in case changes to the business logic is needed.

It seems that we've come up with a very comparable solution just using different terminology and I wanted to participate in defining a common set of interfaces. Unfortunately it may be too late for me to adapt my code to this standard since it has already been deployed to Rinkeby testnet and will later this year be deployed on the mainnet but I think I have something to contribute to the discussion :)

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Jul 14, 2017

chrisfranko commented Jul 14, 2017

@chrisfranko chrisfranko changed the title from ERC: Token Standard for Modular and Upgradeable Tokens to ERC 644: Token Standard for Modular and Upgradeable Tokens Jul 15, 2017

@davux

This comment has been minimized.

Show comment
Hide comment
@davux

davux Jul 16, 2017

The idea of separating balances from business logic seems not only fair, but necessary. However, why not keep ERC20 function naming like @gislik does in his approach?

If there is value in chaning the functions' logic such as e.g. incBalance() – and I would say there is –, then that should be discussed as a proper ERC20 evolution proposal. At any rate, name consistency between the core token interface (be it ERC20 or any evolution of it) and the storage contract should be considered important.

davux commented Jul 16, 2017

The idea of separating balances from business logic seems not only fair, but necessary. However, why not keep ERC20 function naming like @gislik does in his approach?

If there is value in chaning the functions' logic such as e.g. incBalance() – and I would say there is –, then that should be discussed as a proper ERC20 evolution proposal. At any rate, name consistency between the core token interface (be it ERC20 or any evolution of it) and the storage contract should be considered important.

@Dexaran

This comment has been minimized.

Show comment
Hide comment
@Dexaran

Dexaran Jul 17, 2017

You should keep in mind that ERC #20 token standard functions are leading to monetary losses. I wrote a number of articles about it (for example this one).

The main problem of ERC #20 token is that it has two ways of transferring funds:

  1. transfer
  2. approve + transferFrom

which assumes that first pattern is processed without handling by the receiver and the second pattern simulates transaction handling.

The purpose of approve + transferFrom was described in solidity documentation at page 39:

Warning: There are some dangers in using send: The transfer fails if the call stack depth is at 1024 (this can always be forced by the caller) and it also fails if the recipient runs out of gas. So in order to make safe Ether transfers, always check the return value of send, use transfer or even better: use a pattern where the recipient withdraws the money

This was relevant at the moment of creating ERC20 token standard, but the stack depth attack was fixed through EIP #150 . As the result of this approve + transferFrom must be considere deprecated now.

I think that there is no need to develop and implement the approve / allowance mechanism because:

  1. approve + transferFrom is leading to monetary losses since it assumes another way to transfer tokens (And an alternative way to execute a transaction often does not implement handling)
  2. vulnerability to re-approval attack is described here
  3. approve is superfluous since common pattern of transactions handling is fallback function execution. It is already described in ERC #223

I'd like to recommend to remove decApprove / setApprove / getAllowance from the token standard because of described problems of this approach.

Dexaran commented Jul 17, 2017

You should keep in mind that ERC #20 token standard functions are leading to monetary losses. I wrote a number of articles about it (for example this one).

The main problem of ERC #20 token is that it has two ways of transferring funds:

  1. transfer
  2. approve + transferFrom

which assumes that first pattern is processed without handling by the receiver and the second pattern simulates transaction handling.

The purpose of approve + transferFrom was described in solidity documentation at page 39:

Warning: There are some dangers in using send: The transfer fails if the call stack depth is at 1024 (this can always be forced by the caller) and it also fails if the recipient runs out of gas. So in order to make safe Ether transfers, always check the return value of send, use transfer or even better: use a pattern where the recipient withdraws the money

This was relevant at the moment of creating ERC20 token standard, but the stack depth attack was fixed through EIP #150 . As the result of this approve + transferFrom must be considere deprecated now.

I think that there is no need to develop and implement the approve / allowance mechanism because:

  1. approve + transferFrom is leading to monetary losses since it assumes another way to transfer tokens (And an alternative way to execute a transaction often does not implement handling)
  2. vulnerability to re-approval attack is described here
  3. approve is superfluous since common pattern of transactions handling is fallback function execution. It is already described in ERC #223

I'd like to recommend to remove decApprove / setApprove / getAllowance from the token standard because of described problems of this approach.

@gislik

This comment has been minimized.

Show comment
Hide comment
@gislik

gislik Jul 17, 2017

@davux
I agree 💯 with your naming comments — coming up with good names is probably one of the hardest problems in software development :) I am however a bit confused since my implementation has an almost identical method calls to @chrisfranko version:

  • function addBalance(TokenStorage storage self, address to, uint amount)
  • function subBalance(TokenStorage storage self, address from, uint amount)

The purpose of those methods is to interact with the token storage (@chrisfranko calls this Balances.sol). As such these method names are actually pretty descriptive and while not a part of the ERC #20 they are used to implement the ERC20 methods, transfer and transferFrom. I'm willing to put my weight behind the names incBalance and decBalance.

Please let me know If I'm somehow misunderstanding your comment.

@Dexaran
When I was coming up with the the design for the token system I read the the ERC #223 thread and I was very impressed by your proposal. In fact I think your ideas solve many (if not most) of the problems discussed in the thread.

However it seems that ERC20 has already become the de facto standard even though it has not formally been accepted as an EIP. Both 0x and swap rely on the approve/transferFrom and in fact unless I'm misunderstanding something I think it's actually better to not send the 0x settlement contract my token with transfer (as suggested by ERC223) since I may want to cancel my trade and I don't understand how I would recover my token if I had already sent it away. How would you do that using ERC223 tokens?

I'm coming up with design ideas how to make my approve/transferFrom implementation safer but I didn't want to mix those ideas with the original presentation of the token system. However, one simple idea (inspired by ERC223) is to not allow transfering to contracts that don't implement the TokenRecipient. If the contract does indeed implement the interface, transfer would be equivalent of calling approveAndCall. Does this sound like a compromise that's worth exploring?

gislik commented Jul 17, 2017

@davux
I agree 💯 with your naming comments — coming up with good names is probably one of the hardest problems in software development :) I am however a bit confused since my implementation has an almost identical method calls to @chrisfranko version:

  • function addBalance(TokenStorage storage self, address to, uint amount)
  • function subBalance(TokenStorage storage self, address from, uint amount)

The purpose of those methods is to interact with the token storage (@chrisfranko calls this Balances.sol). As such these method names are actually pretty descriptive and while not a part of the ERC #20 they are used to implement the ERC20 methods, transfer and transferFrom. I'm willing to put my weight behind the names incBalance and decBalance.

Please let me know If I'm somehow misunderstanding your comment.

@Dexaran
When I was coming up with the the design for the token system I read the the ERC #223 thread and I was very impressed by your proposal. In fact I think your ideas solve many (if not most) of the problems discussed in the thread.

However it seems that ERC20 has already become the de facto standard even though it has not formally been accepted as an EIP. Both 0x and swap rely on the approve/transferFrom and in fact unless I'm misunderstanding something I think it's actually better to not send the 0x settlement contract my token with transfer (as suggested by ERC223) since I may want to cancel my trade and I don't understand how I would recover my token if I had already sent it away. How would you do that using ERC223 tokens?

I'm coming up with design ideas how to make my approve/transferFrom implementation safer but I didn't want to mix those ideas with the original presentation of the token system. However, one simple idea (inspired by ERC223) is to not allow transfering to contracts that don't implement the TokenRecipient. If the contract does indeed implement the interface, transfer would be equivalent of calling approveAndCall. Does this sound like a compromise that's worth exploring?

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Jul 18, 2017

@Dexaran
RE approve: I'm completely A-OK with your suggestion of removing the approve and transferFrom methods from this ERC. Let me read ERC223 more and ill make an ERC223 branch.

@gislik
Thats right.

chrisfranko commented Jul 18, 2017

@Dexaran
RE approve: I'm completely A-OK with your suggestion of removing the approve and transferFrom methods from this ERC. Let me read ERC223 more and ill make an ERC223 branch.

@gislik
Thats right.

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Jul 18, 2017

@davux It does. Anyone interfacing with the TokenStandard.sol contract will feel as if they are interfacing with regular ERC20 contracts.
incBalance and decBalance are methods in the Balances.sol contract.

chrisfranko commented Jul 18, 2017

@davux It does. Anyone interfacing with the TokenStandard.sol contract will feel as if they are interfacing with regular ERC20 contracts.
incBalance and decBalance are methods in the Balances.sol contract.

@Dexaran

This comment has been minimized.

Show comment
Hide comment
@Dexaran

Dexaran Jul 18, 2017

Both 0x and swap rely on the approve/transferFrom

I think that relying on mechanism that is leading to monetary losses for your users is very bad idea.

it seems that ERC20 has already become the de facto standard

Due to the fact that many developers use this standard without any research or understanding of the consequences. They don't care about the fact than their users will lose money.

Dexaran commented Jul 18, 2017

Both 0x and swap rely on the approve/transferFrom

I think that relying on mechanism that is leading to monetary losses for your users is very bad idea.

it seems that ERC20 has already become the de facto standard

Due to the fact that many developers use this standard without any research or understanding of the consequences. They don't care about the fact than their users will lose money.

@Dexaran

This comment has been minimized.

Show comment
Hide comment
@Dexaran

Dexaran Jul 18, 2017

I'm coming up with design ideas how to make my approve/transferFrom implementation safer

I think that it is possible to make approve / allowance mechanism safer but I think that it is not needed. I prefer to consider it deprecated because stack depth attack is already fixed (it is the only purpose of having approves. Approves are superfluous now).

Reasons:

  1. Irrational blockchain usage. Ethereum already has problems with network bandwidth. There is no need to introduce and use mechanisms which will cause extra blockchain bloating. Approve + transferFrom is a couple of two different transactions to perform a single action.

  2. Not user friendly. Can cause user mistakes.
    Why do we need two different functions (transfer and approveAndCall) to perform token transactions? Is here any advantages over having only transfer function to perform all transfers?

  3. More understandable for developers.
    Event handling and fallback executing is well-known method in programming. Approves are not.

Dexaran commented Jul 18, 2017

I'm coming up with design ideas how to make my approve/transferFrom implementation safer

I think that it is possible to make approve / allowance mechanism safer but I think that it is not needed. I prefer to consider it deprecated because stack depth attack is already fixed (it is the only purpose of having approves. Approves are superfluous now).

Reasons:

  1. Irrational blockchain usage. Ethereum already has problems with network bandwidth. There is no need to introduce and use mechanisms which will cause extra blockchain bloating. Approve + transferFrom is a couple of two different transactions to perform a single action.

  2. Not user friendly. Can cause user mistakes.
    Why do we need two different functions (transfer and approveAndCall) to perform token transactions? Is here any advantages over having only transfer function to perform all transfers?

  3. More understandable for developers.
    Event handling and fallback executing is well-known method in programming. Approves are not.

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Jul 18, 2017

Contributor

As mentioned in another EIP, this doesn't seem like something that should be an EIP. EIPs are not meant to be a source of best practices. They are meant to be a source of standardization of things that need or greatly benefit from standardization. This is not something that greatly benefits from standardization (even though it may be a best practice). I have other concerns with this EIP, but I'm going to leave them out of this discussion because this shouldn't be an EIP in the first place.

Contributor

MicahZoltu commented Jul 18, 2017

As mentioned in another EIP, this doesn't seem like something that should be an EIP. EIPs are not meant to be a source of best practices. They are meant to be a source of standardization of things that need or greatly benefit from standardization. This is not something that greatly benefits from standardization (even though it may be a best practice). I have other concerns with this EIP, but I'm going to leave them out of this discussion because this shouldn't be an EIP in the first place.

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Jul 19, 2017

@MicahZoltu I'm sorry you feel that way. Maybe you should make an EIP to define EIPs better because you seem to be the only one who knows exactly what one is! That sounds like it would be a better use of your time.

chrisfranko commented Jul 19, 2017

@MicahZoltu I'm sorry you feel that way. Maybe you should make an EIP to define EIPs better because you seem to be the only one who knows exactly what one is! That sounds like it would be a better use of your time.

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Jul 19, 2017

#16

Reaches the conclusion that token standards do indeed belong as an EIP. -shrug-

chrisfranko commented Jul 19, 2017

#16

Reaches the conclusion that token standards do indeed belong as an EIP. -shrug-

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Jul 22, 2017

Contributor

There is great value in a standard token interface. However, there is significantly less value in a standard mechanism for the mechanism by which token contracts are upgraded. The reason for this difference is because there are a lot of tokens and there are a number of people building user-facing tools/utilities that interface with tokens (block explorers, node UIs, signer UIs, wallets, etc.). However, for contract upgrade mechanisms there are very few people (no one?) writing generalized tools for token management and the users of these tools would not be end-users but instead far more tech savvy developers. On top of that, the token author can simply choose the token implementation that best aligns with his tool suite of choice, unlike the token user who doesn't get to choose the token contract they use but would still like to choose their tooling.

Contributor

MicahZoltu commented Jul 22, 2017

There is great value in a standard token interface. However, there is significantly less value in a standard mechanism for the mechanism by which token contracts are upgraded. The reason for this difference is because there are a lot of tokens and there are a number of people building user-facing tools/utilities that interface with tokens (block explorers, node UIs, signer UIs, wallets, etc.). However, for contract upgrade mechanisms there are very few people (no one?) writing generalized tools for token management and the users of these tools would not be end-users but instead far more tech savvy developers. On top of that, the token author can simply choose the token implementation that best aligns with his tool suite of choice, unlike the token user who doesn't get to choose the token contract they use but would still like to choose their tooling.

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Jul 22, 2017

"However, for contract upgrade mechanisms there are very few people (no one?)"

That's the problem, there are very few people who actually give a damn about the future of the billion dollar assets they are launching on ethereum. Furthermore, I am working on tooling for it. Hence why I shared this ERC.

And that's quite the assumption that only "tech savvy people" would use token management tools. You are right the token author CAN simply choose the token implementation of his choice if everything is modularized that is.

Thank you for your comment on this request for comment.

chrisfranko commented Jul 22, 2017

"However, for contract upgrade mechanisms there are very few people (no one?)"

That's the problem, there are very few people who actually give a damn about the future of the billion dollar assets they are launching on ethereum. Furthermore, I am working on tooling for it. Hence why I shared this ERC.

And that's quite the assumption that only "tech savvy people" would use token management tools. You are right the token author CAN simply choose the token implementation of his choice if everything is modularized that is.

Thank you for your comment on this request for comment.

@igordata

This comment has been minimized.

Show comment
Hide comment
@igordata

igordata Aug 23, 2017

I was wandering how one could upgrade the contract. I see some contracts have flaws in security.

I want to say, it would be great to have solution for upgrade contracts, and I'm interested in such solution.

I'm happy to see you Chris are putting an effort in developing upgradeable contracts!

igordata commented Aug 23, 2017

I was wandering how one could upgrade the contract. I see some contracts have flaws in security.

I want to say, it would be great to have solution for upgrade contracts, and I'm interested in such solution.

I'm happy to see you Chris are putting an effort in developing upgradeable contracts!

@Saahiljeet-Singh

This comment has been minimized.

Show comment
Hide comment
@Saahiljeet-Singh

Saahiljeet-Singh Aug 24, 2017

I agree with @igordata .
Hey @chrisfranko : could you elaborate how could one upgrade a single module ( say a solidity file ) without impacting the others. Even if we change only the definitions keeping the interfaces intact, redeployment would still be an issue.

Saahiljeet-Singh commented Aug 24, 2017

I agree with @igordata .
Hey @chrisfranko : could you elaborate how could one upgrade a single module ( say a solidity file ) without impacting the others. Even if we change only the definitions keeping the interfaces intact, redeployment would still be an issue.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Sep 5, 2017

Collaborator

One thing to bear in mind: Implementing a generic upgrade mechanism like this opens users to the need to trust the token creator indefinitely (since they could upgrade to an 'unfair) token implementation.

@Dexaran I think that it is possible to make approve / allowance mechanism safer but I think that it is not needed. I prefer to consider it deprecated because stack depth attack is already fixed (it is the only purpose of having approves. Approves are superfluous now).

This is untrue. If you remove approve from ERC20, there is no way to transfer tokens to a contract such that the token knows who sent them the tokens.

Collaborator

Arachnid commented Sep 5, 2017

One thing to bear in mind: Implementing a generic upgrade mechanism like this opens users to the need to trust the token creator indefinitely (since they could upgrade to an 'unfair) token implementation.

@Dexaran I think that it is possible to make approve / allowance mechanism safer but I think that it is not needed. I prefer to consider it deprecated because stack depth attack is already fixed (it is the only purpose of having approves. Approves are superfluous now).

This is untrue. If you remove approve from ERC20, there is no way to transfer tokens to a contract such that the token knows who sent them the tokens.

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Sep 5, 2017

chrisfranko commented Sep 5, 2017

@Dexaran

This comment has been minimized.

Show comment
Hide comment
@Dexaran

Dexaran Sep 5, 2017

@Arachnid

This is untrue. If you remove approve from ERC20, there is no way to transfer tokens to a contract such that the token knows who sent them the tokens.

approve doesn't introduce any functionality that can't be implemented by token fallbacks execution without approves.
By the way, event handling function execution is a standard practice in programming (event handling) unlike approve + transferFrom mechanism that requires twice more transactions to make a token transaction and results in loss of money as well.

Dexaran commented Sep 5, 2017

@Arachnid

This is untrue. If you remove approve from ERC20, there is no way to transfer tokens to a contract such that the token knows who sent them the tokens.

approve doesn't introduce any functionality that can't be implemented by token fallbacks execution without approves.
By the way, event handling function execution is a standard practice in programming (event handling) unlike approve + transferFrom mechanism that requires twice more transactions to make a token transaction and results in loss of money as well.

@Arachnid

This comment has been minimized.

Show comment
Hide comment
@Arachnid

Arachnid Sep 5, 2017

Collaborator

approve doesn't introduce any functionality that can't be implemented by token fallbacks execution without approves.

There are use-cases that are possible with approve but not fallbacks, though I don't find them particularly compelling. The issue I was raising is that you were suggesting that removing approve without any other changes would not eliminate any use-cases; it definitely would.

Collaborator

Arachnid commented Sep 5, 2017

approve doesn't introduce any functionality that can't be implemented by token fallbacks execution without approves.

There are use-cases that are possible with approve but not fallbacks, though I don't find them particularly compelling. The issue I was raising is that you were suggesting that removing approve without any other changes would not eliminate any use-cases; it definitely would.

@Dexaran

This comment has been minimized.

Show comment
Hide comment
@Dexaran

Dexaran Sep 5, 2017

The issue I was raising is that you were suggesting that removing approve without any other changes would not eliminate any use-cases; it definitely would.

I agree, if you just exclude approves from the default ERC20 token then it will eliminate some use-cases.
I suggested an alternative standard with alternative ways of doing the same thing that approves do, but without loss of money.

Dexaran commented Sep 5, 2017

The issue I was raising is that you were suggesting that removing approve without any other changes would not eliminate any use-cases; it definitely would.

I agree, if you just exclude approves from the default ERC20 token then it will eliminate some use-cases.
I suggested an alternative standard with alternative ways of doing the same thing that approves do, but without loss of money.

@debkundu

This comment has been minimized.

Show comment
Hide comment
@debkundu

debkundu Sep 13, 2017

@Arachnid One thing to bear in mind: Implementing a generic upgrade mechanism like this opens users to the need to trust the token creator indefinitely (since they could upgrade to an 'unfair) token implementation.

@chrisfranko Yes you are correct Nick. A more ideal approach would be to have a
democratic DAO control the root address of Balances.sol

Agreed. Security, trust and transparency are of great importance in the business of token management in a democratic manner. Users cannot take the token creator indefinitely when it comes to activities like - incTotalSupply, decTotalSupply. So, so should we add another two items to the cart - (i) Token Governance body and (ii) Voting on token management issues? Something like an Association contract, that uses mintable token owned by a congress finally owned by a single account (https://www.ethereum.org/dao#the-shareholder-association). Thoughts welcome.

debkundu commented Sep 13, 2017

@Arachnid One thing to bear in mind: Implementing a generic upgrade mechanism like this opens users to the need to trust the token creator indefinitely (since they could upgrade to an 'unfair) token implementation.

@chrisfranko Yes you are correct Nick. A more ideal approach would be to have a
democratic DAO control the root address of Balances.sol

Agreed. Security, trust and transparency are of great importance in the business of token management in a democratic manner. Users cannot take the token creator indefinitely when it comes to activities like - incTotalSupply, decTotalSupply. So, so should we add another two items to the cart - (i) Token Governance body and (ii) Voting on token management issues? Something like an Association contract, that uses mintable token owned by a congress finally owned by a single account (https://www.ethereum.org/dao#the-shareholder-association). Thoughts welcome.

@MicahZoltu

This comment has been minimized.

Show comment
Hide comment
@MicahZoltu

MicahZoltu Sep 13, 2017

Contributor

Democratic mutability opens the system up to a Sybil attack against the governance system, which can be an even higher risk than centralized management. In general, I advise projects against upgradability outside of their beta. During beta I generally recommend a simple multi-sig upgrade mechanism as that introduces a clear target of trust and doesn't put the system at risk of a non-state attack from any party outside of the multisig.

Contributor

MicahZoltu commented Sep 13, 2017

Democratic mutability opens the system up to a Sybil attack against the governance system, which can be an even higher risk than centralized management. In general, I advise projects against upgradability outside of their beta. During beta I generally recommend a simple multi-sig upgrade mechanism as that introduces a clear target of trust and doesn't put the system at risk of a non-state attack from any party outside of the multisig.

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Sep 13, 2017

chrisfranko commented Sep 13, 2017

@micah

This comment has been minimized.

Show comment
Hide comment
@micah

micah Sep 13, 2017

micah commented Sep 13, 2017

@kylerchin

This comment has been minimized.

Show comment
Hide comment
@kylerchin

kylerchin Sep 26, 2017

@Dexaran @chrisfranko I am looking for a token standard that allows for upgradability to the token code in the future and is able to be stored in a contract. How would I approach this problem? Do I just use the ERC223 recommended code and just slot in the Balances.sol code?

kylerchin commented Sep 26, 2017

@Dexaran @chrisfranko I am looking for a token standard that allows for upgradability to the token code in the future and is able to be stored in a contract. How would I approach this problem? Do I just use the ERC223 recommended code and just slot in the Balances.sol code?

@facundomedica

This comment has been minimized.

Show comment
Hide comment
@facundomedica

facundomedica Mar 16, 2018

@chrisfranko Is this line ok? https://github.com/expanse-org/Tokens/blob/master/Token_Contracts/contracts/StandardToken.sol#L34 it should get the balance and decrease it for the _from no the message sender.

facundomedica commented Mar 16, 2018

@chrisfranko Is this line ok? https://github.com/expanse-org/Tokens/blob/master/Token_Contracts/contracts/StandardToken.sol#L34 it should get the balance and decrease it for the _from no the message sender.

@chrisfranko

This comment has been minimized.

Show comment
Hide comment
@chrisfranko

chrisfranko Mar 17, 2018

chrisfranko commented Mar 17, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment