CCIP-022: CityCoins Treasury Redemption

[whoabuddy]

Starting draft of the code, main goals:

• CCIP-022 proposal
• CCD-012 redemption extension
• finish CCIP-016 analysis

It was brought up in Discord that CCIP-016 will not use the mining treasury so CCIP-022 is not blocked by it. Thanks hackjumeok!

[codecov]

Codecov Report

Attention: Patch coverage is 83.59788% with 31 lines in your changes missing coverage. Please review.

Project coverage is 88.29%. Comparing base (5ed2777) to head (a44d7c9).

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #71      +/-   ##
==========================================
- Coverage   88.89%   88.29%   -0.61%     
==========================================
  Files          22       24       +2     
  Lines        1468     1657     +189     
  Branches      231      275      +44     
==========================================
+ Hits         1305     1463     +158     
- Misses        148      174      +26     
- Partials       15       20       +5     

Files	Coverage Δ
contracts/extensions/ccd012-redemption-nyc.clar	86.86% <86.86%> (ø)
...cts/proposals/ccip022-treasury-redemption-nyc.clar	80.00% <80.00%> (ø)

---

Continue to review full report in Codecov by Sentry.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5ed2777...a44d7c9. Read the comment docs.

[akilress]

If I look at the to-do-list you posted a few days ago,

I thought CCIP-016 analysis for proposal and CCIP-022 publish text and first draft of code were key.

I was wondering if CCIP-016 is done with the "expose stacking claim bug".

[whoabuddy]

If I look at the to-do-list you posted a few days ago,

I thought CCIP-016 analysis for proposal and CCIP-022 publish text and first draft of code were key.

I was wondering if CCIP-016 is done with the "expose stacking claim bug".

No that just shows how the issue came about. We basically know that for each stacking cycle after CCD-007 started, there is a chance that someone claimed their CityCoins back without receiving their STX reward if:

• they had CityCoins to return in that cycle
• the cycle was not paid by the pool operator

We need to actually look at the transactions in this window and identify how many people were affected, and for how much total STX. That amount should be taken out of the total redemption amount and either claimable by or paid out to the affected addresses.

More documents will be added to CCIP-022 in the governance repo as we go through this process, that's where any supplementary information lives!

• CCIP-022: CityCoins Treasury Redemption (NYC) governance#34

[Lucasyano]

Thank you for your dedicated efforts in drafting the preliminary decision of <CCIP-022: CityCoins Treasury Redemption> voting proposal. I am reaching out with an inquiry. The current voting procedure is as follows:

This CCIP will be voted on using a vote contract that adheres to CCIP-015[^2] using the same two stacking cycles as CCIP-020[^1] and CCIP-021[^3].

• MIA cycles 80 and 81
• NYC cycles 80 and 81

In this context, do individuals who have already sold their CityCoins and converted them into other cryptocurrencies still possess the same voting rights? In other words, even if they have a history of stacking during cycles 80 and 81 but no longer hold CityCoins, do they still retain voting rights in the same manner as before?

[whoabuddy]

If we did cycles 80/81 then yes, it'd be the same voters / voting power that voted on CCIP-020 and CCIP-021.

Are you suggesting we shift it forward?

[Lucasyano]

If we did cycles 80/81 then yes, it'd be the same voters / voting power that voted on CCIP-020 and CCIP-021.

Are you suggesting we shift it forward?

I was curious if those who redeemed their CityCoins and disposed of them would still have the same voting rights. If we aim to proceed in the same manner as before, I have no objections. I hope things progress as quickly and smoothly as possible, without unnecessary complications.

[whoabuddy]

Yes, the contract code for voting does a historical lookup of the stacking cycle, so if we use 80/81 again the voting power would remain the same regardless of recent actions.

[whoabuddy]

The last commit updates the legacy tests to run with a modified config file (Clarinet.legacy.toml) that doesn't include the two newest contracts. The older version of Clarinet doesn't support epoch 2.5 or the new Clarity keywords like stacks-block-height.

For the proposal and redemption contract we'll have to figure out how to use the newer test structure with all of the contracts, working on that now. The main Clarinet configuration file (Clarinet.toml) is the same as the original plus the two new contracts.

