A community member has flagged a transaction that might involve double-spending/minting.
The user has received 10’295 eMaid on his wallet (somehow linked to an old transaction) and was kind enough to inform us. He has also offered to burn the equivalent amount on a different address.
It seems like a very random and isolated incident, but just to be on the safe side, we have decided to halt the automated co-signing process for a few days so we take time to investigate what has happened.
Great to see you reacting promptly!
Definitely good to see the prompt action, and also it’s greatly appreciated that you posted it here rather than brushing it under the carpet, even though it may easily have gone unnoticed!
There is still more burned maid than eMaid.
It looks like a burn from Bittrex (1DUb2YYbQA1jjaNYzVXLZ7ZioEhLXtbUru) occurred recently for 20,015 maid. here
Looking back at the history, it looks like that Ethereum address was issued 150 eMaid after burning directly from Bittrex (1DUb2YYbQA1jjaNYzVXLZ7ZioEhLXtbUru). here I could be wrong.
Maybe that is the reason why that particular user was chosen for the mint? Why the system minted the amount 10’295 eMaid, I dunno there is an invalid transaction for this amount. System desperately tried to reconcile the additional Bittrex mint?
I had a look at the eMAID migration code. I think the filter code needs a “isValid == true”, check.
So the code must of seen this transaction invalid for 10295. Because the user was already associated with Bittrex. It minted them the extra tokens. I guess if this ‘user’ would submit a invalid transaction for 9720, it will try to mint them the remaining tokens.
I don’t think this transaction is unaccounted for, I think the Bittrex burn is getting associated with a particular user. Plus there is a bug, not filtering out invalid omniexplorer transactions.
Great that it was spotted on so early and quick response from the team to resolve the situation.
That is bittrex wallet from memory. It is definitely one of the exchanges.
The error that was on emaid.online seems to come from the recent depreciation of /v1/safes/{address}/transactions/ in gnosis api which is now been replaced by /v1/safes/{address}/multisig-transactions/ route. Not sure if this is related in anyway, still good to know in case if it has been overlooked.
As can been seen here in the documentation:
https://safe-transaction-mainnet.safe.global/
Trex or polo, id bet on that, i recall that add.
How could be happen?
Its seems @tari has explained it @cryptoidiot
Basically it seems that some one has transferred from their Bittrex wallet MAID to the burn address and the bridge associated the address of bittrex’s MAID wallet with that person.
Then someone else has transferred from their Bittrex wallet and so the bridge got confused.
When you send MAID from Bittrex the send address is Bittrex’s wallet.
Indeed, that’s the most plausible explanation at this stage:
After someone (Bob) mistakenly burnt from Bittrex, we temporarily whitlested the Bittrex wallet address a few days ago to solve the situation. Then the system picked a previously failed transaction (spotted by @tari) to resolve the imbalance, especially so as the community member who received the 10’295 eMAID (Alice) had withdrawn the specific amount of 10’295 MAID from Bittrex to his wallet in the past :
As Alice had just passed a new round of KYC to start burning more tokens the day following the whitelisting of the Bittrex address, system got confused.
We are talking of a very very specific edge case here. We still need to formalize this theory by looking at the logs, which we will do on Tuesday, when the main tech guy in charge of the Bridge comes back from vacations. From there it’s hopefully a quick fix. We will do a formal post mortem next week when situation is resolved.
Thank you all involved for the swift action and clear communication!
POST MORTEM:
On July 18th, an unexpected minting of 10295 eMAIDs happened and was promptly reported by the user who received them.
In order to evaluate the situation, alt.co decided to halt the automated co-signing server which in effect triggers a manual validation for new mints.
The situation was transparently disclosed on MaidSafe forums and the open source approach of the bridge allowed the community to investigate.
After analysis, it was found that the extra minting was due to a filtering routine which was missing a verification.
After examination of the logs, it appeared that the erroneous mint was added by the system on June 27, 2023 but wasn’t initialized until July 10th, 2023 when the gap between burned MAIDs and minted eMAIDs allowed it.
In order to get the situation back to normal two counter.measures have been considered.
After that alt.co assumes that the co-signing server (which automatically co-signs initialized transactions on the multi-sig controlling the minting contract after 24 hours) could be re-enabled.
In total 3 users were impacted:
Bottom line: as soon as the burn of 10295 (omni)MAID is done we will reactivate the bridge. We are liaising with the community member to proceed.
Thank you for looking into this and handeling it all so professionally. I’d expect nothing less from alt.co but that doesn’t mean that we’re not highly appreciative. Keep up the good work mate.
The burn was done, so we will now start the procedure to reactivate the bridge later this afternoon
Big thanks to this community member who has proven so much integrity by escalating the issue and helping us improve the overall security of this process. Thanks all for your patience !
And thank YOU for the professional way this was handled.
All adds to the reputation for integrity and transparency that this project has and few others can aspire to.
