Send to my .chain name going to invalid address

I sent a few transactions to Josh.chain but they went to

This is not where the pointer is set. How to fix? And is there any way to recover the tokens sent to this address?

This problem has existed for a long time and has not been solved. This can only be a middleware problem, but in fact, AE has arrived josh.chain Pointer address, you can record the current balance for another verification.

1 Like

So the funds are lost?

@Kryztoval maybe you can help? Thanks a million if you can. I set the pointer to another address today and it seemed to work oddly enough

The fund is safe. In fact, the fund is still sent to the set pointer address, but the query record is not the pointer address you set, so you can record the pointer address first, and then send small amount for verification. In other words, the fund is safe. You are not the first to discuss this issue in the forum.

Let’s ask one of the seed nodes about this… returns:

{"id" : "nm_24BFfnW5a97SS49e3faJaLkruJtwafgKa4G4pLk7B6JpfLV8G6",
 "pointers" : [{"id":"ak_21WFPXaLgtGv7DYA5FkYj1E7XyVfNn4sUFts72axzqYKT6nJYH", 

So spending to Josh.chain will send funds to ak_21WFPXaLgtGv7DYA5FkYj1E7XyVfNn4sUFts72axzqYKT6nJYH

I changed the pointer to my superhero wallet so I could claim a tip. It worked sending to Josh. Chain there. I still don’t know how to get the funds that went to that invalid address

I don’t follow, but yes, now the pointer is changed to ak_u2gFpRN5nABqfqb5Q3BkuHCf8c7ytcmqovZ6VyKwxmVNE5jqa

Only the holder of the account ak_21WFPXaLgtGv7DYA5FkYj1E7XyVfNn4sUFts72axzqYKT6nJYH can move those funds.

Try sending a small amount to Josh. Chain. It goes to that address instead of the one that the pointer is set to.

I spent a fair bit on Josh. Chain and now I have lost 60 tokens trying to send to Josh. Chen :sob:

Which address is “that address” and which one do you expect it to end up at? If you could be a bit more precise, and if you could also provide the transaction(-hash) that doesn’t behave like you think it should I’ll have a look!

Sorry, I will clarify.
Josh.chain is pointing to


Here is one of the tx hash’s


You can find the weird destination from the tx hash I hope.

Well, the destination is the name hash for josh.chain, i.e. nm_24BFfnW5a97SS49e3faJaLkruJtwafgKa4G4pLk7B6JpfLV8G6 - that looks correct to me?!

I’m quite sure the tokens ended up on ak_u2gF..., I’m not at my work laptop right now so I can’t confirm. The problem is that neither aeternal nor the middleware properly tracks these transactions so it is hard to verify for sure.

Ok so I’m not crazy lol. Thanks for looking into this on a Saturday. Please let me know when you are on your work laptop if you have time.
If this is indeed a bug, and there is a bug bounty program, I would be happy if I can get reimbursed for the roughly 60 tokens that went to the wrong place.

1 Like

I’m back home now…

So transaction th_yovuCciLHsnq7DhYer8nGBRxaeMnMHd4RUb3Est5viDkYknTf transfers 50 AE tokens from ak_21WFPXaLgtGv7DYA5FkYj1E7XyVfNn4sUFts72axzqYKT6nJYH to nm_24BFfnW5a97SS49e3faJaLkruJtwafgKa4G4pLk7B6JpfLV8G6. The transaction fee is 16840000000000 aetto. The name points to ak_u2gFpRN5nABqfqb5Q3BkuHCf8c7ytcmqovZ6VyKwxmVNE5jqa so that is where we expect the 50 AE to end up.

So I’ve defined a little function that checks how much the balance of an account changes in a generation, let’s use this (the transaction took place at height 264312):

([email protected])24> BalanceDiff = 
([email protected])24>   fun(Height, Addr) ->
([email protected])24>     {ok, PK} = aeser_api_encoder:safe_decode(account_pubkey, Addr),
([email protected])24>     B1 = aec_accounts:balance(element(2, aec_chain:get_account_at_height(PK, Height))),
([email protected])24>     B2 = aec_accounts:balance(element(2, aec_chain:get_account_at_height(PK, Height+1))),
([email protected])24>     (B2 - B1) / 1000000000000000000
([email protected])24>   end.
([email protected])25> BalanceDiff(264312, <<"ak_u2gFpRN5nABqfqb5Q3BkuHCf8c7ytcmqovZ6VyKwxmVNE5jqa">>).                     
([email protected])26> BalanceDiff(264312, <<"ak_21WFPXaLgtGv7DYA5FkYj1E7XyVfNn4sUFts72axzqYKT6nJYH">>). 

So the sender account had the balance decreasing by 50 AE + Fee (and we also show why blockchains don’t do floating point numbers :slight_smile: ) and the account that the name points to saw a balance increase of 50 AE.

So, it seems to have worked exactly as it should :man_shrugging: No tokens were lost, and all is good.

1 Like

Okay I just did a test send and my balance was updated so I guess the tokens weren’t lost thankfully. I don’t know why these transactions aren’t showing up in my history on the base app.
Anyway, thank you very much and have a good weekend

1 Like

the problem is that the middleware is currently not capable to extract those information. hopefully it will soon get replaced by the new middleware and display all relevant data.

I suggest you to track these issues to be informed about that:

there is currently also a bug in the (old) middleware that it doesn’t return the active auctions for names. so you currently are not able to track running auctions in an easy way.

1 Like

It seems that the Base aepp sends token to the nm_hash directly, and the token will be sent to the owner of the AENS name, not the pointer of the AENS name.

So aeknow tracks the tx directly and gives a temporary solution to list the tx:

Wow, I didn’t know receiver could be a “mn_” address, I need to fix that in my mdw.

You can go to my middleware with the transaction hash

and pass it to the address list, and it will filter all ammounts sent to the name hash, however it does not know rigfht now what name is at what hash.

I’m trying to think how to implement a rolling balance and resolving the names backwards.