Dev any answer from other exchanges(shapeshift..)? Cryptopia can be a solution but i don't know if we can gather fast fee to pay.
Do you want to rewrite full code for TME or for new lending tokens?
No word from Shapeshift yet.
I think at some point renaming TME and making it fully ERC-20 compatible will save a lot of trouble later on. Shouldn't be a problem for places like Cryptopia or Livecoin, but in the long run will be a good idea.
The lending token service is being developed.
Add a compatibility function to etherdelta.github.io in the smart contract and restart it with saving balances! Let the old smart contract die on the sly, and the new one in a long swim!
I agree, let's help the Dev recode the token to get it up and running again!
You can output TME to etherdelta through the intermediary currency. This is a simple smart two-way exchange contract. I could write and deploy it.
You traded your TME for this 1: 1 token, put it up for auction, and sold it. The buyer turned to this smart contract and changed the purchased tokens for an equal amount of TME
Thank you all for the suggestions, input and support.
On the suggestion:
The buyer turned to this smart contract and changed the purchased tokens for an equal amount of TMEWhy not just let the converted tokens remain in the new token? I don't see any advantage to having them convert back to TME. The situation with Nova provides another reason to do so (more on this below).Overtime, all TME will get converted via the 1:1 contract. Anytime a genesis holder wishes to produce the compatible token, they just produce it as TME and then convert it. For reasons discussed below (exchanges not understanding TME's genesis algorithm) I believe this may be best.
The issue with Nova is not a bug in the TME contract. Rather, it is a consequence of an exchange balance scanner not being able to account for the batch generation:
Here is an email from Nova:
Hi!
This is a good example of the problem:
https://ethplorer.io/address/0x3bbb0f94d87497abea56feb483aff0e3ea99d69c
The main problem is that the function that returns the balance from the contract does not seem to be reliable.
In the case with the transaction above we did detect three deposits as stated below:
1000.00000000
12515.56434313
12515.56434313
The way we handle deposits is the same as many other exchanges. It is done in two steps, first scanning blocks and in second step after a number of blocks/confirmations we ask the contract of the balance and your contract does not answer this reliably like the other ERC20 tokens we have listed.When a batch is spawned, the exchange balance checker thinks the contract made an error, but in reality a genesis holder has spawned a batch. Thinking about an edge case where an exchange address were a child address, or the exchange scanned through transactions of a child address, the confusion is understandable.I propose to use ANTIMANIA's solution with a slight alteration: TME sent is burned, and a new token is produced. The eccentricity of TME's production algorithm means that we should issue a new token that has a predictable balanceOf() function and is made by converting TME. Those scanners do not understand and cannot account for (without additional teaching) TME's production algorithm; TME basically comes out of thin air at certain addresses.ANTIMANIA, if you want to write one as you've suggested, that would be very helpful--I was hoping to work on the service currently. If you can, post a link to a repo so everyone can take a look before upload.
I do have a proposal for a new name which I think is an improvement (and could be the name of the converted token), so I may post on that sometime soon.
I am a genesis holder myself and this sh*t keeps getting exciting. I am no technical guy regarding smart contracts but good thing we have people here willing to do such task in making TME more stronger and much better. +respect 
, but I'm sure the dev appreciates your input.