The contract and all its possibilities are regulated by just one address that decides which address will have the Validator, СhainLedger, and TokenPorter.
Overview
We checked up on all the the parts that half a year ago we found questionable, when we first heard about the project.
We analized current smart contracts from Etherscan.
Smart contracts
The Validator contract can:
- Set a TokenPorter for itself
- Set new validators that will decide whether to create a cross-chain exchange or not (can be executed by the owner)
- Delete old validators
Current Validator:
3 VALIDATORS ARE HARD CODED!!!
These are:
- https://etherscan.io/address/0x006b24a61f8391357d9cc00d9b191de6439e9df7
- https://etherscan.io/address/0x92c6324947f5e4ed2b7f6b94270bc48b33621365
- https://etherscan.io/address/0x2b448e4d78293f1c6fc47230306d6297cabb5f46
The TokenPorter contract can:
- Set Validator for itself
- Set ChainLedger for itself
- Import MET
- Export MET
Current TokenPorter:
The chainLedger contract can register (functions can be executed by the owner without any verifications nor voting):
- new Chain
- export
- import
Current ChainLedger:
Current Proceeds (balance of ~$11,185,783.55):
In every contract, the creator indicated the following address:
Current Owner of all contracts:
The most important and most questionable part of this project are the cross-chain operations.
Executing via Exporting/Importing MET.
Export algorithm
- The main smart contract launches the the export function in the TokenPorter contract (TokenPorter is used like a library)
- The tokens are destroyed in the current blockchain
- The number of tokens, wallet address, and the deleted chain address are added to the claimables list (this info is only used in the claimReceivables funciton, which shows that the tokens destroyed in the old blockchain are recreated in the new one - but this function is not executed anywhere...)
- A hash is formed into which a bunch of parameters are recorded, along with timestamps, number of tokens to transfer, total number of tokens in the network, currentTick, previous hash, etc.
- Hash is recorded into exportedBurns
- chainLedger register the Export (just chekcks both the current and remote chains for validity and that's it)
Import algorithm
- The main smart contract launches the import function in the TokenPorter contract
- In the Validator contract there is a verification of isReceiptClaimable
- All the parameters hashed as well as the previous and current hash go here
- If the current hash matches the hash of all these parameters, the verification continues
- If hashClaimable(current hash) - OK (if the hash is not hashClaimed, the smart contract checks if enough verificators: verificators=3, threshold=2). The voting is manual, without any algorithms. Each verificator simply votes YES or NO.
- Execution of claimHash(_burnHashes[1] current hash) (if hashClaimable(current hash) then hashClaimed = true for the current hash)
- Checking the number of tokens (tokens to import)+(tokens in the system) <= (all issued tokens)
- For the first import, prepare auction when first import is done on a non ETH chain
- New tokens are created and added to the new address in the new blockchain
- chainLedger registeres the Import (just checks the current and remote chains for validity)
So what do we get out of all this?
It's bad to have all three verificators hard coded. Especially since they are set by one person (rather than some autonomous algorithm). Btw, the White Paper barely talks about the verificators... Verificators in turn vote not via some advanced algorithm but rather via "approve/not approve." This results in the centralization of the entire system - thus diverging from the project's own goals.
There is no autonomy nor decentralization. Instead, they have automatization and centralization of governance. So the question is - why the fuck do they need a blockchain for this?
Everything can be regulated by one person.
That one person solely decides which smart contract is responsible for which operations. He can replace current contracts with other ones - with completely different logic and at any time.
There are no consensus algorithm that would - in a decentralized manner and without human interference - verify and execute cross-chain transactions.
Auction and Autonomous Converter
If the token price in the сonverter is lower than in the auction, people will most likely buy the tokens in the сonverter.
If the price is lower in the auction, people will buy the tokens there and then dump them onto the сonverter with a profit.
Thus, the auction and сonverter will cancel each other out in favor of keeping the price more or less stable.
But this just looks like exchanging funds for the sake of the exchange - someone will make money, someone will lose it.
The exchange rate is determined via two formulas:
If we want to sell 100 MET for ETH. Here's how it works:
- MET tokens are exchanged for smart-tokens. (Smart-tokens are an intermediary currency; their number of 10,000 tokens listed as an example in the White Paper is not explained in any way.)
- Smart-tokens are exchanged for ETH.
If the сonverter has 1,000 ETH, 2,000 MET, and 10,000 smart-tokens, the price will accordingly be 1 MET = 0.5 ETH (1000/2000).
For 100 MET we expect to receive 50 ETH. According to formulas, we actually receive 47 ETH. 3 ETH remain in the smart contract. Consider them a commission (with the goal there to gather enough liquidity for a convenient exchange of funds).
After that operation is performed, 953 ETH and 2100 MET will remain in the contract -> the exchange rate will be 1 MET = 0.4538095238095238 ETH (953/2100)
Couple of examples
Let's assume that the owner was tortured via a thermorectal cryptoanalizer and gave up all passwords for everything. Via the changeOwnership function, the hackers will change the owner in the main contract-token (using the owner's wallet and hence his address) and will control all the contracts they want to control.
Or the owner himself decides to go rogue - remember, the owner of all contracts is the same address.
Or this can be done via the setTokenPorter function in the Validator contract, which sets the new TokenPorter. The new TokenPorter can have an absolutely new logic of processing old functions.
Thus, the export and import functions for MET could be modified. All the verifications will be removed. Exporting will burn MET, while importing will add MET to the owner's address.
Conclusion
So they just happened to forget to mention their centralization? Plus, feels like they deliberately overcomplicated (or even hid) the principles of the workings and logic of their smart contracts.
But the smart contracts themselves are written, work has been done, the coin is being traded.
Verdict
Scam!
Ситуация следующая. Контракт и все его возможности регулируются одним адресом.
Данный адрес решает по какому адресу будет находится смарт-контракт Validator, СhainLedger и TokenPorter.
Overview
Мы перепроверили спорные моменты в Metronome, которые нам не понравились еще пол года назад, когда мы впервые узнали про этот проект.
Проанализировали действующие смарт-контракты с etherscan.
Smart contracts
Контракт Validator может:
- назначать себе TokenPorter
- задавать новых валидаторов, которые будут решать - производить кроссчейн обмен или нет (может вызваться овнером)
- удалять старых валидаторов
Текущий Validator:
ЗАХАРДКОЖЕНО ТРИ ВАЛИДАТОРА!!!
Собственно сами валидаторы:
- https://etherscan.io/address/0x006b24a61f8391357d9cc00d9b191de6439e9df7
- https://etherscan.io/address/0x92c6324947f5e4ed2b7f6b94270bc48b33621365
- https://etherscan.io/address/0x2b448e4d78293f1c6fc47230306d6297cabb5f46
Контракт TokenPorter может:
- назначать себе Validator
- назначать себе ChainLedger
- импортировать MET
- экспортировать MET
Текущий TokenPorter:
Контракт chainLedger может регистрировать (функции могут быть вызваны овнером, без проверок или голосований):
- новый Чейн
- экспорт
- импорт
Текущий ChainLedger:
Текущий Proceeds (~$11,185,783.55 на счету):
Во всех контрактах создателем указан этот адрес:
Текущий Owner всех контрактов:
Самая важная и спорная часть - кроссчейн операции.
Производятся с помощью Экспорта Импорта MET.
Алгоритм экспорта
- главный смарт-контракт запускает экспорт в контракте TokenPorter (TokenPorter - используется как библиотека)
- токены уничтожаются в текущем блокчейне
- в список claimables складываются количество токенов, адрес кошелька, адрес удаленного чейна (эти данные используются только в функции claimReceivables, которая укажет, что уничтоженные токены в старом блокчейне были воссозданны в новом. Но она нигде не вызывается...)
- формируется хэш в который записывается куча параметров, таймштампы, количество токенов для передачи, общее количество токенов в системе, текущий тик, предыдущий хэш и т.п.
- хэш записывается в exportedBurns
- chainLedger регистрирует Экспорт (просто проверяет на валидность текущий и удаленный чейн и всё)
Алгоритм импорта
- главный смарт-контракт запускает импорт в контракте TokenPorter
- в контракте Validator проходит проверка isReceiptClaimable
- сюда летят все параметры которые хэшировались + предыдущий и текущий хэши
- если текущий хэш совпадает с хэшом всех этих параметров то проверка продолжается
- если hashClaimable(текущих хэш) то ОК (если хэш не hashClaimed то проверяется, чтобы за хэш проголосовало достаточно верификаторов (verificators=3, threshold=2) голосование вручную, без каких-либо алгоритмов. просто верификатор дает голос ЗА или ПРОТИВ)
- вызов claimHash(_burnHashes[1] текущий хэш) (если hashClaimable(текущий хэш) то ставим hashClaimed = true для текущего хэша)
- проверка количества токенов. (токены для импорта)+(токены в системе) <= (всех произведенных токенов)
- во время первого импорта prepare auction when first import is done on a non ETH chain
- производятся новые токены и начисляются на новый адрес в новом блокчейне
- chainLedger регестрирует Импорт (просто проверяет на валидность текущий и удаленный чейн и всё)
Что мы имеем?
Захардкоженность трех верификаторов - это плохо. Причем этих верификаторов назначает 1 человек, а не какой-нибудь автономный алгоритм. В ВП, кстати, про верификаторов написано очень поверхностно... Сами верификаторы голосуют не по хитрому алгоритму, а просто "одобрил\не одобрил". Как следствие централизованность всей системы и несоответствие своим же целям у проекта.
Автономности и децентрализованности - нет. Вместо этого здесь автоматизация и централизованное управление. Вопрос - нахрена тут блокчейн?
Всё может регулироваться одним человеком.
Этот один человек сам решает, какой смарт-контракт отвечает за какие операции. Он может заменять текущие контракты другими, с любой другой логикой, в любой момент.
Нет алгоритма консенсуса, который бы децентрализовано и без участия людей позволил бы верифицировать, проводить кроссчейн операции.
Аукцион и Обменник
Если цена на токен в обменнике меншье чем на аукционе - скоей всего все будут скупать токены с обменника.
Если цена на аукционе будет меньше чем в обменнике - все будут стараться скупить токены через аукцион и далее скинуть их в обменнике по выгодной цене.
Взаимоисключающие аукцион и обменник будут постоянно держать цену на более менее стабильном уровне.
Но выглядит это как обмен ради обмена и ничего больше. Т.е. кто-то потеряет деньги, а кто-то получит эти потерянные деньги.
Курс в обменнике определяется двумя формулами.
Если мы хотим продать 100 MET за эфир. Принцип следующий:
- MET токены меняются на смарт-токены. (Смарт токены - промежуточная валюта для обмена, их количество (10,000) в ВП для примера взято без пояснений)
- Смарт токены меняются на ETH
Если в смарт-контракте обменнике нахиодится 1000 ETH, 2000 MET и 10,000 смарт-токенов, то цена будет соответствующей 1 MET = 0.5 ETH (1000/2000)
Для 100 MET мы ожидаем получить 50 ETH, согласно формулам, мы получим 47 ETH. 3 ETH остаются в смарт-контракте. Их можно расценивать как комиссию (цель - набрать ликвид для удобного обмена).
После данной операции в контракте останутся 953 ETH и 2100 MET -> курс будет 1 MET = 0,4538095238095238 ETH (953/2100)
Пару примеров
Предположим, овнер сдался под напором терморектального криптоанализатора и выдал все пароли от всего подряд. Через функцию changeOwnership в главном контракте-токене хацкеры с его кошельком, на котором будет адрес овнера, сменят овнера и будут рулить всеми контрактами как им вздумается.
Ну или он сам так решит, во всех контрактах овнер - это один и тот же адрес.
Или через функцию setTokenPorter в контракте Validator, которая задает новый TokenPorter. В новом TokenPorter может быть абсолютно другая логика обработки старых функций.
Так функции эксопрт импорт MET могут быть модифицированны. Все проверки будут убраны. При экспорте будут сгорать MET, а при импорте они будут зачисляться на адрес овнера.
Conclusion
Недосказанность в виде централизации, а так же специального запутывания принципов работы и логики смартконтрактов.
Но сами смарт-контракты написаны, работа проделана, монета торгуется.
Verdict
Scam!
Disclaimer: The above audit is not in any way financial advice or a solicitation to buy - it's merely our collective opinion that we are kind enough to share with you. Don't make us regret that.
Our links: