komodoplatform / coins Goto Github PK

Hi cipig,
This is concerning Whive coin listing on atomicdex, which has been okay , but the prices.komodo.live api does not seem to pick prices from coinpaprika despite the fact it is properly configured.Please advice on what to do.
Thanks

lets add checksums for all files / assets in this repo and host checksum independently for cross-validation possibilities

Going through the coins file, there are a few inconsistencies which could be fixed to help with future maintenance.
e.g.

• BEP-20 (and other platform/protocols) tokens should have a -BEP20 suffix (or *-ERC20; *-SLP etc)
• There is no consistent tagging of testnet coins. Suggest using a (test) suffix in fname.
• Not all coins have an fname value, and there might be other entries missing standard values.
• Due to the way the price service operates, any chars after the first - in the coin value will return the same price. For this reason, no coin should use a - in their name except to indicate it's platform/protocol. Instead, use an _. For example, a test coin named NAME on the BNB testnet would be NAME_TEST-BEP20

Changing the coin name value will be a breaking change for DEX apps which use a supplementary coins file for activation, so this update needs to be done in a carefully coordinated manner at a time where it wont impact any imminent deadlines for releases / demonstrations etc.

We're also lacking a clear delisting process / cycle. Something similar to KomodoPlatform/komodo-wallet-desktop#1993 should also be applied here.

cc: @ologunB @yurii-khi @artemii235

Action was updated last week, need to be applied in our workflows: https://github.com/peter-evans/create-pull-request/releases/tag/v6.0.1

As seen in the past, occasionally electrum servers operated by third parties may fail, and resolving the issue takes longer than is ideal.
To mitigate this, the following actions should be taken:

• Enforce contact details be included in all pull requests which involve resources not maintained by the Komodo team.
• Setup & maintain real-time monitoring of listed electrum servers. Status should be available via API for dashboard / app display and automated alerts.
• Setup a daily cron run of the CI to keep the electrums listed in coins_config.json up to date.

During KomodoPlatform/komodo-defi-framework#1526 (comment) discussion, I have discovered that block times are set in minutes, which seems confusing to me. E.g. IRIS testnet block time is ~5 seconds, which is 1/12 minute - this can't be simply written as finite decimal, so we have to round it, losing some precision. It may even lead to incorrect block count based swap lock times, which is a serious problem.

So I propose to change all block times in the config to seconds. cc @smk762 @tonymorony

• Images already optimised in CI/CD flow, need to confirm this is what all repos use.
• Vector file formats like svg would be good where possible
• coins_config.json could be trimmed, some fields are not required for guis. Some field names could be shortened.
• We should also serve a minified version for the guis to reduce the file size.

req from api team

Currently we have https://github.com/KomodoPlatform/coins/blob/master/ethereum/HT only single Heco node.
Quite often it's unavailable -> all GUIs can not activate/use HT and it's tokens.

Thus we should at least add mroe public nodes here.

Received the following info:

Minu is based on BNB Smart Chain

Website: https://www.minucoin.com

Mining Dapp: https://www.minucoin.com/dapp

CoinGecko Link: https://www.coingecko.com/en/coins/minu

CoinMarketCap link: https://coinmarketcap.com/currencies/minu/

Block Explorer Token: https://bscscan.com/token/0xf48f91df403976060cC05dBbf8A0901b09fdeFd4

Block Explorer Dapp: https://bscscan.com/address/0x0754088499311a3FC2A9D2B759Dab2b6c0dB4A15

Pancakeswap pool: https://pancakeswap.finance/info/pairs/0x91d8d7dfcadc8e04195e75069e1316e01ba7f01c

Mexc pool: https://www.mexc.com/exchange/MINU_USDT

P2B CEX pool: https://p2pb2b.com/trade/MINU_USDT/

IndoEX CEX pool: https://www.indoex.io/trade/MINU_USDT

Probit CEX pool: https://www.probit.com/app/exchange/MINU-USDT

1inch: https://app.1inch.io/#/56/simple/swap/BNB/MINU

OpenOcean: https://app.openocean.finance/classic#/BSC/MINU/BNB

Twitter: https://twitter.com/minu_coin

