2
If external function declarations are saving gas, why aren't we using it for the transfer functions?
The ERC20 specification states that they should be public instead of external. It does violate the ERC20 specification if you mark them as external.
However, in practice this should not be an issue. The difference between external and public functions are that in public functions, the call data is copied to memory first. In external functions, the data is ...
2
You should be aware that smart contracts on ethereum cannot interact directly with the outside world. So you will never have a token that reflect instantly the price of real world goods.
It is possible however to use oracles to keep the price reasonably updated. This can be done through a centralized authority or decentralized one.
For example DAI and USC ...
1
ERC20 and ERC721 are, by definition, interfaces.
You cannot attach extra data to the prescribed functions, e.g. transfer() because that will break compatibility with the standard interface.
You didn't say what you want to achieve so it's not possible to be specific about the solution. Two common approaches spring to mind.
ERC20 is for fungible assets - ...
1
Typically the one who signs a transaction also pays for the transaction. However, this doesn't have to be the case.
What you are looking for is something called meta transactions. A user signs a transaction he wishes to send to the blockchain and then hands the transaction to a third party which actually sends the transaction for the user (and pays for the ...
1
The token supports only the functionality written into the token's smart contract. I'm not sure what you mean with "lock" but most likely that is not possible unless you have originally coded such functionality inside the contract.
If it's a basic ERC20 contract with no extra functionality then there's very little you can do about the tokens. Depends a bit ...
Only top voted, non community-wiki answers of a minimum length are eligible