Not sure if this will affect code coverage reports, might have to tweak something there after.

[akilress]

1/ In recent weeks, Nice bit of progress has been added to v2.minecitycoins.com

2/ and I know that many bugs have been resolved during preliminary simulations.

3/ Do you have any idea when the actual voting will take place and can we(DAO) expect an update from the previous schedule?
@whoabuddy

[whoabuddy]

Latest on implementation for CCIP-022, tests are done for the proposal but there were some challenges there that took longer than expected. Now we have a base set of tests against the proposal itself and the newer city-based voting data storage with just NYC votes.

Next up is the testing for the CCD-012 extension, which is the contract where the treasury is transferred to and redemption is handled from. Once that is done we're ready for deployment.

[whoabuddy]

Shout out to the extra eyes by drakesdenog on Discord and the legendary @LNow, the redemption ratio is now calculated correctly with some cost savings too.

The tests are now looking for the burn events as well, and should provide us enough information to make sure it's all working as expected.

There are claim tests for V1 only, V2 only, V1 + V2, and claim + acquire + claim patterns (multi-claim).

Putting some of the stats from console logging here as an artifact before removing the console lines from the code.

Shouldn't be much left from here but would be good to take a fresh pass to make sure all values are correct and tests are covering all expected cases.

V1 only

v1 only redemptionInfo {
  blockHeight: "12611",
  contractBalance: "15000000000000",
  redemptionRatio: "93632958",
  redemptionsEnabled: "true",
  totalSupply: "16020000000000"
}
v1 only redeem block {
  height: 12613,
  receipts: [
    { result: "(err u12006)", events: [] },
    {
      result: "(ok (some u9363295800))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u936329580000))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u4681647900000))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u9363295800000))",
      events: [ [Object], [Object], [Object], [Object] ]
    }
  ]
}
----------
user1Info {
  address: "ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5",
  nycBalances: {
    address: "ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5",
    balanceV1: "10000",
    balanceV2: "0",
    totalBalance: "10000000000"
  },
  redemptionAmount: "9363295800",
  redemptionClaims: "0"
}
user2Info {
  address: "ST2CY5V39NHDPWSXMW9QDT3HC3GD6Q6XX4CFRK9AG",
  nycBalances: {
    address: "ST2CY5V39NHDPWSXMW9QDT3HC3GD6Q6XX4CFRK9AG",
    balanceV1: "1000000",
    balanceV2: "0",
    totalBalance: "1000000000000"
  },
  redemptionAmount: "936329580000",
  redemptionClaims: "0"
}
user3Info {
  address: "ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC",
  nycBalances: {
    address: "ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC",
    balanceV1: "5000000",
    balanceV2: "0",
    totalBalance: "5000000000000"
  },
  redemptionAmount: "4681647900000",
  redemptionClaims: "0"
}
user4Info {
  address: "ST2NEB84ASENDXKYGJPQW86YXQCEFEX2ZQPG87ND",
  nycBalances: {
    address: "ST2NEB84ASENDXKYGJPQW86YXQCEFEX2ZQPG87ND",
    balanceV1: "10000000",
    balanceV2: "0",
    totalBalance: "10000000000000"
  },
  redemptionAmount: "9363295800000",
  redemptionClaims: "0"
}

V2 only