Telegram: https://t.me/minu_coin

Token Audit: https://github.com/cyberscope-io/audits/blob/main/11-minu/Token.pdf

Dapp Audit: https://github.com/cyberscope-io/audits/blob/main/11-minu/audit.pdf

Flooz Integration: https://flooz.xyz/trade/0xf48f91df403976060cC05dBbf8A0901b09fdeFd4?network=bsc

DefiLlama: https://defillama.com/protocol/minu

BNB Chain official page: https://dappbay.bnbchain.org/detail/minu

Alchemy Dapp Store: https://www.alchemy.com/dapps/minu

Magic Store: https://magic.store/app/minu

cc: @cipig @smk762

Alongside the config generation PR (#502) we need to implement the following:

When there is a merge to master:

• Run utils/scan_electrums.py which will identify current working / failed electrums.
• Run utils/generate_app_configs.py which will output json files for each app (web, mobile, desktop). It will reference the electrums_scan_report.json to exclude any entries which are failing.
• Push the generated app config json files to master branch, so they are available for apps to grab during build. Also push the electrum_scan_report .json file to master - we can use this to inform electrum maintainers if their servers need attention.
• Create exclusion in the CI flow so that updating the json files in master does not trigger the CI workflow, so we can avoid an infinite loop which melts down githubs servers.

Once a day:

• Run utils/scan_electrums.py which will identify current working / failed electrums.
• Push the electrum_scan_report .json file to master - we can use this to inform electrum maintainers if their servers need attention.

Refs:

• https://github.com/iancoleman/bip39/blob/master/src/js/bitcoinjs-extensions.js
• https://github.com/qtumproject/ledger-wallet-chrome/blob/master/app/src/bitcoin/networks.coffee

Among the assets listed in https://github.com/KomodoPlatform/coins/blob/master/utils/coins_config.json

the following coins/assets didn't have icons in https://github.com/KomodoPlatform/coins/tree/master/icons

image not found- ADEX BSC: ADEXBSC
image not found- ADEX BSC Testnet: ADEXBSCT
image not found- AtomicSLP: ASLP
image not found- aware token: AWR
image not found- baer chain: BRC
image not found- Bitcoin Cash Testnet: tBCH
image not found- bodhi token: BOT
image not found- cfun token: CFUN
image not found- entertainment cash: ENT
image not found- epc: EPC
image not found- Fake USD: USDF
image not found- fenix.cash: FENIX
image not found- Honk Honk: HONK
image not found- Ilien Swap: ILNSW-PLG20
image not found- PlayCoin: PLY
image not found- sTST: sTST
image not found- winechain: WID
image not found- Zombie: ZOMBIE

maybe the new workflow can keep track of this info too?

cc: @cipig @smk762

I'm not sure if we have a clear canonical place where smart chain launch parameters are stored, beyond the assetchains.old and assetchains.json files in https://github.com/KomodoPlatform/komodo which are only targeting chains being notarised. As a result, params for other coins like SOULJA, Dragon Fairy etc don't appear to be listed anywhere beyond perhaps Discord.

Would this repo be a suitable place to store this info? I'd propose a folder "smart chains" with a structure similar to the below:

    "MESH": "-ac_name=MESH -ac_supply=1000007 -ac_ccactivate=320000",
    "MGW": "-ac_name=MGW -ac_supply=999999",
    "MSHARK": "-ac_name=MSHARK -ac_supply=1400000",
    "NINJA": "-ac_name=NINJA -ac_supply=100000000",
    "PANGEA": "-ac_name=PANGEA -ac_supply=999999",
    "REVS": "-ac_name=REVS -ac_supply=1300000",
    "RICK": "-ac_name=RICK -ac_supply=90000000000 -ac_reward=100000000 -ac_cc=3 -ac_staked=10 -addnode=138.201.136.145 -addnode=95.217.44.58"

alternatively, to include ecosystem chains using custom daemons, or no longer in use (for historical value):

    "MGW": {
           "launch": "-ac_name=MGW -ac_supply=999999",
           "status": "active dpow",
           "repo": "https://github.com/KomodoPlatform/komodo/tree/master"
    },
    "TOKEL": {
           "launch": "-ac_name=TOKEL -ac_supply=100000000 -ac_eras=2 -ac_cbmaturity=1 -ac_reward=100000000,4250000000 -ac_end=80640,0 -ac_decay=0,77700000 -ac_halving=0,525600 -ac_cc=555 -ac_ccenable=236,245,246,247 -ac_adaptivepow=6 -addnode=135.125.204.169 -addnode=192.99.71.125 -addnode=144.76.140.197 -addnode=135.181.92.123",
           "status": "active dpow",
           "repo": "https://github.com/KomodoPlatform/komodo/tree/tokel"
    },
    "MCL": {
           "launch": "-ac_name=MCL -ac_supply=2000000 -ac_cc=2 -addnode=37.148.210.158 -addnode=37.148.212.36 -addressindex=1 -spentindex=1 -ac_marmara=1 -ac_staked=75 -ac_reward=3000000000 -daemon",
           "status": "active dpow",
           "repo": "https://github.com/marmarachain/marmara/tree/master"
    },
    "OOT": {
           "launch": "-ac_name=OOT -ac_supply=216000000 -ac_sapling=5000000",
           "status": "abandoned",
           "repo": "N/A"
    }

If you think this might be of value, I'll collect the data and draft a PR.

Right now we have our nodes and another nodes. For our node request to enable the ethereum looks like this:

'{
	"userpass": "'$userpass'",
	"mmrpc": "2.0",
	"method": "enable_eth_with_tokens",
	"params": {
		"ticker": "ETH",
		"nodes": [
			{"url": "https://auth.defimania.live/ethereum", "gui_auth": true }
		],
		"swap_contract_address": "0x24ABE4c71FC658C91313b6552cd40cD808b3Ea80",
		"erc20_tokens_requests": []
	},
	"id": 0
}'

