diff --git a/src/cc/CC_made_easy.md b/src/cc/CC_made_easy.md
index 354e99ab2..daf7cbedd 100644
--- a/src/cc/CC_made_easy.md
+++ b/src/cc/CC_made_easy.md
@@ -14,12 +14,12 @@
  *                                                                            *
  ******************************************************************************/
 
-How to write utxo based CryptoConditions contracts for KMD chains
+How to write utxo based CryptoConditions contracts for HUSH chains
 by jl777
 
 This is not the only smart contracts methodology that is possible to build on top of OP_CHECKCRYPTOCONDITION, just the first one. All the credit for getting OP_CHECKCRYPTOCONDITION working in the Komodo codebase goes to @libscott. I am just hooking into the code that he made and tried to make it just a little easier to make new contracts.
 
-There is probably some fancy marketing name to use, but for now, I will just call it "CC contract" for short, knowing that it is not 100% technically accurate as the CryptoConditions aspect is not really the main attribute. However, the KMD contracts were built to make the CryptoConditions codebase that was integrated into it to be more accessible.
+There is probably some fancy marketing name to use, but for now, I will just call it "CC contract" for short, knowing that it is not 100% technically accurate as the CryptoConditions aspect is not really the main attribute. However, the HUSH contracts were built to make the CryptoConditions codebase that was integrated into it to be more accessible.
 
 Since CC contracts run native C/C++ code, it is turing complete and that means that any contract that is possible to do on any other platform will be possible to create via CC contract.
 
@@ -655,7 +655,7 @@ Yes, blockchains are complicated.
 Chapter 13 - different languages
 The current codebase is integrated into the hushd codebase, which is C/C++. However, it is possible to use different languages and integrate into the C/C++ as zcash has shown by using the rust language for some parts of the zcashd.
 
-I think any language that is compiled and can create a linkable library while being able to call and be called by C/C++ functions can be used. If you are able to make such a language binding for a simple CC contract like faucet, this will be good for a 777 KMD bounty. Of course, you need to be the first to submit a properly working pull request.
+I think any language that is compiled and can create a linkable library while being able to call and be called by C/C++ functions can be used. If you are able to make such a language binding for a simple CC contract like faucet, this will be good for a 777 HUSH bounty. Of course, you need to be the first to submit a properly working pull request.
 
 
 Chapter 14 - runtime bindings
diff --git a/src/cc/betprotocol.h b/src/cc/betprotocol.h
index 02c0000f2..6694cb331 100644
--- a/src/cc/betprotocol.h
+++ b/src/cc/betprotocol.h
@@ -62,7 +62,7 @@ public:
     CMutableTransaction MakePostEvidenceTx(uint256 signedSessionTxHash,
             int playerIndex, std::vector<unsigned char> state);
 
-    // on KMD
+    // on HUSH
     CC* MakePayoutCond(uint256 signedSessionTxHash);
     CMutableTransaction MakeStakeTx(CAmount totalPayout, uint256 signedSessionTx);
     CMutableTransaction MakeAgreePayoutTx(std::vector<CTxOut> payouts, uint256 signedStakeTxHash);
