We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged

44

3 Primary improvements with ERC223 Eliminates the problem of lost tokens which happens during the transfer of ERC20 tokens to a contract (when people mistakenly use the instructions for sending tokens to a wallet). ERC223 allows users to send their tokens to either wallet or contract with the same function transfer, thereby eliminating the potential for ...


5

Taking an informal look: The ConsenSys contract is very basic and does not use safe maths operations. I wouldn't use this. OpenZeppelin features lots of different token types, which provides flexibility, and has had a relatively high amount of scrutiny. It looks like a good basis to base your token on. My understanding is that the ERC223 standard is not ...


4

ERC-223 is a proposal right now, not a standard. See the proposal discussion. There are several concerns brought up, including that a new proposal should involve a round-table with more ERC-20 authors to collect feedback. ERC-20 is the standard to follow for new tokens.


4

You may be interested in an implementation of ERC223 forked from OpenZeppelin.


4

Any smart contract wanting to interact with an ERC223 token is supposed to implement the tokenFallback() function to handle incoming token transfers. Those 2 lines call that function on the target account (if it is a smart contract) so, the target smart contract MUST have previously implemented the tokenFallback() function. As can be seen in the example ...


3

In a smart contract written in solidity, there exists the payable modifier which allows the sender to attach Ether to a transaction which will be accepted by the contract as a fee for providing its service. There is no predefined modifier that would allow the same functionality for any ERC20 compliant token. However, you can achieve this functionality by ...


3

Yes, you can use call. E.g.: addr.call(keccak256("tokenFallback(address,amount,bytes)"), from, amount, data); call returns true or false indicating success or failure of the call. You can just ignore it if you don't care whether the call succeeds. Of course, as I understand it, the entire purpose of ERC 223 is to make sure that the transfer is reverted if ...


3

You can have a few shared addresses where you consolidate several transfers and have a single transfer instead. It can be complex to manage to which user the tokens have to be credited. A user can send tokens to a previous address without requesting authorization. IMHO the easiest is to generate a custom address per user. You will have to pay the ether for ...


3

1) Matching the ERC777TokensRecipient interface is optional. More specifically, one single ERC1820 registry is deployed on most Ethereum networks, always at the same address: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24. The ERC1820 registry contains a mapping from addresses to contract addresses verifying the ERC777TokensRecipient interface. Those ...


3

Firstly, I assume you mean a smart contract you will deploy, as you can't change the functionality of one already deployed. With ERC20, there is no function triggered on your contract when it receives tokens, the token contract itself is all that gets called. To detect the change you would need some external program to monitor the blockchain for relevant ...


3

This is a limitation of ERC20. When Alice pays Bob, she sends a transaction to the token contract to make an accounting entry. There is no standard method for the token contract to inform Bob. The allow/transferFrom flow resolves it with a 2-step process - first authorize Bob to take from Alice, then inform Bob. Since Bob is in the loop, Bob can do what ...


2

If the recipient is a contract it invokes a callback function after making the transfer of tokens function transfer(address _to, uint _amount, bytes _data) public { // Standard transfer balances[msg.sender] = balances[msg.sender].sub(_amount); balances[_to] = balances[_to].add(_amount); // If recipient is a contract invoke token callback ...


2

It is not that bad to have two events. The event names are similar but their signature is very different. A wallet should only use the signature to refer an event. Transfer(address,address,uint256) has signature 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef Transfer(address,address,uint256,bytes) ...


2

It's the same as fallback functions for Ether. from the docs: ERC223 tokens should be sent by calling transfer function on token contract with no difference is receiver a contract or a wallet address. If the receiver is a wallet ERC223 token transfer will be same to ERC20 transfer. If the receiver is a contract ERC223 token contract will try to ...


2

You're correct that msg.sender in the receiver will be the address of a token contract. This is why the first parameter to tokenFallback is the address of the original sender: for a compliant ERC223 token, the receiver knows the original sender by this first parameter. https://github.com/ethereum/EIPs/issues/223 mentions these points: Contract to work ...


2

There's a bracket (}) missing: change function approveAndCall(address _spender, uint256 _value, bytes _extraData) public returns (bool success) { tokenRecipient spender = tokenRecipient(_spender); if (approve(_spender, _value)) { spender.receiveApproval(msg.sender, _value, this, _extraData); return true; } to function ...


2

assert(_to.call.value(0)(bytes4(keccak256(_custom_fallback)), msg.sender, _value, _data)); what is the main working of this assert() and their arguments? This assert is calling a function of _to (when it is a contract) passed as a parameter in transfer and checking the return value as true. bytes4(keccak256(_custom_fallback)) is used to select the ...


2

Its not about why divide by 1000. This can be any no raised to power 10. The reason behind such division is You can not use decimals in smart contracts and hence what if you want to have have x % of fee ? You need to use logic fee = amount * x / 100; But them the min value of x is 1. So if you want your x to be as low as 0.1, you can use: fee = ...


2

Ended up with an ERC223 implementation :) Thanks ! pragma solidity ^0.5.2; /** * @title SafeMath * @dev Unsigned math operations with safety checks that revert on error. */ library SafeMath { /** * @dev Multiplies two unsigned integers, reverts on overflow. */ function mul(uint256 a, uint256 b) internal pure returns (uint256) { ...


2

It isn't especially obvious at first. A contract can easily accept and transact with ERC20 tokens. However, a contract cannot do anything it wasn't designed to do in advance of deployment. While it's easy to say that contract is an address and it can theoretically forward tokens, in practice, it may not know how. Contracts do not perform arbitrary actions ...


2

In current understanding, Serenity will be a separate blockchain, so no contracts will automatically migrate from current Ethereum to Serenity. New token contracts deployed on Serenity will probably require new standard interfaces, different from EIP20/EIP223 etc., though it is too early to tell what exactly the differences will be. Serenity will have a ...


2

It would help to see what you are reading. ERC223 uses a tokenfallback function. In some cases it might be acceptable to accept any token, any amount. Perhaps a general-purpose wallet. In other cases it would make sense to reject everything except acceptable tokens in the correct amount, e.g. fees of some kind. Both are valid use-cases so it makes sense ...


2

ERC20 as defined here has a function called approveAndCall this allows to make the two steps in a single transaction. The function is: function approveAndCall(address spender, uint tokens, bytes memory data) public returns (bool success) { allowed[msg.sender][spender] = tokens; emit Approval(msg.sender, spender, tokens); ...


2

Try this: https://coinmarketcap.com/tokens/ They are listed by market cap which might be a good indicator. is mostly outdated and can't get compiled any more with latest solidity compiler versions That doesn't make sense. Contracts don't get outdated. Bytecode remains on the chain. Only the compiler evolves and with it the Solidity language (the most ...


2

Alright, y'all are lazy so I did it myself. This is a super rough estimate. Here's a gist of my script to get all the function names in the top 1000 'verified contracts' on etherscan. The script downloads the abis for all the top contracts and checks for the existence of functions with the names in the following list: ['transfer(with bytes)', '...


1

ERC-223 helps to stop the loss of tokens (e.g. in case they were sent to the non-compatible or wrong contract). It also consumes less gas since the token transfer is a one-step process (instead of 2 steps in ERC-20). However, take into consideration the ATN incident that happened on March 5th, 2017. ERC-223 ATN incident


1

ERC-223 is backwards compatible with ERC-20 and provides a couple of nice safety measures. I would go for ERC-223.


1

If you use the ERC20 Token Standard you get to define the totalSupply as a part of the contract creation. So these tokens do not need to be mined, they will simply all exist as soon as you create the contract.


Only top voted, non community-wiki answers of a minimum length are eligible