Was able to successfully deposit 100,000tツ and trade it for tBTC once I set my refund wallet address for BTC. The site works great, and my test withdrawal of 100tツ went through immediately which was so nice.
3 Likes
Right now there is a known bug on deposit and withdrawal, I’m trying to fix it.
2 Likes
I see 2 TX, and it shows true for kernel 0849c2fb8a7d66bfa3ca92b9867a947c7ce6045b48aa342134a4b251bb0596bd62
but on blockchain I see 0998d85e651d03f4994d0527a6feced6c7da926615084a295105a3b4501767e336
so here kernel changed in-between the receiver got correct one but sender got 0998d85e651d03f4994d0527a6feced6c7da926615084a295105a3b4501767e336 but show as false for confirmed. Doesn’t make sense at all.
2 Likes
I dunno if any of this is true but this is what gpt thinks:
Totally get why that looks weird. In Grin it can happen, and it’s usually benign. Here’s what’s going on and how to fix it.
What likely happened
• **Kernels are unique to a specific final transaction.** If anything in the slate changes before broadcast (fees, lock_height, features, or even a rebuild/repost), the **kernel hash changes**.
• It’s common for the **sender’s wallet** to keep an old, now-stale tx entry (with kernel 0998…e336) that never made it on-chain, while the **receiver** (or the network node that finally posted it) broadcast the slightly-updated final tx (with kernel 0849…bd62) that **did** confirm.
• Another possibility is a **repost** after the first attempt stalled in stem/mempool; the wallet recreated the tx and produced a new kernel. The original stays in your wallet log showing confirmed: false forever unless you repair/cancel it.
• This is not a double spend; only the kernel that appears on-chain is real. The other is just an **orphaned wallet record**.
How to verify & clean it up (sender side)
1\. **List your txs with details**
grin-wallet txs -i
grin-wallet txs -i <tx_id> -v
• Confirm which entry shows kernel 0849…bd62 (the on-chain one) and which shows 0998…e336 (the stale one).
2\. **Repair your wallet state**
grin-wallet repair
• This reconciles with the chain, updates confirmations, and often resolves stray/unconfirmed logs.
3\. If the stale entry still lingers as unconfirmed, **cancel it explicitly**:
grin-wallet cancel -i <tx_id_of_0998…e336>
• This only affects your local log; it won’t touch the confirmed tx.
4\. (Optional) **Check the block explorer** for the confirmed kernel 0849…bd62 to see its block height and confs. That’s the source of truth.
Why receiver “looks right”
The receiver finalized/broadcast the version that got mined, so their wallet points to the on-chain kernel (0849…bd62) and shows confirmed: true. Your wallet just retained an earlier attempt (0998…e336) that never confirmed.
If you paste the output of grin-wallet txs -i for those two entries (or the block height you see for 0849…bd62), I’ll map them 1:1 and confirm everything lines up.
2 Likes
It doesn’t seem to like XMR testnet addresses starting with B, I have tried two of them now. Also, which Polygon testnet is the USDT on?
Great work @nonlogs this is very nice. Please keep us posted when the Grin/BTC pair is live.
4 Likes
It’d be nice if you displayed the BTC (buy side) and GRIN (sell side) wallet balances here on the GRIN/BTC market page. Then you could click the balance and have it populate the max quantity you can buy/sell. It’s a feature TO had that I really liked.
2 Likes
I don’t know what happened exactly, but here are some points that could be helpful for you.
-
If you know how to re-create the issue, report it on grin-wallet github.
-
Canceling a transaction is local to your wallet, you can’t cancel a transaction that was already broadcasted into the network.
-
Messy things can happen to your wallet if you cancel an already broadcasted transaction that haven’t received any confirmations yet: Canceling a transaction may result in an incorrect wallet balance · Issue #739 · mimblewimble/grin-wallet · GitHub
2 Likes
I spoke with them and they were running two wallets from the same seed phrase which was most likely causing the issues. It’s a simple mistake I see a lot of new Grinners commit.
2 Likes
But there is no such command as grin-wallet repair I think it was changed to grin-wallet scan (which would scan the whole wallet) but still it didn’t get fixed. I think, as @transatoshi mentioned, it could be related to running the same wallet on multiple devices.
1 Like
I’m running the stage-net not test-net.
Stagenet
-
Standard address → starts with
5 -
Subaddress → starts with
7
you can use this website for faucet: https://stagenet-faucet.xmr-tw.org/ or CypherFaucet | Monero Stagenet Faucet (sXMR)
2 Likes
I would take that into account.
2 Likes
That’s what I get for assuming things.