v2 only redemptionInfo {
  blockHeight: "12611",
  contractBalance: "15000000000000",
  redemptionRatio: "93691442",
  redemptionsEnabled: "true",
  totalSupply: "16010000000000"
}
v2 only redeem block {
  height: 12613,
  receipts: [
    { result: "(err u12006)", events: [] },
    {
      result: "(ok (some u9369143731))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u936914419531))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u4684572099531))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u9369144200000))",
      events: [ [Object], [Object], [Object], [Object] ]
    }
  ]
}
----------
user1Info {
  address: "ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5",
  nycBalances: {
    address: "ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5",
    balanceV1: "0",
    balanceV2: "9999999500",
    totalBalance: "9999999500"
  },
  redemptionAmount: "9369143731",
  redemptionClaims: "0"
}
user2Info {
  address: "ST2CY5V39NHDPWSXMW9QDT3HC3GD6Q6XX4CFRK9AG",
  nycBalances: {
    address: "ST2CY5V39NHDPWSXMW9QDT3HC3GD6Q6XX4CFRK9AG",
    balanceV1: "0",
    balanceV2: "999999999500",
    totalBalance: "999999999500"
  },
  redemptionAmount: "936914419531",
  redemptionClaims: "0"
}
user3Info {
  address: "ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC",
  nycBalances: {
    address: "ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC",
    balanceV1: "0",
    balanceV2: "4999999999500",
    totalBalance: "4999999999500"
  },
  redemptionAmount: "4684572099531",
  redemptionClaims: "0"
}
user4Info {
  address: "ST2NEB84ASENDXKYGJPQW86YXQCEFEX2ZQPG87ND",
  nycBalances: {
    address: "ST2NEB84ASENDXKYGJPQW86YXQCEFEX2ZQPG87ND",
    balanceV1: "0",
    balanceV2: "10000000000000",
    totalBalance: "10000000000000"
  },
  redemptionAmount: "9369144200000",
  redemptionClaims: "0"
}
---

V1 + V2

v1 + v2 redemptionInfo {
  blockHeight: "12611",
  contractBalance: "15000000000000",
  redemptionRatio: "46845721",
  redemptionsEnabled: "true",
  totalSupply: "32020000000000"
}
v1 + v2 redeem block {
  height: 12613,
  receipts: [
    { result: "(err u12006)", events: [] },
    {
      result: "(ok (some u9369143965))",
      events: [ [Object], [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u936914419765))",
      events: [ [Object], [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u4684572099765))",
      events: [ [Object], [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u9369144200000))",
      events: [ [Object], [Object], [Object], [Object], [Object] ]
    }
  ]
}
----------
user1Info {
  address: "ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5",
  nycBalances: {
    address: "ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5",
    balanceV1: "10000",
    balanceV2: "9999999500",
    totalBalance: "19999999500"
  },
  redemptionAmount: "9369143965",
  redemptionClaims: "0"
}
user2Info {
  address: "ST2CY5V39NHDPWSXMW9QDT3HC3GD6Q6XX4CFRK9AG",
  nycBalances: {
    address: "ST2CY5V39NHDPWSXMW9QDT3HC3GD6Q6XX4CFRK9AG",
    balanceV1: "1000000",
    balanceV2: "999999999500",
    totalBalance: "1999999999500"
  },
  redemptionAmount: "936914419765",
  redemptionClaims: "0"
}
user3Info {
  address: "ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC",
  nycBalances: {
    address: "ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC",
    balanceV1: "5000000",
    balanceV2: "4999999999500",
    totalBalance: "9999999999500"
  },
  redemptionAmount: "4684572099765",
  redemptionClaims: "0"
}
user4Info {
  address: "ST2NEB84ASENDXKYGJPQW86YXQCEFEX2ZQPG87ND",
  nycBalances: {
    address: "ST2NEB84ASENDXKYGJPQW86YXQCEFEX2ZQPG87ND",
    balanceV1: "10000000",
    balanceV2: "10000000000000",
    totalBalance: "20000000000000"
  },
  redemptionAmount: "9369144200000",
  redemptionClaims: "0"
}

multi-claim