nodes is array and element has property gui_auth.
gui_auth should be true only for our nodes and should not be for another one. Other nodes work, but this flag brings overhead.

I think that node should have the same structure.
nodes: [{"url": "https://auth.defimania.live/ethereum", "gui_auth": true }]

As discussed with @tonymorony using a put to push code is not an ideal situation. Conflicts have been plaguing us with the electrum scan report which will no longer be pushed once #549 is merged. Removing this file also removes the "grace period" functionality implemented in #539 as it no longer has a prior reference timestamp to determine the last time a connection was made, so in order to implement automated alerts / dashboard for electrum status, we need to find a home for this file. If completely removing bot generated PRs, the same would apply to the coins_config.json

Below are few options to overcome this:

• Schedule periodic manual updates to these files to be pushed manually (without bot) to coins repo
• Do not include in coins repo at all, and just have gui repos generate them as needed and pushed to the gui repo
• Store these files elsewhere, for example in their own repo which would include API for guis to be aware of update to the canonical version commit hash and alert / dashboard code which will display electrum status and, if contacts are listed in the electrum entry, alert the maintainer to resolve the issue.

Please add comments to this thread if you have an idea for an alternative proposal, and I'll add them to the list above.

cc: @tonymorony @yurii-khi @SirSevenG

Replace electrum servers for the GRMS coin with new ones for release in the next release
"electrum": [
{
"url": "electrum.grms.pw:17485"
},
{
"url": "electrum1.grms.pw:17485"
},
{
"url": "electrum2.grms.pw:17485"
},
{
"url": "electrum3.grms.pw:17485"
}

Among all the coins listed in atomicdex-desktop, based on: https://raw.githubusercontent.com/KomodoPlatform/atomicDEX-Desktop/master/assets/config/0.5.6-coins.json

the following coins/assets didn't have icons in https://github.com/KomodoPlatform/coins/tree/master/icons

Avalanche Testnet: AVAXT
Binance Coin (Testnet): BNBT
EthKovan Optimism (Testnet): ETHK-OPT20
Fantom Testnet: FTMT
Matic Testnet: MATICTEST
Moonbeam: GLMR
Pegaxy Stone: PGX-PLG20
Ropsten test ERC20: JSTR
RSK Smart Bitcoin: RBTC
SmartBCH: SBCH

cc: @cipig @smk762

Currently listed electrums (https://github.com/KomodoPlatform/coins/blob/master/electrums/GRS) have invalid/expaired SSL certificates, so it's impossible to activate GRS on all platforms atm

This is a list of smart chains that we could delist before S7.

• MESH (not notarized)
• ZILLA (not notarized)
• RICK & MORTY (replaced by DOC & MARTY)
• DEX, BOTS, JUMBLR, MGW, REVS (converted to vDEX)
• BET & PANGEA (converted to CHIPS)
• CRYPTO - done, already delisted
• MSHARK (buyback/convert to KMD/VRSC)
• HODL (buyback)

Any comments appreciated.

./ethereum/MATICTEST has probably a wrong key with 'fallback_contract_address'. Assuming that this should be a 'fallback_swap_contract' key like the others?!

{
  "swap_contract_address": "0x73c1Dd989218c3A154C71Fc08Eb55A24Bd2B3A10",
  "fallback_contract_address": "0x73c1Dd989218c3A154C71Fc08Eb55A24Bd2B3A10", # <--------
  "rpc_nodes": [
    {
      "url": "https://rpc-mumbai.matic.today"
    },
    {
      "url": "https://matic-mumbai.chainstacklabs.com"
    },
    {
      "url": "https://rpc-mumbai.maticvigil.com"
    }
  ]
}

ref: KomodoPlatform/komodo-defi-framework#1604 (comment)

Updating txversion fields for some coins can be beneficial, an example is PPC where n_time is removed from version 3 reducing the tx size/fees. I will start looking in coins code for new tx versions and we can test them 1 by 1 before updating thier config.
KomodoPlatform/komodo-defi-framework#1631
KomodoPlatform/komodo-defi-framework#1631 (comment)

The current json output is not as pretty as it could be, and a different format would make it easier to integrate into monitoring / alerts systems.

e.g.

{
    "DEX": {
        "electrums_total": 3,
        "electrums_working": 2,
        "stats": {
            "electrum1.cipig.net:10006": [true, "passed"],
            "electrum2.cipig.net:10006": [false, "[Errno 111] Connection refused"],
        }
    }
}

e.g. polygon had a 157-depth reorg in the last month https://polygonscan.com/block/39599624/f?hash=0x0b7e6c5e9fbae3e2dbd114e4836b52ffb1211820bf62bbbd3ddf859dd07c0fe1

We can check reorg data here https://polygonscan.com/blocks_forked, we need to find this info for coins supported and update required_confirmations to a good value (e.g. for polygon if we used 20 confirmations it will be a good value that avoids these problems for almost all blocks but if we want a complete safe value, we will need to make it 200 confirmations)

We need to check this data periodically and also check chain updates that solve these problems so we can reduce these values when these problems are solved to have faster swap times.

all the asset types in the current coins file:

  'AVX-20',
  'Matic',
  'BEP-20',
  'ERC-20',
  'KRC-20',
  'FTM-20',
  'HecoChain',
  'UTXO',
  'ZHTLC',
  'SLP',
  'Smart Chain',
  'RSK Smart Bitcoin',
  'Moonriver',
  'Arbitrum',
  'QRC-20',
  'Ethereum Classic',
  'Moonbeam',
  'HRC-20',
  'SmartBCH',
  'Ubiq',
  'TENDERMINT',
  'TENDERMINTTOKEN'

observations + my opinions:

1. every name starts with an upper case letter (good)
2. format of ERC-20 type tokens xxx-20 is good as it is
3. acronyms are all uppercase like UTXO, SLP, ZHTLC (good)
4. single word full names like Matic, Ubiq, Moonriver are also good
5. multi word names: 'Ethereum Classic', 'RSK Smart Bitcoin', 'Smart Chain', are two words, but 'HecoChain', is one word in Pascal case. this is inconsistent. if there is existing code that depends on the current name 'HecoChain' (I assume there definitely is), we should make it an exception, and all future multi-word names should be two words
   or consider 'Ethereum Classic', 'RSK Smart Bitcoin', 'Smart Chain' as exceptions and make all future multiword names Pascal case. just have to pick one style and stick to it
6. 'TENDERMINT' should be 'Tendermint'
7. 'TENDERMINTTOKEN' should be 'TendermintToken' or 'Tendermint Token' based on the decision for multiword names from the 5th point

I'm making a webpage that displays all these names in a single spot, so found this inconsistency.

it is also ok to decide that changing any of the existing names will cause too much unnecessary work in the API/GUI codebases. then I will write some exceptions for the webpage I'm creating and normalize the naming scheme just over there

cc: @smk762 @cipig @tonymorony

refs:

• https://github.com/satoshilabs/slips/blob/master/slip-0044.md
• https://github.com/qtumproject/ledger-wallet-chrome/blob/master/app/src/bitcoin/networks.coffee
• https://trezor.io/coins (for Trezor coin field)
• https://github.com/KomodoPlatform/WebDEX/issues/502#issuecomment-1193167304

e.g.

    "derivation_path": "m/44'/2301'",
    "trezor_coin": "Qtum"

For qrc20 tokens need swap contract address which is not in repo.

Currently all entries in coins file (including segwit) have a 44 value for the purpose part of derivation path.

Need to test using different values with mm2 for generating addresses and transacting and confirm it works.

It seems for some minor coins which are supported by livecoinwatch may not be supported as a pair. I can't think of a method to filter these out without using a pair exclusion list.

Originally posted by @smk762 in KomodoPlatform/komodo-wallet-desktop#2239 (comment)

Project name / ticker: MIL
Team: Einsteiniumcoin
Repository: https://github.com/emc2foundation/mil
Algo: Ethash

Describe the bug
When user tries to send funds on valid P2SH address in KMD network he receive the error message that entered address is incorrect. The issue affects Desktop and Mobile versions of AtomicDEX as well.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Wallet'
2. Click on 'KMD'
3. Choose Send, enter any valid P2SH address as a recipient address.
4. See error

Expected behavior
Funds should be sent.

Screenshots

As you can see Ledger Live app allows to send on this P2SH address and count it as valid.

Currently the electrum scan report rejects coins with no working electrums at the time of the CI run which has the potential to omit coins where an electrum is down for a brief period for maintenance. To accommodate situations like this, we could implement a "offline_since" value, which resets when a connection is made in subsequent CI runs. Thenwe can filter out with an "offline_since" value greater than "x" (3 days?).

Recently we ended up in a position where the master branch of the coins repo contained information which breaks the functionality of some methods in the current API release version. To avoid repeating this problem, the following suggestions have been made

• master branch should at all times be compatible with the latest API release binaries (mm2.1 branch)
• dev branch will be created, and should at all times be compatible with the API dev branch
• Additional branches can be created with the same branch name used in API repo for specific feature testing, before merging into dev and eventually master.
• Upon release of a new version of the API, a git tag with the same version number / short hash as the API release will be created to offer a static fallback reference. new coin additions for existing protocols can be added to master (and should still function with the API release), with the option to add incremental tags if required or on a schedule once a week/month).
• GUIs which reference the coin_config.json generated by this repo's CI should use tags / short hashes to source the data, so we can avoid builds failing due to potentially introduced errors.

Please add any more suggestions or pros/cons below.
cc: @yurii-khi @artemii235 @ozkanonur @tonymorony @cipig

Request:

{
    "method": "task::enable_utxo::init",
    "userpass": "***",
    "mmrpc": "2.0",
    "params": {
        "ticker": "VAL",
        "activation_params": {
            "tx_history": true,
            "mode": {
                "rpc": "Electrum",
                "rpc_data": {
                    "servers": [
                        {
                            "url": "e1.validitytech.com:11004",
                            "protocol": "WSS",
                            "disable_cert_verification": true
                        },
                        {
                            "url": "e2.validitytech.com:11004",
                            "protocol": "WSS",
                            "disable_cert_verification": true
                        },
                        {
                            "url": "e3.validitytech.com:11004",
                            "protocol": "WSS",
                            "disable_cert_verification": true
                        }
                    ]
                }
            },
            "scan_policy": "scan_if_new_wallet",
            "priv_key_policy": "Trezor"
        }
    }
}

Status response:

{
    "mmrpc": "2.0",
    "result": {
        "status": "Error",
        "details": {
            "error": "Error on platform coin VAL creation: Operation failed due to unknown reason: Failure { code: Some(FailureDataError), message: Some(\"Invalid coin name\") }",
            "error_path": "lib.common_impl.coin_balance.utxo_common.hd_pubkey.client",
            "error_trace": "lib:103] common_impl:52] coin_balance:408] utxo_common:234] hd_pubkey:170] client:90]",
            "error_type": "CoinCreationError",
            "error_data": {
                "ticker": "VAL",
                "error": "Operation failed due to unknown reason: Failure { code: Some(FailureDataError), message: Some(\"Invalid coin name\") }"
            }
        }
    },
    "id": null
}

VAL config, from coins.json

  {
    "coin": "VAL",
    "name": "validity",
    "fname": "Validity",
    "confpath": "USERHOME/.Validity/validity.conf",
    "isPoS": 1,
    "rpcport": 27914,
    "pubtype": 76,
    "p2shtype": 58,
    "wiftype": 121,
    "txfee": 100000,
    "dust": 300000,
    "mm2": 1,
    "required_confirmations": 5,
    "avg_blocktime": 1,
    "mature_confirmations": 60,
    "protocol": {
      "type": "UTXO"
    },
    "derivation_path": "m/44'/634'",
    "trezor_coin": "Valorbit",
    "links": {
      "homepage": "https://valorbit.com"
    }
  }

Noticed on https://github.com/KomodoPlatform/coins/blob/master/icons_original/taz.png
There may be others.

at the moment segwit: true flag set e.g. for BCH https://github.com/KomodoPlatform/coins/blob/master/coins#L469
and for QRC20 tokens: https://github.com/KomodoPlatform/coins/blob/master/coins#L2493 where it shouldn't be

not correct flag might cause dangerous consequences (wrong address funds sending), so we should re-evaluate this flag for added coins I think

ref: https://github.com/KomodoPlatform/WebDEX/pull/822#issuecomment-1403148143

Garlicoin is a Litecoin fork.
Here's the PR to add it to spesmilo/electrumx: spesmilo/electrumx#211
Here are most of the needed parameters: https://garlic.wiki/index.php/Garlicoin#Technical_Details

In future, all PRs for electrums must contain a point of contact for resolving issues.
Electrum status summary: https://stats.kmd.io/atomicdex/electrum_status/
Currently, the following coins have issues on some or all servers:

• ABY (2/4 failing, no contact details)
• ACTN (1/4 failing, email sent)
• AUR (2/3 failing, no contact details)
• AYA (2/4 failing, email sent)
• BSTY (2/3 failing, no contact details)
• BTX (1/1 failing, contacted via discord)
• CDN (4/8 failing, no contact details)
• DGC (1/2 failing, no contact details)
• DIMI (2/2 failing, email sent)
• EFL (4/6 failing, no contact details)
• FLUX (1/2 failing, no contact details)
• GRS (1/5 failing, email sent)
• IL8P (2/2 failing, email sent)
• LNC (2/2 failing, email sent)
• LYNX (1/5 failing, no contact details)
• MONA (1/4 failing, no contact details)
• NATURE (3/3 failing, no contact details)
• NMC (4/5 failing, reported at namecoin/electrum-nmc#336)
• NVC (2/2 failing, email sent)
• NYAN (4/4 failing, no contact details)
• RUNES (3/6 failing, email sent)
• SCA (3/3 failing, email sent)
• SIX (3/3 failing, email sent)
• SMART (5/6 failing, no contact details. Not present in coins file?)
• tBCH (2/4 failing, no contact details)
• TRC (1/3 failing, no contact details)
• UIS (1/2 failing, no contact details)
• UNO (2/2 failing, no contact details)
• VRM (1/1 failing, email sent)

utxo_merge param was added to ADEX Desktop here KomodoPlatform/komodo-wallet-desktop#1937, but atm it's not reflected in coins_config.json because it's missing from generate_app_configs.py