How do I post OTC orders for ERC223 tokens?

erc223

#1

Anyone know how to do this? I tried on 0x Protocol directly and submitted 8 sell orders for an ERC223 token and when you try to buy and sign for the order it gives and error message.


#2

Could you share some more details? Can’t assist you with the information you have provided so far.

Mind that you cannot buy the order you have created yourself.


#3

Trying to get a market started for Sweetcoin (SWC) https://www.saturn.network/exchange/ETH/token/0xff32d68d8a4608fba6b51f07d1f138a63a149211

On 0x as a test I posted the sell order on one address and tried to buy on a different address

Just tried to post a couple sell orders on Saturn for SWC and they’re not showing up on the order book. (showing stuck pending on etherscan)


#4

Did you set a high enough gas limit? Seems to be working fine for me, I just created an order.

https://www.saturn.network/exchange/ETH/order-book/0xff32d68d8a4608fba6b51f07d1f138a63a149211/0x0000000000000000000000000000000000000000

Are you using MetaMask or Saturn Wallet?

Thanks!


#5

Yes, I’m using metamask and I’m paying Gas Price 3 with 1,000,000 Gas Limit and my sell orders still get rejected. For some reason metamask keeps showing a message each time before I confirm the transaction that says “ALERT: Transaction Error. Exception thrown in contract code.”


#6

For some reason it lets you post buy orders, but kicks off an error and fails when you try and post a sell order


#7

Thanks! I have let Saturn DEVs know, let’s wait and see what they say :slight_smile:


#8

This is some of the most convoluted and illegible code for a token I have ever seen in my life. It is very hard to tell what is going on there and why a simple token warrants to have such incredible and unnecessary complexity.

These reservations aside, I have managed to figure out what the issue is.

function transfer(address dst, uint256 wad) public stoppable returns (bool) {
        bool retVal = logic.transfer(msg.sender, dst, wad);
        if (retVal) {
            uint codeLength;
            assembly {
            // Retrieve the size of the code on target address, this needs assembly .
                codeLength := extcodesize(dst)
            }
            if (codeLength>0) {
                ERC223ReceivingContract receiver = ERC223ReceivingContract(dst);
                bytes memory empty;
                receiver.tokenFallback(msg.sender, wad, empty);
            }

            Transfer(msg.sender, dst, wad);
        }
        return retVal;
    }

    function transferFrom(address src, address dst, uint256 wad) public stoppable returns (bool) {
        bool retVal = logic.transferFrom(src, dst, wad);
        if (retVal) {
            uint codeLength;
            assembly {
            // Retrieve the size of the code on target address, this needs assembly .
                codeLength := extcodesize(dst)
            }
            if (codeLength>0) {
                ERC223ReceivingContract receiver = ERC223ReceivingContract(dst);
                bytes memory empty;
                receiver.tokenFallback(src, wad, empty);
            }

            Transfer(src, dst, wad);
        }
        return retVal;
    }

    function approve(address guy, uint256 wad) public stoppable returns (bool) {
        bool ok = logic.approve(msg.sender, guy, wad);
        if (ok)
            Approval(msg.sender, guy, wad);
        return ok;
    }

Notice the ERC223 methods being stuck inside the transferFrom which belongs to ERC20 spec. This token is also not ERC223 compatible, so it is impossible to list it as an ERC223 token either.

I am sure token devs had best intentions in mind, but is sounds like they were not able to properly manage this complexity and have rendered this token to be completely unusable by smart contracts that support ERC223 standard, and potentially have introduced bugs to smart contracts that deal with ERC20.

In short, I would argue that one needs to be very careful when implementing standards and keep improvization to a minimum, otherwise issues like these will arise.

@ryancharleston have you tried listing on other DEXs? I wonder if ERC20-only DEXs are able to work with your token.


#9

Wow, this sucks.

I tried listing SWC on 0x Project but it didn’t work there either.


#10

The best solution is picking either a stable ERC20 or a stable ERC223 implementation, for example this one

and then airdropping the new token to old SWC holders. Kind of like doing a token hard-fork. The new token should be tradable on Saturn. You can use this free airdrop tool


#11

Thanks, I just brought this to the attention of someone at Sweetbridge.


#12

Here’s a response I got from Sweetbridge RE: Sweetcoin token contract…

We wanted to keep the token implementation both secure and
The plain ERC20 token has plenty of issues, mainly:

  1. Mentioned earlier - tokens can be accidentally inside contracts.
  2. Inability of handling incoming token transactions. ERC20 token contract is
    not notifying receiver that transaction occurs.

Over the time there were few approaches to overcome this: ERC223, ERC777 and ERC827. The latter one was proposed 11 Jan 2018. We focused on ERC223 because this is what was on the top by that time.

We didn’t implement ERC223 (eg: we didn’t add data parameter) because we
didn’t want to break ERC20 interface so our token is in fact a ERC20 token! We
added the aforementioned callback functionality to the transfer function. This
allows contract developers to handle incoming token transactions.

As a consequence, contract-contract communication requiring transfer and callback requires one transaction, instead of 2 asynchronous ones: approve :
transferFrom (which in fact could end up in a stale mode). This is also
something which we use still use in our Vault contract and has been using in
the SWCQueue contract.


#13

As I said, noble goals but poor implementation. The token contract is neither ERC20 nor ERC223 and is not listable by any DEX known to me.