diff --git a/src/cc/dapps/dappinc.h b/src/cc/dapps/dappinc.h
index 29c15f111..c89658e72 100644
--- a/src/cc/dapps/dappinc.h
+++ b/src/cc/dapps/dappinc.h
@@ -639,7 +639,7 @@ cJSON *get_rawmempool(char *refcoin,char *acname)
 cJSON *get_addressutxos(char *refcoin,char *acname,char *coinaddr)
 {
     cJSON *retjson; char *retstr,jsonbuf[256];
-    if ( refcoin[0] != 0 && strcmp(refcoin,"KMD") != 0 )
+    if ( refcoin[0] != 0 && strcmp(refcoin,"HUSH3") != 0 )
         printf("warning: assumes %s has addressindex enabled\n",refcoin);
     sprintf(jsonbuf,"{\\\"addresses\\\":[\\\"%s\\\"]}",coinaddr);
     if ( (retjson= get_hushcli(refcoin,&retstr,acname,"getaddressutxos",jsonbuf,"","","","","","")) != 0 )
diff --git a/src/cc/dapps/zmigrate.c b/src/cc/dapps/zmigrate.c
index bc5f8e869..0e9d08112 100644
--- a/src/cc/dapps/zmigrate.c
+++ b/src/cc/dapps/zmigrate.c
@@ -23,6 +23,8 @@
 #include "cJSON.c"
 
 /*
+NOTE: HUSH nor any Hush Smart Chain has any sprout outputs. This code is kept for historical and educational purposes.
+
  z_migrate: the purpose of z_migrate is to make converting of all sprout outputs into sapling. the usage would be for the user to specify a sapling address and call z_migrate zsaddr, until it returns that there is nothing left to be done.
  
  its main functionality is quite similar to a z_mergetoaddress ANY_ZADDR -> onetime_taddr followed by a z_sendmany onetime_taddr -> zsaddr
@@ -318,8 +320,6 @@ cJSON *get_komodocli(char *refcoin,char **retstrp,char *acname,char *method,char
 {
     long fsize; cJSON *retjson = 0; char cmdstr[32768],*jsonstr,fname[256];
     sprintf(fname,"/tmp/zmigrate.%s",method);
-    //if ( (acname == 0 || acname[0] == 0) && strcmp(refcoin,"KMD") != 0 )
-    //    acname = refcoin;
     if ( acname[0] != 0 )
     {
         if ( refcoin[0] != 0 && strcmp(refcoin,"HUSH3") != 0 )
@@ -490,7 +490,7 @@ cJSON *get_rawmempool(char *refcoin,char *acname)
 cJSON *get_addressutxos(char *refcoin,char *acname,char *coinaddr)
 {
     cJSON *retjson; char *retstr,jsonbuf[256];
-    if ( refcoin[0] != 0 && strcmp(refcoin,"KMD") != 0 )
+    if ( refcoin[0] != 0 && strcmp(refcoin,"HUSH3") != 0 )
         printf("warning: assumes %s has addressindex enabled\n",refcoin);
     sprintf(jsonbuf,"{\\\"addresses\\\":[\\\"%s\\\"]}",coinaddr);
     if ( (retjson= get_komodocli(refcoin,&retstr,acname,"getaddressutxos",jsonbuf,"","","")) != 0 )
@@ -1294,7 +1294,7 @@ void reconcile_claims(char *refcoin,char *fname)
                 else fields[n][i++] = *str++;
             }
             printf("%s\n",fields[1]);
-            total += update_claimstats(fields[1],fields[3],fields[5 + (strcmp("KMD",refcoin)==0)],atof(fields[4])*SATOSHIDEN + 0.0000000049);
+            total += update_claimstats(fields[1],fields[3],fields[5 + (strcmp("HUSH3",refcoin)==0)],atof(fields[4])*SATOSHIDEN + 0.0000000049);
             numlines++;
         }
         fclose(fp);
@@ -1358,12 +1358,12 @@ int32_t main(int32_t argc,char **argv)
                             }
                             continue;
                         }
-                        if ( strcmp(coinstr,"KMD") == 0 && verify_vin(coinstr,jbits256(item,"txid"),0,"R9JCEd6xnCxNUSpLrHEWvzPSh7CNXm7z75") < 0 )
+                        if ( strcmp(coinstr,"HUSH3") == 0 && verify_vin(coinstr,jbits256(item,"txid"),0,"R9JCEd6xnCxNUSpLrHEWvzPSh7CNXm7z75") < 0 )
                         {
                             printf("WARNING: imposter dust detected! %s\n",bits256_str(str,jbits256(item,"txid")));
                             continue;
                         }
-                        else if ( strcmp(coinstr,"KMD") != 0 && verify_vin(coinstr,jbits256(item,"txid"),0,"R9MUnxXijovvSeT9sFuUX23TiFtVvZEGjT") < 0 )
+                        else if ( strcmp(coinstr,"HUSH3") != 0 && verify_vin(coinstr,jbits256(item,"txid"),0,"R9MUnxXijovvSeT9sFuUX23TiFtVvZEGjT") < 0 )
                         {
                             printf("WARNING: imposter dust detected! %s\n",bits256_str(str,jbits256(item,"txid")));
                             continue;
diff --git a/src/cc/eval.h b/src/cc/eval.h
index b1049e7cd..d4581e8ef 100644
--- a/src/cc/eval.h
+++ b/src/cc/eval.h
@@ -224,7 +224,7 @@ public:
         if (SMART_CHAIN_SYMBOL[0]) return 1;
         if (s.size() >= 72) {
             if (strcmp("BTC", &s[68]) == 0) return 1;
-            if (strcmp("KMD", &s[68]) == 0) return 1;
+            if (strcmp("HUSH3", &s[68]) == 0) return 1;
         }
         return 0;
     }
diff --git a/src/cc/gateways.cpp b/src/cc/gateways.cpp
index d62760820..c8036e5f2 100644
--- a/src/cc/gateways.cpp
+++ b/src/cc/gateways.cpp
@@ -33,8 +33,8 @@
  
  the potential pubkeys to be used would be based on active oracle data providers with recent activity.
  
- bind asset <-> KMD gateway deposit address
- KMD deposit -> globally spendable marker utxo
+ bind asset <-> HUSH gateway deposit address
+ HUSH deposit -> globally spendable marker utxo
  spend marker utxo and spend linked/locked asset to user's CC address
  
  redeem -> asset to global CC address with withdraw address -> gateway spendable marker utxo
@@ -57,19 +57,19 @@
  In order to create a new gateway it is necessary to follow some strict steps.
  1. create a token with the max possible supply that will be issued
  2. transfer 100% of them to the gateways CC's global pubkey's asset CC address. (yes it is a bit confusing)
- 3. create an oracle with the identical name, ie. KMD and format must start with Ihh (height, blockhash, merkleroot)
+ 3. create an oracle with the identical name, ie. HUSH and format must start with Ihh (height, blockhash, merkleroot)
  4. register a publisher and fund it with a subscribe. there will be a special client app that will automatically publish the merkleroots.
  5. Now a gatewaysbind can bind an external coin to an asset, along with the oracle for the merkleroots. the txid from the bind is used in most of the other gateways CC calls
  
  usage:
- ./c tokencreate KMD 1000000 KMD_equivalent_token_for_gatewaysCC
+ ./c tokencreate HUSH 1000000 HUSH_equivalent_token_for_gatewaysCC
  a7398a8748354dd0a3f8d07d70e65294928ecc3674674bb2d9483011ccaa9a7a
  
  transfer to gateways pubkey: 03ea9c062b9652d8eff34879b504eda0717895d27597aaeb60347d65eed96ccb40 RDMqGyREkP1Gwub1Nr5Ye8a325LGZsWBCb
  ./c tokentransfer a7398a8748354dd0a3f8d07d70e65294928ecc3674674bb2d9483011ccaa9a7a 03ea9c062b9652d8eff34879b504eda0717895d27597aaeb60347d65eed96ccb40 100000000000000
  2206fc39c0f384ca79819eb491ddbf889642cbfe4d0796bb6a8010ed53064a56
  
- ./c oraclescreate KMD blockheaders Ihh
+ ./c oraclescreate HUSH blockheaders Ihh
  1f1aefcca2bdea8196cfd77337fb21de22d200ddea977c2f9e8742c55829d808
  
  ./c oraclesregister 1f1aefcca2bdea8196cfd77337fb21de22d200ddea977c2f9e8742c55829d808 1000000
@@ -79,7 +79,7 @@
  f9499d8bb04ffb511fcec4838d72e642ec832558824a2ce5aed87f1f686f8102
  
  gatewaysbind tokenid oracletxid coin tokensupply M N pubkey(s)
- ./c gatewaysbind a7398a8748354dd0a3f8d07d70e65294928ecc3674674bb2d9483011ccaa9a7a 1f1aefcca2bdea8196cfd77337fb21de22d200ddea977c2f9e8742c55829d808 KMD 100000000000000 1 1 02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92
+ ./c gatewaysbind a7398a8748354dd0a3f8d07d70e65294928ecc3674674bb2d9483011ccaa9a7a 1f1aefcca2bdea8196cfd77337fb21de22d200ddea977c2f9e8742c55829d808 HUSH 100000000000000 1 1 02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92
  e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e
  
  ./c gatewaysinfo e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e
@@ -87,7 +87,7 @@
  "result": "success",
  "name": "Gateways",
  "pubkey": "02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92",
- "coin": "KMD",
+ "coin": "HUSH",
  "oracletxid": "1f1aefcca2bdea8196cfd77337fb21de22d200ddea977c2f9e8742c55829d808",
  "taddr": 0,
  "prefix": 60,
@@ -99,7 +99,7 @@
  "issued": "0.00000000"
  }
  
- To make a gateway deposit, send the funds to the "deposit" address, along with any amount to the same pubkey address you want to get the assetized KMD to appear in.
+ To make a gateway deposit, send the funds to the "deposit" address, along with any amount to the same pubkey address you want to get the assetized HUSH to appear in.
  
  0223d114dededb04f253816d6ad0ce78dd08c617c94ce3c53bf50dc74a5157bef8 pubkey for RFpxgqff7FDHFuHa3jSX5NzqqWCcELz8ha
  ./hush-cli z_sendmany "<funding addr>" '[{"address":"RFpxgqff7FDHFuHa3jSX5NzqqWCcELz8ha","amount":0.0001},{"address":"RHV2As4rox97BuE3LK96vMeNY8VsGRTmBj","amount":7.6999}]'
@@ -112,27 +112,27 @@
  010000000149964cdcd17fe9b1cae4d0f3b5f5db301d9b4f54099fdf4d34498df281757094010000006a4730440220594f3a630dd73c123f44621aa8bb9968ab86734833453dd479af6d79ae6f584202207bb5e35f13b337ccc8a88d9a006c8c5ddb016c0a6f4f2dc44357a8128623d85d01210223154bf53cd3a75e64d86697070d6437c8f0010a09c1df35b659e31ce3d79b5dffffffff0310270000000000001976a91447d2e323a14b0c3be08698aa46a9b91489b189d688ac701de52d000000001976a91459fdba29ea85c65ad90f6d38f7a6646476b26b1688acb0a86a00000000001976a914f9a9daf5519dae38b8b61d945f075da895df441d88ace18d965b
  
  gatewaysdeposit bindtxid height coin cointxid claimvout deposithex proof destpub amount
- ./hush-cli -ac_name=AT5 gatewaysdeposit e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e 1003776 KMD bc41a00e429db741c3199f17546a48012fd3b7eea45dfc6bc2f5228278133009 0 010000000149964cdcd17fe9b1cae4d0f3b5f5db301d9b4f54099fdf4d34498df281757094010000006a4730440220594f3a630dd73c123f44621aa8bb9968ab86734833453dd479af6d79ae6f584202207bb5e35f13b337ccc8a88d9a006c8c5ddb016c0a6f4f2dc44357a8128623d85d01210223154bf53cd3a75e64d86697070d6437c8f0010a09c1df35b659e31ce3d79b5dffffffff0310270000000000001976a91447d2e323a14b0c3be08698aa46a9b91489b189d688ac701de52d000000001976a91459fdba29ea85c65ad90f6d38f7a6646476b26b1688acb0a86a00000000001976a914f9a9daf5519dae38b8b61d945f075da895df441d88ace18d965b 04000000232524ea04b54489eb222f8b3f566ed35504e3050488a63f0ab7b1c2030000007f91615f04835822bf6984a56482aeeb11d03814352eca9afc0a20192fdcae900000000000000000000000000000000000000000000000000000000000000000268e965ba608071d0800038e16762900000000000000000000000000000000000000000042008dd6fd4005016b4292b05df6dfd316c458c53e28fb2befb96e4870a40c6c04e733d75d8a7a18cce34fe326005efdc403bfa4644e30eeafdaeff34419edc591299e6cc5933cb2eeecbab5c4dfe97cd413b75215999a3dd02b540373581e81d8512bff1640590a6b4da4aaa9b8adc0102c38ca0022daed997b53ed192ba326e212fba5e505ce29e3ad149cef7f48d0e00948a1acd81731d84008760759211eb4abbc7b037939a7964182edb59cf9065357e864188ee5fc7316e8796963036bb99eeb9f06c95d64f78749ecec7181c12eb5d83a3b9b1c1e8a0aae9a20ce04a250b28216620bfc99bb81a6de4db80b93a5aea916de97c1a272e26644abdd683f19c5e3174a2e4513ed767d8f11a4c3074295f697839c5d9139676a813451cc7da38f68cbae5d990a79075f98903233ca04fe1b4b099e433585e5adcc45d41d54a9c648179297359c75950a5e574f13f70b728bbbf552770256315cd0a00139d6ab6934cb5ed70a4fc01a92611b096dd0028f17f4cc687b75f37dca530aa47a18321c50528dbd9272eabb3e13a87021a05918a6d2627e2caba6d7cf1a9f0b831ea3337b9a6af92746d83140078d60c72b6beacf91c9e68a34cee209e08670be1d17ff8d80b7a2285b1325461a2e33f2ee675593f1900e066a5d212615cd8da18749b0e684eee73edcc9031709be715b889c6d015cf4bd4ad5ab7e21bd3492c208930a54d353ef36a437f507ead38855633c1b88d060d9e4221ca8ce2f698e8a6ae0d41e9ace3cbd401f1e0f07650e9c126d4ef20278c8be6e85c7637513643f8d02d7ad64c09da11c16429d60e5160c345844b8158ece62794e8ad280d4e4664150e74978609ece431e51a9f9e1ce8aa49c16f36c7fd12b71acc42d893e18476b8b1e144a8175519612efc93e0aecc61f3b21212c958b0e2331d76aaa62faf11a58fe2bd91ab9ab01b906406c9bbc02df2a106e67182aae0a20b538bf19f09c57f9de5e198ba254580fb1b11e22ad526550093420cb7c68628d4c3ad329c8acc6e219093d277810ed016b6099b7e3781de412a22dacedaa2acf29e8062debcd85c7b9529a20b2782a2470763ac27cf89611a527d43ac89b8063ffb93b6ed993425194f8ee821a8493a563072c896f9584f95db28e3f2fc5fb4a6f3c39d615cd563641717cd50afb73ed3989cbf504b2043882993ce9575f56402534173b1396fbc13df80920b46788ae340ad5a91f25177cc74aa69024d76f56166199d2e4d50a053555256c4e3137ea1cee1130e916a88b6ee5cf2c85652fb8824d5dacfa485e3ef6190591ac0c2fcacc4fc7deb65aca4b0b89b76e35a46b0627e2e967cc63a5d606a984c8e63eabb98fde3e69114340ae524c974cb936e57690e98a7a74533f6f7d1d0496976496b54d14a8163efb32b70dfbb79d80a3022c4f53571c08bf044270565716b435084376714b224ab23e9817c05af8223723afc0577af5c8fc28f71036ca82528aaa4ca9bcd18a50e25d2a528f183d3a2074d968d170876d8dce434c5937261b55173ab87e03d5632ca0834fdc5387c15ab3a17d75c0f274004f289ff1bf7d14e97fdf4172eb49adfb418cc2f4794806ae7c0111c97df4d65d38679ec93fea3ef738ed565e8906a8fe1861cafe3938c772fedcfab40159938e06ef414fd299f2355c6d3369bc1bd3c4db64ce205f0a1b70a40030f505b736e28230de82e97776b5ee7b10708bb3020d28cec7a8e124549ec80c547ac4e7b52bf397c72bcfce30820554ab8fb4d1f73b209bc32a0e7e878843cdbf5f01222728ccea7e6ab7cb5e3fee3234f5b85d1985f91492f6ceaa6454a658dab5074f163ce26ed753137fa61c940679de13bd7b212cd3cf2b334f5201cecbc7473342bd7a239e09169bccd56d03000000037a9068df0625e548e71263c8361b4e904c998378f6b9e32729c3f19b10ad752e093013788222f5c26bfc5da4eeb7d32f01486a54179f19c341b79d420ea041bc8878d22fad4692b2d609c3cf190903874d3682a714c7483518c9392e07c25035010b 0223d114dededb04f253816d6ad0ce78dd08c617c94ce3c53bf50dc74a5157bef8 7.6999
+ ./hush-cli -ac_name=AT5 gatewaysdeposit e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e 1003776 HUSH bc41a00e429db741c3199f17546a48012fd3b7eea45dfc6bc2f5228278133009 0 010000000149964cdcd17fe9b1cae4d0f3b5f5db301d9b4f54099fdf4d34498df281757094010000006a4730440220594f3a630dd73c123f44621aa8bb9968ab86734833453dd479af6d79ae6f584202207bb5e35f13b337ccc8a88d9a006c8c5ddb016c0a6f4f2dc44357a8128623d85d01210223154bf53cd3a75e64d86697070d6437c8f0010a09c1df35b659e31ce3d79b5dffffffff0310270000000000001976a91447d2e323a14b0c3be08698aa46a9b91489b189d688ac701de52d000000001976a91459fdba29ea85c65ad90f6d38f7a6646476b26b1688acb0a86a00000000001976a914f9a9daf5519dae38b8b61d945f075da895df441d88ace18d965b 04000000232524ea04b54489eb222f8b3f566ed35504e3050488a63f0ab7b1c2030000007f91615f04835822bf6984a56482aeeb11d03814352eca9afc0a20192fdcae900000000000000000000000000000000000000000000000000000000000000000268e965ba608071d0800038e16762900000000000000000000000000000000000000000042008dd6fd4005016b4292b05df6dfd316c458c53e28fb2befb96e4870a40c6c04e733d75d8a7a18cce34fe326005efdc403bfa4644e30eeafdaeff34419edc591299e6cc5933cb2eeecbab5c4dfe97cd413b75215999a3dd02b540373581e81d8512bff1640590a6b4da4aaa9b8adc0102c38ca0022daed997b53ed192ba326e212fba5e505ce29e3ad149cef7f48d0e00948a1acd81731d84008760759211eb4abbc7b037939a7964182edb59cf9065357e864188ee5fc7316e8796963036bb99eeb9f06c95d64f78749ecec7181c12eb5d83a3b9b1c1e8a0aae9a20ce04a250b28216620bfc99bb81a6de4db80b93a5aea916de97c1a272e26644abdd683f19c5e3174a2e4513ed767d8f11a4c3074295f697839c5d9139676a813451cc7da38f68cbae5d990a79075f98903233ca04fe1b4b099e433585e5adcc45d41d54a9c648179297359c75950a5e574f13f70b728bbbf552770256315cd0a00139d6ab6934cb5ed70a4fc01a92611b096dd0028f17f4cc687b75f37dca530aa47a18321c50528dbd9272eabb3e13a87021a05918a6d2627e2caba6d7cf1a9f0b831ea3337b9a6af92746d83140078d60c72b6beacf91c9e68a34cee209e08670be1d17ff8d80b7a2285b1325461a2e33f2ee675593f1900e066a5d212615cd8da18749b0e684eee73edcc9031709be715b889c6d015cf4bd4ad5ab7e21bd3492c208930a54d353ef36a437f507ead38855633c1b88d060d9e4221ca8ce2f698e8a6ae0d41e9ace3cbd401f1e0f07650e9c126d4ef20278c8be6e85c7637513643f8d02d7ad64c09da11c16429d60e5160c345844b8158ece62794e8ad280d4e4664150e74978609ece431e51a9f9e1ce8aa49c16f36c7fd12b71acc42d893e18476b8b1e144a8175519612efc93e0aecc61f3b21212c958b0e2331d76aaa62faf11a58fe2bd91ab9ab01b906406c9bbc02df2a106e67182aae0a20b538bf19f09c57f9de5e198ba254580fb1b11e22ad526550093420cb7c68628d4c3ad329c8acc6e219093d277810ed016b6099b7e3781de412a22dacedaa2acf29e8062debcd85c7b9529a20b2782a2470763ac27cf89611a527d43ac89b8063ffb93b6ed993425194f8ee821a8493a563072c896f9584f95db28e3f2fc5fb4a6f3c39d615cd563641717cd50afb73ed3989cbf504b2043882993ce9575f56402534173b1396fbc13df80920b46788ae340ad5a91f25177cc74aa69024d76f56166199d2e4d50a053555256c4e3137ea1cee1130e916a88b6ee5cf2c85652fb8824d5dacfa485e3ef6190591ac0c2fcacc4fc7deb65aca4b0b89b76e35a46b0627e2e967cc63a5d606a984c8e63eabb98fde3e69114340ae524c974cb936e57690e98a7a74533f6f7d1d0496976496b54d14a8163efb32b70dfbb79d80a3022c4f53571c08bf044270565716b435084376714b224ab23e9817c05af8223723afc0577af5c8fc28f71036ca82528aaa4ca9bcd18a50e25d2a528f183d3a2074d968d170876d8dce434c5937261b55173ab87e03d5632ca0834fdc5387c15ab3a17d75c0f274004f289ff1bf7d14e97fdf4172eb49adfb418cc2f4794806ae7c0111c97df4d65d38679ec93fea3ef738ed565e8906a8fe1861cafe3938c772fedcfab40159938e06ef414fd299f2355c6d3369bc1bd3c4db64ce205f0a1b70a40030f505b736e28230de82e97776b5ee7b10708bb3020d28cec7a8e124549ec80c547ac4e7b52bf397c72bcfce30820554ab8fb4d1f73b209bc32a0e7e878843cdbf5f01222728ccea7e6ab7cb5e3fee3234f5b85d1985f91492f6ceaa6454a658dab5074f163ce26ed753137fa61c940679de13bd7b212cd3cf2b334f5201cecbc7473342bd7a239e09169bccd56d03000000037a9068df0625e548e71263c8361b4e904c998378f6b9e32729c3f19b10ad752e093013788222f5c26bfc5da4eeb7d32f01486a54179f19c341b79d420ea041bc8878d22fad4692b2d609c3cf190903874d3682a714c7483518c9392e07c25035010b 0223d114dededb04f253816d6ad0ce78dd08c617c94ce3c53bf50dc74a5157bef8 7.6999
  -> 9d80ea79a65aaa0d464f8b762356fa01047e16e9793505a22ca04559f81a6eb6
  
  to get the merkleroots onchain, from the multisig signers nodes run the oraclefeed program with acname oracletxid pubkey Ihh
  ./oraclefeed AT5 1f1aefcca2bdea8196cfd77337fb21de22d200ddea977c2f9e8742c55829d808 02ebc786cb83de8dc3922ab83c21f3f8a2f3216940c3bf9da43ce39e2a3a882c92 Ihh
  
  gatewaysclaim bindtxid coin deposittxid destpub amount
- ./c gatewaysclaim e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e KMD 9d80ea79a65aaa0d464f8b762356fa01047e16e9793505a22ca04559f81a6eb6 0223d114dededb04f253816d6ad0ce78dd08c617c94ce3c53bf50dc74a5157bef8 7.6999
+ ./c gatewaysclaim e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e HUSH 9d80ea79a65aaa0d464f8b762356fa01047e16e9793505a22ca04559f81a6eb6 0223d114dededb04f253816d6ad0ce78dd08c617c94ce3c53bf50dc74a5157bef8 7.6999
  
  now the asset is in the pubkey's asset address!
  it can be used, traded freely and any node who has the asset can do a gatewayswithdraw
  
  gatewayswithdraw bindtxid coin withdrawpub amount
- ./c gatewayswithdraw e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e KMD 03b7621b44118017a16043f19b30cc8a4cfe068ac4e42417bae16ba460c80f3828 1
+ ./c gatewayswithdraw e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e HUSH 03b7621b44118017a16043f19b30cc8a4cfe068ac4e42417bae16ba460c80f3828 1
  ef3cc452da006eb2edda6b6ed3d3347664be51260f3e91f59ec44ec9701367f0
  
- Now there is a withdraw pending, so it needs to be processed by the signing nodes on the KMD side
+ Now there is a withdraw pending, so it needs to be processed by the signing nodes on the HUSH side
  
  gatewayspending bindtxid coin
  gatewayspending will display all pending withdraws and if it is done on one of the msigpubkeys, then it will queue it for processing
- ./c gatewayspending e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e KMD
+ ./c gatewayspending e6c99f79d4afb216aa8063658b4222edb773dd24bb0f8e91bd4ef341f3e47e5e HUSH
  
  
  Implementation Issues:
@@ -151,10 +151,10 @@
  */
 // start of consensus code
 
-#define KMD_PUBTYPE 60
-#define KMD_P2SHTYPE 85
-#define KMD_WIFTYPE 188
-#define KMD_TADDR 0
+#define HUSH_PUBTYPE 60
+#define HUSH_P2SHTYPE 85
+#define HUSH_WIFTYPE 188
+#define HUSH_TADDR 0
 #define CC_MARKER_VALUE 10000
 
 CScript EncodeGatewaysBindOpRet(uint8_t funcid,uint256 tokenid,std::string coin,int64_t totalsupply,uint256 oracletxid,uint8_t M,uint8_t N,std::vector<CPubKey> gatewaypubkeys,uint8_t taddr,uint8_t prefix,uint8_t prefix2,uint8_t wiftype)
@@ -184,7 +184,7 @@ uint8_t DecodeGatewaysBindOpRet(char *depositaddr,const CScript &scriptPubKey,ui
     depositaddr[0] = 0;
     if ( vopret.size() > 2 && E_UNMARSHAL(vopret,ss >> e; ss >> f; ss >> coin; ss >> totalsupply; ss >> oracletxid; ss >> M; ss >> N; ss >> gatewaypubkeys; ss >> taddr; ss >> prefix; ss >> prefix2; ss >> wiftype) != 0 )
     {
-        if ( prefix == KMD_PUBTYPE && prefix2 == KMD_P2SHTYPE )
+        if ( prefix == HUSH_PUBTYPE && prefix2 == HUSH_P2SHTYPE )
         {
             if ( N > 1 )
             {
@@ -874,12 +874,12 @@ UniValue GatewaysBind(const CPubKey& pk, uint64_t txfee,std::string coin,uint256
 
     cp = CCinit(&C,EVAL_GATEWAYS);
     cpTokens = CCinit(&CTokens,EVAL_TOKENS);
-    if (coin=="KMD")
+    if (coin=="HUSH")
     {
-        prefix = KMD_PUBTYPE;
-        prefix2 = KMD_P2SHTYPE;
-        wiftype = KMD_WIFTYPE;
-        taddr = KMD_TADDR;
+        prefix = HUSH_PUBTYPE;
+        prefix2 = HUSH_P2SHTYPE;
+        wiftype = HUSH_WIFTYPE;
+        taddr = HUSH_TADDR;
     }
     else
     {
diff --git a/src/cc/importgateway.cpp b/src/cc/importgateway.cpp
index 499721909..1afaeec94 100644
--- a/src/cc/importgateway.cpp
+++ b/src/cc/importgateway.cpp
@@ -19,13 +19,11 @@
 #include "CCImportGateway.h"
 #include "key_io.h"
 #include "../importcoin.h"
-
 // start of consensus code
-
-#define KMD_PUBTYPE 60
-#define KMD_P2SHTYPE 85
-#define KMD_WIFTYPE 188
-#define KMD_TADDR 0
+#define HUSH_PUBTYPE 60
+#define HUSH_P2SHTYPE 85
+#define HUSH_WIFTYPE 188
+#define HUSH_TADDR 0
 #define CC_MARKER_VALUE 10000
 
 extern uint256 HUSH_EARLYTXID;
@@ -46,7 +44,7 @@ uint8_t DecodeImportGatewayBindOpRet(char *burnaddr,const CScript &scriptPubKey,
     burnaddr[0] = 0;
     if ( vopret.size() > 2 && E_UNMARSHAL(vopret,ss >> e; ss >> f; ss >> coin; ss >> oracletxid; ss >> M; ss >> N; ss >> importgatewaypubkeys; ss >> taddr; ss >> prefix; ss >> prefix2; ss >> wiftype) != 0 )
     {
-        if ( prefix == KMD_PUBTYPE && prefix2 == KMD_P2SHTYPE )
+        if ( prefix == HUSH_PUBTYPE && prefix2 == HUSH_P2SHTYPE )
         {
             if ( N > 1 )
             {
@@ -481,12 +479,12 @@ std::string ImportGatewayBind(uint64_t txfee,std::string coin,uint256 oracletxid
 
     cp = CCinit(&C,EVAL_IMPORTGATEWAY);
     cpTokens = CCinit(&CTokens,EVAL_TOKENS);
-    if (coin=="KMD")
+    if (coin=="HUSH")
     {
-        prefix = KMD_PUBTYPE;
-        prefix2 = KMD_P2SHTYPE;
-        wiftype = KMD_WIFTYPE;
-        taddr = KMD_TADDR;
+        prefix = HUSH_PUBTYPE;
+        prefix2 = HUSH_P2SHTYPE;
+        wiftype = HUSH_WIFTYPE;
+        taddr = HUSH_TADDR;
     }
     else
     {
diff --git a/src/cc/importpayout.cpp b/src/cc/importpayout.cpp
index 2740d8ef2..a3fd90394 100644
--- a/src/cc/importpayout.cpp
+++ b/src/cc/importpayout.cpp
@@ -31,7 +31,7 @@
  * notarised on another chain.
  *
  * IN: params - condition params
- * IN: importTx - Payout transaction on value chain (KMD)
+ * IN: importTx - Payout transaction on value chain (HUSH)
  * IN: nIn  - index of input of stake
  *
  * importTx: Spends stakeTx with payouts from asset chain
diff --git a/src/cc/makerogue b/src/cc/makerogue
index ff16cbb16..408b35c77 100755
--- a/src/cc/makerogue
+++ b/src/cc/makerogue
@@ -1,12 +1,14 @@
 #!/bin/sh
+# Copyright 2016-2021 The Hush developers
 cd rogue;
 make clean;
 
 if [ "$HOST" = "x86_64-w64-mingw32" ]; then
-  echo building rogue.exe...
+  echo "Not supported"
+  exit 1
   ./configure --host=x86_64-w64-mingw32
   echo $PWD
-  wget https://github.com/KomodoPlatform/rogue/releases/download/0.3.3b-01/x86_64-w64-mingw32.tar.gz
+  # wget ...
   tar xvfz x86_64-w64-mingw32.tar.gz && rm x86_64-w64-mingw32.tar.gz
   echo lib archive cleaned
   echo $PWD
diff --git a/src/cc/pegs.cpp b/src/cc/pegs.cpp
index 7ee5c815b..47570fe05 100644
--- a/src/cc/pegs.cpp
+++ b/src/cc/pegs.cpp
@@ -31,45 +31,45 @@ pegs CC is able to create a coin backed (by any supported coin with gateways CC
  
  <one hour later...>
  
- OK, now we are ready to describe the pegs CC. Let us imagine an -ac_import sidechain with KMD gateways CC. Now we have each native coin fungible with the real KMD via the gateways deposit/withdraw mechanism. Let us start with that and make a pegged and backed USD chain.
+ OK, now we are ready to describe the pegs CC. Let us imagine an -ac_import sidechain with HUSH gateways CC. Now we have each native coin fungible with the real HUSH via the gateways deposit/withdraw mechanism. Let us start with that and make a pegged and backed USD chain.
  
  <alternatively we can start from a CC enabled chain with external value>
  
- Here the native coin is KMD, but we want USD, so there needs to be a way to convert the KMD amounts into USD amounts. Something like "KMDBTC, BTCUSD, *, 1" which is the prices CC syntax to calculate KMD/USD, which is exactly what we need. So now we can assume that we have a block by block usable KMD/USD price. implementationwise, there can be an -ac option like -ac_peg="KMDBTC, BTCUSD, *, 1" and in conjunction with -ac_import=KMD gateways CC sidechain, we now have a chain where deposit of KMD issues the correct USD coins and redeem of USD coins releases the correct number of KMD coins.
+ Here the native coin is HUSH, but we want USD, so there needs to be a way to convert the HUSH amounts into USD amounts. Something like "HUSHBTC, BTCUSD, *, 1" which is the prices CC syntax to calculate HUSH/USD, which is exactly what we need. So now we can assume that we have a block by block usable HUSH/USD price. implementationwise, there can be an -ac option like -ac_peg="HUSHBTC, BTCUSD, *, 1" and in conjunction with -ac_import=HUSH gateways CC sidechain, we now have a chain where deposit of HUSH issues the correct USD coins and redeem of USD coins releases the correct number of HUSH coins.
  
  Are we done yet?
  
- Not quite, as the prices of KMD will be quite volatile relative to USD, which is good during bull markets, not so happy during bear markets. There are 2 halves to this problem, how to deal with massive price increase (easy to solve), how to solve 90% price drop (a lot harder).
+ Not quite, as the prices of HUSH will be quite volatile relative to USD, which is good during bull markets, not so happy during bear markets. There are 2 halves to this problem, how to deal with massive price increase (easy to solve), how to solve 90% price drop (a lot harder).
  
  In order to solve both, what is needed is an "account" based tracking which updates based on both price change, coins issued, payments made. So let us create an account that is based on a specific pubkey, where all relevant deposits, issuances, withdraws are tracked via appropriate vin/vout markers.
  
- Let us modify the USD chain above so that only 80% of the possible USD is issued and 20% held in reserve. This 80% should be at least some easily changeable #define, or even an -ac parameter. We want the issued coins to be released without any encumberances, but the residual 20% value is still controlled (owned) but the depositor. This account has the amount of KMD deposited and USD issued. At the moment of deposit, there will still be 20% equity left. Let us start with 1000 KMD deposit, $1.5 per KMD -> 800 KMD converted to 1200 USD into depositor pubkey and the account of (1000 KMD, -1200 USD) = 200 KMD or $300 equity.
+ Let us modify the USD chain above so that only 80% of the possible USD is issued and 20% held in reserve. This 80% should be at least some easily changeable #define, or even an -ac parameter. We want the issued coins to be released without any encumberances, but the residual 20% value is still controlled (owned) but the depositor. This account has the amount of HUSH deposited and USD issued. At the moment of deposit, there will still be 20% equity left. Let us start with 1000 HUSH deposit, $1.5 per HUSH -> 800 HUSH converted to 1200 USD into depositor pubkey and the account of (1000 HUSH, -1200 USD) = 200 HUSH or $300 equity.
  
- Now it becomes easy for the bull market case, which is to allow (for a fee like 1%) issuance of more USD as the equity increases, so let us imagine KMD at $10:
+ Now it becomes easy for the bull market case, which is to allow (for a fee like 1%) issuance of more USD as the equity increases, so let us imagine HUSH at $10:
  
- (1000 KMD, -1200 USD, 200KMD reserve) -> $2000 equity, issue 80% -> $1600 using 160 KMD
- (1000 KMD, -1200 USD, 200KMD reserve, -160KMD, issue $1600 USD, 40 KMD reserve)
+ (1000 HUSH, -1200 USD, 200HUSH reserve) -> $2000 equity, issue 80% -> $1600 using 160 HUSH
+ (1000 HUSH, -1200 USD, 200HUSH reserve, -160HUSH, issue $1600 USD, 40 HUSH reserve)
  
- we have $2800 USD in circulation, 40 KMD reserve left against $10000 marketcap of the original deposit. It it easy to see that there are never any problems with lack of KMD to redeem the issued USD in a world where prices only go up. Total USD issuance can be limited by using a decentralized account tracking based on each deposit.
+ we have $2800 USD in circulation, 40 HUSH reserve left against $10000 marketcap of the original deposit. It it easy to see that there are never any problems with lack of HUSH to redeem the issued USD in a world where prices only go up. Total USD issuance can be limited by using a decentralized account tracking based on each deposit.
  
  What is evident though is that with the constantly changing price and the various times that all the various deposits issue USD, the global reserves are something that will be hard to predict and in fact needs to be specifically tracked. Let us combine all accounts exposure in to a global reserves factor. This factor will control various max/min/ allowed and fee percentages.
  
  Now we are prepared to handle the price goes down scenario. We can rely on the global equity/reserve ratio to be changing relatively slowly as the reference price is the smooted trustless oracles price. This means there will be enough blocks to adjust the global reserves percentage. What we need to do is liquidate specific positions that have the least reserves.
  
- What does liquidation mean? It means a specific account will be purchased at below its current value and the KMD withdrawn. Let us assume the price drops to $5:
+ What does liquidation mean? It means a specific account will be purchased at below its current value and the HUSH withdrawn. Let us assume the price drops to $5:
  
- (1000 KMD, -1200 USD, 200KMD reserve, -160KMD, issue $1600 USD, 40 KMD reserve) 1000 KMD with 2800 USD issued so $2200 reserves. Let us assume it can be liquidated at a 10% discount, so for $2000 in addition to the $2800, the 5000 KMD is able to be withdrawn. This removes 4800 USD coins for 1000 KMD, which is a very low reserve amount of 4%. If a low reserve amount is removed from the system, then the global reserve amount must be improved.
+ (1000 HUSH, -1200 USD, 200HUSH reserve, -160HUSH, issue $1600 USD, 40 HUSH reserve) 1000 HUSH with 2800 USD issued so $2200 reserves. Let us assume it can be liquidated at a 10% discount, so for $2000 in addition to the $2800, the 5000 HUSH is able to be withdrawn. This removes 4800 USD coins for 1000 HUSH, which is a very low reserve amount of 4%. If a low reserve amount is removed from the system, then the global reserve amount must be improved.
  
  In addition to the global reserves calculation, there needs to be a trigger percentage that enables positions to be liquidated. We also want to liquidate the worst positions, so in addition to the trigger percentage, there should be a liquidation threshold, and the liquidator would need to find 3 or more better positions that are beyond the liquidation threshold, to be able to liquidate. This will get us to at most 3 accounts that could be liquidated but are not able to, so some method to allow those to also be liquidated. The liquidating nodes are making instant profits, so they should be expected to do whatever blockchain scanning and proving to make things easy for the rest of the nodes.
  
  One last issue is the normal redemption case where we are not liquidating. In this case, it should be done at the current marketprice, should improve the global reserves metrics and not cause anybody whose position was modified to have cause for complaint. Ideally, there would be an account that has the identical to the global reserve percentage and also at the same price as current marketprice, but this is not realistic, so we need to identify classes of accounts and consider which ones can be fully or partially liquidated to satisfy the constraints.
  
  looking at our example account:
- (1000 KMD, -1200 USD, 200KMD reserve, -160KMD, issue $1600 USD, 40 KMD reserve)
+ (1000 HUSH, -1200 USD, 200HUSH reserve, -160HUSH, issue $1600 USD, 40 HUSH reserve)
 
- what sort of non-liquidation withdraw would be acceptable? if the base amount 1000 KMD is reduced along with USD owed, then the reserve status will go up for the account. but that would seem to allow extra USD to be able to be issued. there should be no disadvantage from funding a withdraw, but also not any large advantage. it needs to be a neutral event.... 
+ what sort of non-liquidation withdraw would be acceptable? if the base amount 1000 HUSH is reduced along with USD owed, then the reserve status will go up for the account. but that would seem to allow extra USD to be able to be issued. there should be no disadvantage from funding a withdraw, but also not any large advantage. it needs to be a neutral event.... 
  
- One solution is to allow for the chance for any account to be liquidated, but the equity compensated for with a premium based on the account reserves. So in the above case, a premium of 5% on the 40KMD reserve is paid to liquidate its account. Instead of 5% premium, a lower 1% can be done if based on the MAX(correlated[daywindow],smoothed) so we get something that is close to the current marketprice. To prevent people taking advantage of the slowness of the smoothed price to adjust, there would need to be a one day delay in the withdraw. 
+ One solution is to allow for the chance for any account to be liquidated, but the equity compensated for with a premium based on the account reserves. So in the above case, a premium of 5% on the 40HUSH reserve is paid to liquidate its account. Instead of 5% premium, a lower 1% can be done if based on the MAX(correlated[daywindow],smoothed) so we get something that is close to the current marketprice. To prevent people taking advantage of the slowness of the smoothed price to adjust, there would need to be a one day delay in the withdraw. 
  
  From a practical sense, it seems a day is a long time, so maybe having a way to pay a premium like 10%, or wait a day to get the MAX(correlated[daywindow],smoothed) price. This price "jumping" might also be taken advantage of in the deposit side, so similar to prices CC it seems good to have the MAX(correlated[daywindow],smoothed) method.
  
diff --git a/src/hush_events.h b/src/hush_events.h
index ab92521ec..6d733483d 100644
--- a/src/hush_events.h
+++ b/src/hush_events.h
@@ -117,7 +117,7 @@ void hush_event_undo(struct hush_state *sp,struct hush_event *ep)
     {
         case HUSH_EVENT_RATIFY: printf("rewind of ratify, needs to be coded.%d\n",ep->height); break;
         case HUSH_EVENT_NOTARIZED: break;
-        case HUSH_EVENT_KMDHEIGHT:
+        case HUSH_EVENT_HUSHHEIGHT:
             if ( ep->height <= sp->SAVEDHEIGHT )
                 sp->SAVEDHEIGHT = ep->height;
             break;
@@ -175,7 +175,7 @@ void hush_eventadd_kmdheight(struct hush_state *sp,char *symbol,int32_t height,i
     if ( kmdheight > 0 ) {
         buf[0] = (uint32_t)kmdheight;
         buf[1] = timestamp;
-        hush_eventadd(sp,height,symbol,HUSH_EVENT_KMDHEIGHT,(uint8_t *)buf,sizeof(buf));
+        hush_eventadd(sp,height,symbol,HUSH_EVENT_HUSHHEIGHT,(uint8_t *)buf,sizeof(buf));
         if ( sp != 0 )
             komodo_setkmdheight(sp,kmdheight,timestamp);
     } else {
diff --git a/src/hush_structs.h b/src/hush_structs.h
index 1dda55a08..fde010d7b 100644
--- a/src/hush_structs.h
+++ b/src/hush_structs.h
@@ -33,7 +33,7 @@
 #define HUSH_MAXBLOCKS 250000 // DONT CHANGE
 #define HUSH_EVENT_RATIFY 'P'
 #define HUSH_EVENT_NOTARIZED 'N'
-#define HUSH_EVENT_KMDHEIGHT 'K'
+#define HUSH_EVENT_HUSHHEIGHT 'K'
 #define HUSH_EVENT_REWIND 'B'
 #define HUSH_EVENT_PRICEFEED 'V'
 #define HUSH_EVENT_OPRETURN 'R'
diff --git a/src/rpc/server.h b/src/rpc/server.h
index d809597f1..4e301ea8c 100644
--- a/src/rpc/server.h
+++ b/src/rpc/server.h
@@ -351,6 +351,7 @@ extern UniValue getrawchangeaddress(const UniValue& params, bool fHelp, const CP
 extern UniValue setaccount(const UniValue& params, bool fHelp, const CPubKey& mypk);
 extern UniValue getaccount(const UniValue& params, bool fHelp, const CPubKey& mypk);
 extern UniValue getaddressesbyaccount(const UniValue& params, bool fHelp, const CPubKey& mypk);
+extern UniValue listaddresses(const UniValue& params, bool fHelp, const CPubKey& mypk);
 extern UniValue sendtoaddress(const UniValue& params, bool fHelp, const CPubKey& mypk);
 extern UniValue signmessage(const UniValue& params, bool fHelp, const CPubKey& mypk);
 extern UniValue verifymessage(const UniValue& params, bool fHelp, const CPubKey& mypk);
diff --git a/src/wallet/rpcwallet.cpp b/src/wallet/rpcwallet.cpp
index e1dd4e8e9..55af77ce2 100644
--- a/src/wallet/rpcwallet.cpp
+++ b/src/wallet/rpcwallet.cpp
@@ -423,6 +423,37 @@ UniValue getaccount(const UniValue& params, bool fHelp, const CPubKey& mypk)
     return strAccount;
 }
 
+UniValue listaddresses(const UniValue& params, bool fHelp, const CPubKey& mypk)
+{
+    if (!EnsureWalletIsAvailable(fHelp))
+        return NullUniValue;
+
+    if (fHelp || params.size() != 1)
+        throw runtime_error(
+            "listaddresses\n"
+            "\nResult:\n"
+            "[                     (json array of string)\n"
+            "  \"" + strprintf("%s",hush_chainname()) + "_address\"  (string) a " + strprintf("%s",hush_chainname()) + " address associated with the given account\n"
+            "  ,...\n"
+            "]\n"
+            "\nExamples:\n"
+            + HelpExampleCli("listaddresses", "")
+            + HelpExampleRpc("listaddresses", "")
+        );
+
+    LOCK2(cs_main, pwalletMain->cs_wallet);
+
+    string strAccount = AccountFromValue(params[0]);
+
+    // Find all taddrs
+    UniValue ret(UniValue::VARR);
+    for (const std::pair<CTxDestination, CAddressBookData>& item : pwalletMain->mapAddressBook) {
+        const CTxDestination& dest = item.first;
+        const std::string& strName = item.second.name;
+        ret.push_back(EncodeDestination(dest));
+    }
+    return ret;
+}
 
 UniValue getaddressesbyaccount(const UniValue& params, bool fHelp, const CPubKey& mypk)
 {
@@ -441,8 +472,8 @@ UniValue getaddressesbyaccount(const UniValue& params, bool fHelp, const CPubKey
             "  ,...\n"
             "]\n"
             "\nExamples:\n"
-            + HelpExampleCli("getaddressesbyaccount", "\"tabby\"")
-            + HelpExampleRpc("getaddressesbyaccount", "\"tabby\"")
+            + HelpExampleCli("getaddressesbyaccount", "\"\"")
+            + HelpExampleRpc("getaddressesbyaccount", "\"\"")
         );
 
     LOCK2(cs_main, pwalletMain->cs_wallet);
@@ -8277,6 +8308,7 @@ static const CRPCCommand commands[] =
     { "wallet",             "getaccount",               &getaccount,               true  },
     { "wallet",             "getalldata",               &getalldata,               true  },
     { "wallet",             "getaddressesbyaccount",    &getaddressesbyaccount,    true  },
+    { "wallet",             "listaddresses",            &listaddresses        ,    true  },
     { "wallet",             "getbalance",               &getbalance,               false },
     { "wallet",             "getnewaddress",            &getnewaddress,            true  },
     { "wallet",             "getrawchangeaddress",      &getrawchangeaddress,      true  },
diff --git a/src/wallet/walletdb.cpp b/src/wallet/walletdb.cpp
index 937d3b15c..7b286c2c7 100644
--- a/src/wallet/walletdb.cpp
+++ b/src/wallet/walletdb.cpp
@@ -441,7 +441,7 @@ ReadKeyValue(CWallet* pwallet, CDataStream& ssKey, CDataStream& ssValue,
             ssValue >> wtx;
             CValidationState state;
             auto verifier = libzcash::ProofVerifier::Strict();
-            // ac_public chains set at height like KMD and ZEX, will force a rescan if we dont ignore this error: bad-txns-acpublic-chain
+            // ac_public chains which enable at a certain height instead of from genesis, this will force a rescan if we dont ignore this error: bad-txns-acpublic-chain
             // there cannot be any ztx in the wallet on ac_public chains that started from block 1, so this wont affect those. 
             // ac_private chains fail this check for notary nodes, need exception. Triggers full rescan without it. 
             if ( !(CheckTransaction(0,wtx, state, verifier, 0, 0) && (wtx.GetHash() == hash) && state.IsValid()) && (state.GetRejectReason() != "bad-txns-acpublic-chain" && state.GetRejectReason() != "bad-txns-acprivacy-chain" && state.GetRejectReason() != "bad-txns-stakingtx") )