multi redemptionInfo {
  blockHeight: "12611",
  contractBalance: "15000000000000",
  redemptionRatio: "46845721",
  redemptionsEnabled: "true",
  totalSupply: "32020000000000"
}
firstRedeemBlock {
  height: 12613,
  receipts: [
    { result: "(err u12006)", events: [] },
    {
      result: "(ok (some u9369139515))",
      events: [ [Object], [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u936914410630))",
      events: [ [Object], [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u4684572085946))",
      events: [ [Object], [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u9369144181261))",
      events: [ [Object], [Object], [Object], [Object], [Object] ]
    }
  ]
}
secondRedeemBlock {
  height: 33612,
  receipts: [
    { result: "(err u12006)", events: [] },
    {
      result: "(ok (some u4684))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u9369))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u14053))",
      events: [ [Object], [Object], [Object], [Object] ]
    },
    {
      result: "(ok (some u18738))",
      events: [ [Object], [Object], [Object], [Object] ]
    }
  ]
}
----------
user1Info {
  address: "ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5",
  nycBalances: {
    address: "ST1SJ3DTE5DN7X54YDH5D64R3BCB6A2AG2ZQ8YPD5",
    balanceV1: "0",
    balanceV2: "10000",
    totalBalance: "10000"
  },
  redemptionAmount: "4684",
  redemptionClaims: "9369139515"
}
user2Info {
  address: "ST2CY5V39NHDPWSXMW9QDT3HC3GD6Q6XX4CFRK9AG",
  nycBalances: {
    address: "ST2CY5V39NHDPWSXMW9QDT3HC3GD6Q6XX4CFRK9AG",
    balanceV1: "0",
    balanceV2: "20000",
    totalBalance: "20000"
  },
  redemptionAmount: "9369",
  redemptionClaims: "936914410630"
}
user3Info {
  address: "ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC",
  nycBalances: {
    address: "ST2JHG361ZXG51QTKY2NQCVBPPRRE2KZB1HR05NNC",
    balanceV1: "0",
    balanceV2: "30000",
    totalBalance: "30000"
  },
  redemptionAmount: "14053",
  redemptionClaims: "4684572085946"
}
user4Info {
  address: "ST2NEB84ASENDXKYGJPQW86YXQCEFEX2ZQPG87ND",
  nycBalances: {
    address: "ST2NEB84ASENDXKYGJPQW86YXQCEFEX2ZQPG87ND",
    balanceV1: "0",
    balanceV2: "40000",
    totalBalance: "40000"
  },
  redemptionAmount: "18738",
  redemptionClaims: "9369144181261"
}

[whoabuddy]

Tests are now complete and console logging still enabled for the final test to assist with peer review.

The tests simulate just over 5B NYC (both V1 and V2) against 15M STX in the contract for a more realistic simulation to the values on mainnet.

The final test covers a lot of ground, including:

• after init, redemption ratio stored in contract matches a calculated version in test
• after init, current contract balance = total balance - redeemed STX
• before first redemption, user ratios match contract ratio
• first redemption succeeds

Following that, any users with stacked tokens in the test unstack them and another round of redemptions are run to verify:

• after first redemption, current contract balance = total balance - redeemed STX
• before second redemption, user ratios match contract ratio
• second redemption succeeds

The information for the contract, each user, and the related ratios are output to the console after each step for manual verification as well.

[hanjumeok]

Tests are now complete and console logging still enabled for the final test to assist with peer review.

The tests simulate just over 5B NYC (both V1 and V2) against 15M STX in the contract for a more realistic simulation to the values on mainnet.

The final test covers a lot of ground, including:

• after init, redemption ratio stored in contract matches a calculated version in test
• after init, current contract balance = total balance - redeemed STX
• before first redemption, user ratios match contract ratio
• first redemption succeeds

Following that, any users with stacked tokens in the test unstack them and another round of redemptions are run to verify:

• after first redemption, current contract balance = total balance - redeemed STX
• before second redemption, user ratios match contract ratio
• second redemption succeeds

The information for the contract, each user, and the related ratios are output to the console after each step for manual verification as well.

Thank you for your dedication.

What tasks remain? If we proceed with the vote and the result is in favor, will it be implemented immediately?

Could you please provide an approximate timeline?

[akilress]

hi, whoabuddy
@whoabuddy
I see you've been working on a lot of things, how are things coming along? :)

1/ It's hard to allocate time, but I'm pretty sure that the NYC liquidation is technically done with the code review, and the CCIP will be done once the code review is organized.

2/ At this point in the process, I think it's more natural to release a timeline for voting, since we're also nearing the end of the 86 cycles we originally proposed.

[whoabuddy]

@akilress we're in the peer review stage and so far everything looks good with two main things brought up by reviewers:

