ChatCrawlersearch across public Telegram Open the app
I

Igra Network Community

679 members
12 July 2026
M
Mike D
Sa1𐤊rishnatext not yet in the index
Yes, however it's not returning the gas back to me, I think I may have the wrong return wallet set up incorrectly. So this is causing me to have a zero balance in my wallet 0 and then I'm getting penalized for it with my staked igra . I paused my attester from my dashboard to prevent them penalizing fee to keep occurring until I figure out why the 0 Wallet is not getting the balance of gas fees returned
S
Sa1𐤊rishna
The L1 gas fee is not refunded. The ikas will be refunded for a successful attestion
Sa1𐤊rishnaThe L1 gas fee is not refunded. The ikas will be refunded for a successful attestion
I found the problem. This is not about the normal L1 gas fee being refunded. My Orchestra .env had the same Igra locking address set as W0_WALLET_TO_ADDRESS through W4_WALLET_TO_ADDRESS, instead of each node wallet’s own Kaspa return/change address. Because of that, when wallet 0 submitted transactions, the small L1 fee was paid normally, but the remaining KAS change was also sent to the Igra locking address. Two transactions moved approximately 9.996 KAS and 29.998 KAS, leaving wallet 0 at zero. The attestor then continued being selected but could not submit transactions, which caused about 104 IGRA in penalties. I have now run sync-wallet-addresses.sh, confirmed that wallets 0–4 each have their own correct return address, recreated the wallet and RPC containers, and all five are healthy. I also paused the attestor and stopped the local attestor container to prevent further penalties. I need help determining whether the approximately 39.994 KAS sent to the locking address can be recovered or credited, and I would also appreciate confirmation that my corrected setup is now safe before I fund wallet 0 and resume.
Replymessage unavailable
I found the problem. This is not about the normal L1 gas fee being refunded. My Orchestra .env had the same Igra locking address set as W0_WALLET_TO_ADDRESS through W4_WALLET_TO_ADDRESS, instead of each node wallet’s own Kaspa return/change address. Because of that, when wallet 0 submitted transactions, the small L1 fee was paid normally, but the remaining KAS change was also sent to the Igra locking address. Two transactions moved approximately 9.996 KAS and 29.998 KAS, leaving wallet 0 at zero. The attestor then continued being selected but could not submit transactions, which caused about 104 IGRA in penalties. I have now run sync-wallet-addresses.sh, confirmed that wallets 0–4 each have their own correct return address, recreated the wallet and RPC containers, and all five are healthy. I also paused the attestor and stopped the local attestor container to prevent further penalties. I need help determining whether the approximately 39.994 KAS sent to the locking address can be recovered or credited, and I would also appreciate confirmation that my corrected setup is now safe before I fund wallet 0 and resume.
Mike D
Sa1𐤊rishnaYou have the kas on the wallet 4 ? You can recover them via your keys anytime
Wallet 4 does not contain the KAS. I checked wallets 0–4 directly from the node: Wallet 0: 0 KAS Wallet 1: 1 KAS Wallets 2–4: 0 KAS Wallet 4’s address is: kaspa:qz3ete0gpw752j3rvnajgudyd96797n0qhga8v83ypyrfl496kxyglwndlkz6 The approximately 39.994 KAS was sent to: kaspa:qpjdhxr6642qjs4hg874cw555ez78yt3tn39uu0flmt0z8ur2gczcwftnuszs That address has over 119,000 transactions and is not one of my five node wallets. Please explain exactly how wallet 4 supposedly controls that address and provide the official recovery procedure. I will not send or reveal any seed phrase, private key, password, or key file.
M
Replymessage unavailable
My 39.994 KAS was sent to: kaspa:qpjdhxr6642qjs4hg874cw555ez78yt3tn39uu0flmt0z8ur2gczcwftnuszs That address has over 119,000 transactions and is not one of my five node wallets. Please explain exactly how wallet 4 supposedly controls that address and provide the official recovery procedure. I will not send or reveal any seed phrase, private key, password, or key file.
Sa1𐤊rishna
Mike DWallet 4 does not contain the KAS. I checked wallets 0–4 directly from the node: Wallet 0: 0 KAS Wallet 1: 1 KAS Wallets 2–4: 0 KAS Wallet 4’s address is: kaspa:qz3ete0gpw752j3rvnajgudyd96797n0qhga8v83ypyrfl496kxyglwndlkz6 The approximately 39.994 KAS was sent to: kaspa:qpjdhxr6642qjs4hg874cw555ez78
Not wallet 4 the message was supposed to be any of the 4 wallets. I think the kas might be on the change address of wallet 0 and all dms are scams. Wait for @argonmining to confirm
S
If anyone is claiming to be admin in dms they are scammers
A
Replymessage unavailable
Ссылка
click to show
On that kaspa wallet kaspa:qpjdhxr6642qjs4hg874cw555ez78yt3tn39uu0flmt0z8ur2gczcwftnuszs I see two txns that add up to roughly that total of 39.994 KAS https://kaspa.stream/transactions/97b1e93636bb6521a6f69c757010e0c5e4452620d8c9815432f03650c94bcedf?blockHash=77d8a8932cfc92ca9a04270e61dacf6e09a4a7cbae547817ec6a041cff3da8d1 https://kaspa.stream/transactions/97b19ee2972b9b10964917a20e421ef61065b6cbcc846872204e8e73a47a5864?blockHash=92fc35d37585f8ead219810fae0a33d07f2c1c9abcef6a898b57ec8a69cc7bec
Mike D
Sa1𐤊rishnaNot wallet 4 the message was supposed to be any of the 4 wallets. I think the kas might be on the change address of wallet 0 and all dms are scams. Wait for @argonmining to confirm
Thank you. I will wait for @argonmining to confirm. Wallet 0’s displayed/default address is kaspa:qzlw...vgqmup, while the KAS went to kaspa:qpjdhx...tnuszs. The qpj... address has over 119,000 transactions and receives funds from many unrelated addresses, so it does not appear to be an ordinary private change address. Please provide the exact official command to verify whether wallet 0’s existing keys control that address, and the official recovery steps. I will run commands locally, but I will not reveal or send my mnemonic, private key, password, or key file. And yes, a lot of private DM's , but I know better , ty
M
AshtonOn that kaspa wallet kaspa:qpjdhxr6642qjs4hg874cw555ez78yt3tn39uu0flmt0z8ur2gczcwftnuszs I see two txns that add up to roughly that total of 39.994 KAS https://kaspa.stream/transactions/97b1e93636bb6521a6f69c757010e0c5e4452620d8c9815432f03650c94bcedf?blockHash=77d8a8932cfc92ca9a04270e61dacf6e09a4a7c
Yes, those are the two transactions: 97b1e93636bb6521a6f69c757010e0c5e4452620d8c9815432f03650c94bcedf — about 29.998028 KAS 97b19ee2972b9b10964917a20e421ef61065b6cbccc846872204e8e73a47a5864 — about 9.996066 KAS Both were sent from wallet 0 after W0_WALLET_TO_ADDRESS was incorrectly set to kaspa:qpjdhx...tnuszs. I have now corrected all five W*_WALLET_TO_ADDRESS values using sync-wallet-addresses.sh, recreated the wallet/RPC containers, and verified they are healthy. Can you please confirm: Who controls the qpjdhx...tnuszs address? Whether the 39.994 KAS can be recovered or credited back to my wallet 0? The exact official recovery procedure? My attestor remains paused and the local attestor container is stopped.
M
Mike D
AshtonI dont know who controls that address. It will take some research
Thank you for researching it. One important detail: I did not manually choose or type the qpjdhx...tnuszs address. It was already present in the Orchestra .env.mainnet.example file as the return address for W0 through W4, and it was copied into my active .env. The official documentation says sync-wallet-addresses.sh must replace those values with each running wallet’s actual address before the workers are used. That synchronization apparently did not happen during my original setup. Could you please investigate: Why that specific address was included in the official mainnet example. Who controls it. Whether the setup script should have blocked RPC transactions until wallet addresses were synchronized. How the 39.994094 KAS can be returned. I have screenshots of the original .env.mainnet.example, the active .env, both transaction IDs, and the corrected configuration. I will preserve all files and logs.
A
Ashton
Mike DThank you for researching it. One important detail: I did not manually choose or type the qpjdhx...tnuszs address. It was already present in the Orchestra .env.mainnet.example file as the return address for W0 through W4, and it was copied into my active .env. The official documentation says sync-wa
Yes exactly. So that is a bit of user error on the initial startup, I just dont know if that is a random placeholder address or if someone actually controls it. Regardless, if you have corrected the env file youre node and attester are fine to run, you just need to fund the W0 wallet
M
Mike D
AshtonYes exactly. So that is a bit of user error on the initial startup, I just dont know if that is a random placeholder address or if someone actually controls it. Regardless, if you have corrected the env file youre node and attester are fine to run, you just need to fund the W0 wallet
Understood. I accept that the wallet-address synchronization step was missed during my initial setup. However, the address was already present in the official example configuration, and the software allowed transactions to proceed without verifying that it matched wallet 0. Before I fund W0 and resume, I need confirmation of: Whether kaspa:qpjdhx...tnuszs is controlled by Igra or another known party. Whether the approximately 39.994094 KAS can be recovered. Whether there is an official safeguard or validation command to confirm the corrected return address is being used before I send more KAS. My attestor will remain paused until those points are confirmed.
M
Mike D
AshtonYes exactly. So that is a bit of user error on the initial startup, I just dont know if that is a random placeholder address or if someone actually controls it. Regardless, if you have corrected the env file youre node and attester are fine to run, you just need to fund the W0 wallet
Also, My wallet return address is now confirmed correctly inside rpc-provider-0. However, docker inspect exposed my current KASWALLET_PASSWORD. What is the official procedure to rotate the password for the existing keys.kaswallet-0.json wallet without replacing or losing the wallet keys?
13 July 2026
M
Mike D
Replymessage unavailable
I located the setup video instructions on YouTube . At approximately 30:29–35:27, the presenter explicitly explains that W0–W4_WALLET_TO_ADDRESS are change-return addresses and warns that leaving the placeholder causes the entire remaining UTXO to be sent to somebody else. This exactly matches my transactions: approximately 9.996066 KAS and 29.998028 KAS were routed to the placeholder, while only tiny L1 fees were actually charged. My configuration is now corrected. Please ask the developers who generated or controls the placeholder address and whether its private key is available to return the 39.994094 KAS.
M
Mike D
Replymessage unavailable
Hi IGRA Team, I have an attester running on mainnet and would like to verify whether my behavior is expected. Operator: 0x6309549Db0C9cB8Bd81792DE7B5e35d71b263b91 Current status: ✅ Attester is Active on the dashboard. ✅ Stake: 400,140 IGRA (effective 400,001 after penalties). ✅ Node is fully synced and healthy. ✅ Attester Docker container is healthy. ✅ Operator wallet has sufficient KAS for gas (currently ~11 KAS). ✅ iKAS balance is available. However, the attester logs repeatedly show: Submitting attestation... ERROR: Transaction dropped or not mined Transient attestation failure, will retry The dashboard currently shows: Attestations: 0 IAS Score: 0 Rewards: 0 My questions are: Is this expected behavior at the current stage of the network? Is my attester actually participating despite these log messages? Is there anything I should change in my configuration? Thank you!
Open in Telegram Каталог площадок Искать в ChatCrawler

A snapshot of an open public feed from the search index ChatCrawler — “Google for public Telegram”; refreshed as the venue is crawled. Times are UTC.

Public content only, official Telegram API. About · FAQ · What we do not do · Remove a page · Catalog