๐[BUG] Claiming MIA keeps getting rolled back by post-condition
Opened this issue ยท 5 comments
Describe the bug
Every time I try to claim my MIA, the transaction goes through, but the transaction says "Notice
This transaction would have succeeded, but was rolled back by a supplied post-condition."
To Reproduce
Steps to reproduce the behavior:
- Go to https://minecitycoins.com/stacking?chain=mainnet
- Select city "MIA"
- Click on button "Claim"
- Approve transaction
Expected behavior
Transaction should succeed and I should receive my 199,870.000000.
Desktop (please complete the following information):
- OS: Mac OS
- Browser: Firefox
- Version 115.0.3 (64-bit)
Additional context
I have tried doing this several times, with several fee rates. This is an example with the largest fee rate: https://explorer.hiro.so/txid/0x456578e655754526cea5beb4b2c875e6c511bb6f1e01bdf3da7219f6177328c7?chain=mainnet.
The transaction in question is from cycle 62 for DaoV1. I also have a similar issue with claiming my NYC coin.
Bump. This issue is still current, as can be seen with this new transaction I made today. Is anyone going to take this up? I would REALLY like to get my MIA and NYC back.
@whoabuddy In order to compare with the screenshots from the previous transaction:
And the cityName
variable appears to be properly populated:
Is there something I'm missing? Can this be fixed, or is this something that I would need to use the scripts for?
If it helps, this is the transaction that stacked that MIA: https://explorer.hiro.so/txid/0xdfd6e609d69193a954c253c2faea3497e5dbd42c6d2730497e2cb71cb611608e
Thanks for the additional information! Looking at what you provided cycle 62 should return both MIA and STX, but the STX value is not included in the post condition. If a contract tries to transfer any assets that aren't specified in the post conditions it will fail as a safety precaution.
This is likely due to some loading errors we're seeing with minecitycoins.com, a newer version is in the works but until then you can try https://jing.cash created by another community member.
To show the analysis in more detail and explain how one can get to that conclusion with on-chain data, see below.
The original stacking transaction outputs the following data:
{
amountStacked: u199870000000,
cityId: u1,
cityName: "mia",
cityTreasury: 'SP8A9HZ3PKST0S42VM9523Z9NV42SZ026V4K39WH.ccd002-treasury-mia-stacking,
event: "stacking",
firstCycle: u58,
lastCycle: u62,
lockPeriod: u5,
userId: u418
}
Here we see the cityId, firstCycle, lastCycle, and userId which are used to query the contract to get different information.
Now let's look at the failed tx for cycle 62:
- cityName and cycleId are correctly set
- includes a post-condition that the contract transfers exactly 199,870 MIA
Since there is no STX mentioned in the post-conditions let's take a look at what this address should receive from the contract by claiming cycle 62. There are two functions to do that which can be accessed from the Explorer sandbox.
get-stacker
with:
- cityId: 1
- userId: 418
- cycleId: 62
This returns the value (tuple (claimable u199870000000) (stacked u199870000000))
which means:
- 199,870 MIA stacked
- 199,870 MIA claimable this cycle
get-stacking-reward
with:
- cityId: 1
- cycle: 62
- userId: 418
This returns the value (some u1855650)
which equals 1.855650 STX.
So for the transaction to succeed it needs to have the post condition for both the MIA and the STX, or the function can be called in allow mode which bypasses the post conditions from jing.cash.