1. We should determine the minimum amount of NYC for the redemption and how much STX would be received based on the current redemption ratio. The tests currently cover ~10,000 NYC at the smallest case, and this could just be a simple spreadsheet that's added to the CCIP in the governance repo as a supplemental document.
2. There is an edge case where unclaimed mining rewards can slightly modify the redemption ratio after it's set. Any mining claims will mint new NYC and we can mitigate this in three ways:
   • the v2 website has the functionality to download and filter all mining and mining claim transactions, from which a user can see their unclaimed values without having to search individual block heights. Once the vote begins this should be the priority to get it up and running so people can use that data to claim as much as possible before the redemption ratio is set. (the same logic can be used for reclaiming any stacked NYC as well)
   • the scripts repository has a new transaction download script that uses the same logic as the v2 website, and we can use this to collect all transactions for each of the mining contracts, then identify how many claims are outstanding to try and anticipate the possible changes and adjust the ratio. This would need to be done before the vote, proposal, and redemption extension are deployed. If the impact is minimal then we may be able to forego the adjustment based on the item below:
   • the get-redemption-for-balance function should be modified based on the info above so that if the redemption amount is greater than the balance in the contract, the remaining balance of the contract will be transferred, effectively ending the redemption and making sure the final redemption call will succeed. This would not occur until the very end of the redemption process with the last claim. This would need to be done before the vote, proposal, and redemption extension are deployed.

Given the two mitigations above need to be completed before the contracts are deployed they now take top priority, however both can be targeted, tested, and setup today, with the goal of getting the contracts deployed and vote started as soon as today as well.

A huge THANK YOU to the community for their patience as we round out this process, writing code that lives on-chain forever has some unique challenges and we can anticipate the vote to start very soon!

Also, there is a lot of talk about "missed cycles" but this is irrelevant as the current code didn't support stacking past cycle 83 in it's current form due to the hard fork and new pox-4 contract on Stacks. The vote cannot happen before the extensions are ready as well because the contract code is what we're voting on; once the vote is complete the contract code is executed pending a successful vote result.

[KILRdad]

Decision to end protocol started March 2024. At this time question was raised on Discord what would happen to unclaimed STX since 100% STX treasuries have been stacked with only approx 45% MIA and 62% NYC stacked and include this in CCIP22

Did not happen, now proposing to either add additional CCIP or replacement CCIP if 22 fails that would split redemptions into 2 phases/epochs. 1st phase redemption would last 6 months (25,000 blocks).

In the 2nd/final epoch the redemption ratio for any NYC to be burned would need to be recalculated based off the current supply of unclaimed STX

The newly calculated ratio will apply to all NYC to be redeemed in the 2nd phase going forward, will also allow all NYC redeemed in phase 1 to claim 1x more in phase 2 with the new ratio.

Potential workflow of additional round liquidation:

Phase 1
15,519,437 NYC STX
5.332 Billion NYC
Redemption Ratio .00291

NYC Holder 10 million redeems 29,106 STX

1st round redemption only 62% STX redeemed leaving 5,897,386 STX in treasury

Phase 2
5,897,386 STX
5.332 Billion NYC (allows all burns from phase 1 to claim again)
Redemption Ratio .0011

NYC Holder 10 million who redeemed in phase 1 can do 1 final redemption with the previously burned 10 million NYC: 11,060 stx

This will encourage all users to redeem early and reduce potential for unclaimed STX.

Proposed changes to CCIP22 language in bold

Redemption Extensions
This CCIP will implement a new redemption extension for NYC.

The redemption extensions will:
receive and hold funds from the respective city treasury contract
allow for 2 phases of redemption
record the total supply of NYC at the time of initialization
calculate the ratio of NYC to STX based on the total supply and contract balance for phase 1
allow users to burn NYC in exchange for their portion of STX and track the related totals from phase 1 to use in phase 2
calculate new redemption ratio in phase 2 (25K blocks after phase 1 initiated)

Redemption Mechanism
The NYC mining treasury currently holds 15.5M STX, and upon successful execution the entire balance will be transferred to the redemption extension.

