On our exchange we do not do “eth wrapping”, we natively support ETH and ETC and save money for our traders, unlike ddex and 0x relayers.
Those were probably ERC223 tokens. For ERC20 tokens you’d have to approve them. Try making a DAI sell order and you’ll see it in action.
This is not entirely true. Sure, when you make orders or take orders the bulk of the gas fee is paid for the DEX execution - that’s why we have worked hard on optimizing gas price as much as we could to save money for our traders. For example, if you cancel your order or if you buy full order up to the limit so it is fulfilled, our smart contract will actually refund you gas so your transaction gets 50% cheaper, similarly to how GasToken works.
However, when you do ERC20 Approve transaction, that is the definition of interacting with your token, and thus whatever gas costs are incurred are 100% responsibility of your smart contract. The DEX smart contract is not used in this transaction at all, only its address.
That’s fine, variable supply tokens are supported as well. As long as the approved amount is larger than what any one user holds they should be able to trade without any problem.
It’s not how much you spend, but it is the professionals you buy the services from. Clearly it is worth to buy smart contract audit service from experts such as ourselves, instead of whoever you paid thousands for and who left you with that issue.
I have reviewed the changes you made in your
approve method that were causing integration issues. Namely you removed the following lines
require(tokens <= balances[msg.sender]);
require(tokens >= 0);
require(allowed[msg.sender][spender] == 0 || tokens == 0);
Second line of this is redundant and will simply incur gas fees on every use of this method.
tokens is already defined as an unsigned int, meaning it can only be 0 or positive.
Third line is normally redundant too. ERC20 standard does not require this check, you are simply putting an extra limitation on its functionality, limiting your token’s adoption.
First line is the one that was causing problems with our DEX, as we ask to approve full token supply instead of your current supply. If we did that then every trade would require two transactions instead of one and that would be a horrible user experience. There is simply no way around that with ERC20, that’s why we use ERC223 for our tokens. Most dapps and other DEXs follow suit and do the same thing, although some do allow you to do the two-click trading flow.
I’m glad your upgraded token removed these three lines and made it more compatible with dapps - I’m sure your community will love it.
If you want me to look over the rest of your contract and fix any other issues I might discover it is best to do so early, before your token adoption grows huge and doing a token migration will be a pain to do.