Following the transfer and upon initialization, the redemption extension will:
get the total supply for NYC V1 and V2
add the total supplies accounting for decimal differences
get the balance of the redemption contract itself
set variables representing all data gathered above and that redemption is enabled
create a redemption ratio from balance / total supply

The redemption extension then exposes a public function that:
calculates amount to transfer based on balance * redemption ratio
verify that redemption is enabled
verify user hasn't claimed already
verify there is something to burn
verify there is something to redeem
burn the NYC balance for the user
transfer the STX to the user
store redemption info for the user
print the redemption info as 2 events
stored redemption info from phase 1 will be used for 1 more redemption at the new ratio in phase 2
redemption ratio will be recalculated in phase 2: remaining treasury stx / total NYC supply

[whoabuddy]

Thanks @KILRdad for outlining the info above, the other side of the argument in Discord was to keep things fair and simple with redemption setup so that anyone with an NYC balance can claim at any time, allowing those with funds still on Okcoin or in accounts that may be recovered at a later date.

The trade-off is that some STX may remain locked in the redemption contract, but it's difficult to correlate stacking participation with redemption participation as there are still many holders with funds locked on Okcoin. Their Earn program ended in March of 2023 and the Okcoin deposit address currently holds ~746M NYC or 14% of the total supply.

Further analysis shows that of the NYC holders (looking at just V2) shows that almost 2B NYC is still locked in the stacking contract, which can be reclaimed by holders now that the mining and stacking functionality were disabled with CCIP-020.

So the question is: should NYC holders be allowed to claim at any time, or should there be a time limit so that active holders can claim more? The current version of CCIP-022 that will begin voting soon would allow the claims to occur at any time, setting the redemption ratio once and using it to redeem for users until the redemption contract is fully depleted of STX.

Additional work is being done on the v2 minecitycoins interface to download and analyze all transactions for a connected wallet then allow for any missing claims, and a redemption tab will be added that shows the redemption amount of STX based on the wallet balance of NYC.

IMO setting a time limit for redemption puts unnecessary pressure on the process, and the focus should be on helping people identify and claim what's theirs as holders of NYC. Ultimately this will be decided by the vote on CCIP-022 once live.

[KILRdad]

Previous comment updated with full text from:
#74

As of now 5.332 Billion NYC
Highest amt stacked ever was 3.317 Billion
746 Million on OKcoin

5.332 - 3.317 - .746(14%) = 1.269 (24%) NYC V2 or V1 that did not stack/vote

Nothing ever can be predicted with 100% certainty however can review historical data and look for patterns to formulate decisions with the most productive outcomes

OKcoin stopped stacking (earn program) and trading March 2023. Community voted to stack 100% treasuries and from community calls hope was for coins to stack yet large % coins did not participate/move

When 100% treasuries were stacked on average 3 billion NYC stacked (did not increase drastically over time). Approx .746 billion (14%) on OKcoin and 1.269 billion (24% unstacked V2 and V1) did not stack and therefore did not vote

CCIP-20 passed yet NYC still being sold off meaning those holders had no interest in redemption

From this data there is a higher probability that 38% of the treasury may go unclaimed indefinitely: 5,897,386 stx

Dormant STX capital doing nothing would be better used powering other STX projects

A 2 phase redemption (needing 2 redemption ratios) still allows indefinite redemption at the same time placing urgency to redeem. If majority of holders redeem in the 1st phase of 25K blocks then treasury will be depleted as planned

If in 6 months approx 38% treasury remains then unlikely to be redeemed ever considering major changes regarding stacking started end 2022 (almost 2 yrs prior) with little movement in coins

Community mentioned lack of online awareness and therefore support/participation for the project, little was done/improved in this regard

Many projects are quickly forgotten over time. Viewing data/trends from how NYC coins moved/stacked/voted can deduce the same has already happened

Goal is to prevent treasury STX from being unused

Idea to change mining/stacking 2022 was to curb miner behavior as all miners did not behave with what was determined to be in the best interest of the protocol. Along this logic also cannot equate intentions of all holders and expect that all can/want/will participate any longer for redemption

2 phases allow a higher drawdown of the treasury while still allowing indefinite redemption if those remaining STX are ever to be redeemed