Reading the proposal and its separately reported chain context.
Loading the proposal. Its status, vote amounts and original source times will appear when the readings are ready.
Back to governanceWaiting for evidence.
Waiting for evidence.
Waiting for evidence.
Waiting for evidence.
This pending view does not establish a proposal result, current voting power or a successful source read.
I am re-creating Prop #11859 because it did not pass last time due to reasons that remain unexplained/unjustifiable to me. This proposal is important and required at this point of time to help both Terra Classic AND Terra mitigate the legal liabilities which lies before both of the entities, and if not mitigated, could lead to unforeseen consequences for every investor and holder of Luna Classic AND Luna. UST can also be repegged by turning on the Market Maker module, but the moment we do that, we are exposing ourselves to another probable de-peg event, because we currently do not have backup reserves to ensure that customers remain protected in case of such an event again. This proposal is to do just that – create reserves, because we will be continuously earning while the trading bot automatically trades for customers, and adds to the volume. This trading bot has the ability to make customers a lot of money in the long run, burn both LUNC and USTC, multiply the current volume AND also create enough reserves to repeg UST again. I do not personally believe any other proposal has been put forward in governance in the last two years to the same effect. I will not be rewriting the original proposal and will keep it as it was written in Proposal #11859 because I do not believe any more changes are required to the idea, and I have already progressed and improved the algorithm behind the trading bot to an extent that, with some further improvements, I will be able to create a live app for everyone to use in less than a month after the proposal passes governance. The Original Proposal for making HODLR is as follows: Validators asked me to wait for 6 months before reapplying for this again (now this has become 1 year), so I waited, and yet no other dev has been able to produce anything of value for UST that is capable of bringing in more than $5 Billion to Luna Classic and repeg USTC. We currently require $8 Billion to repeg it. The TL;DR is - HODLR is an Arbitrage Trading Bot & Algorithm which automatically trades and makes profits over a period of time. I have already tested it and the test results are on my X account @klothtweets. In the last 3 months, I have talked extensively about HODLR, and I have 6-7 videos on it on my YouTube channel as well. This algorithm makes a minimum profit of ~70-80% and maximum profit of ~450-700% in 30 days according to initial test results. If this proposal is funded, I will be able to get an AWS server, test it and deploy it live. This will allow normal users to invest LUNC and USTC, make profits while holding it like a fixed deposit withdrawable any time, and also burn both LUNC and USTC in the process, automatically repegging USTC, apart from being able to save enough for reserves required to repeg USTC. The spend amount required ($10,000) is for the AWS server which will cost me around $3,000 for 6 months and my remuneration, which is approximately $7,000 for 6 months. So, currently I require just $10,000 to continue my work. I can't continue this work for free because I need to dedicate all my time to it as it is an intensive task to develop an algorithm that ONLY I will be able to, among ALL developers of the entire Terra Luna Classic community. I have written at length about the trading bot and algorithm on my X account which you can find by searching for HODLR on my profile @klothtweets. There is no team that I have for this proposal, and I am working alone on this currently. The Terra Luna Classic community is aware that I am a publicly doxxed person. The wallet address terra1lg85ytn3l78cxkuvh66tvscj2zxnvq55gnvgra mentioned to receive the funding is my own, and my complete name is Arunaday Basu. Please make the correct decision this time, deposit & vote on this because every vote counts. Thanks for your vote - Arunaday Basu.
Connect Keplr to read your vote and review a new vote or update while the chain keeps voting open.
REJECTED · Voting deadline
Your wallet holds the keys and approves each transaction. A submitted vote can have no voting power; participation weight and final eligibility are determined by the chain.
Submitted
25 Jan 2024, 06:48:18 UTC
Vote closed
05 Feb 2024, 15:44:55 UTC
Not approved
The proposal did not produce an approved governance action.
Proposal status, current block and node version are separate responses with their own original clocks.
A reported PASSED status for routed protocol messages is consistent with successful governance handlers in supported SDK versions. The production fork and its version at execution are not independently established here. A text mandate still needs delivery evidence; a requested treasury payment is not a reconciled recipient payout.
Current block response metadata
Reported response header height: 30752355 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Node info response metadata
Current or final voting power, calculated from the on-chain tally.
Historical bonded stake and vote-close parameters are not available here. Turnout and threshold checks are withheld; the recorded proposal status remains authoritative.
Amounts use the separate tally endpoint response.
Selected tally
Current staking pool
Changes between retained samples near vote close and the 7, 30, and 90 day targets. Sample times and a 36 hour tolerance show how closely each pair matches its target.
Retained outcome assembly available
These retained comparisons have a separate assembly clock. It does not refresh the original proposal, block, node or parameter source clocks.
These times describe optional assembly, separate from retained sample capture times and original upstream response completion. Optional outcome work has a 1.2-second wait budget. Core reads and server load can make the total response take longer. The same admitted work continues after that wait; later requests can reuse its completed result. The original core cache and source clocks remain unchanged. No automatic page polling is added.
Community pool
Preferred signal: context
/cosmos.gov.v1.MsgExecLegacyContent/cosmos.distribution.v1beta1.CommunityPoolSpendProposalReported response header height: 30752355 · reported
Public requested / response origin: Withheld or unavailable / Withheld or unavailable
Cached responses keep their original completion clocks. The block header time is a reported chain time, separate from HTTP completion and page assembly. Missing, invalid, future, wrong-chain or legacy source evidence is withheld. The block and node-info reads have no common-height guarantee; reported response metadata does not authenticate chain state.
A current block reaching an upgrade target does not prove software activation or validator adoption. A separately reported current node version does not establish the historical execution version or which proposal caused it. These responses do not independently verify execution receipts, recipient payouts or off-chain delivery.
Current tallying parameters
Current reported SDK context
The model uses SDK0.53.6/math1.5.3 fixed18-place quotient and half-even rounding on reported integer aggregates. Quorum allows equality; approval and veto require strictly greater shares. Expedited approval uses its separately returned expedited threshold. Missing supported SDK/rule/threshold evidence withholds decisions. Internal fractional voting power and production custom tally logic are not reconstructed or independently established.
Cached inputs keep their original completion clocks. These independently read responses have no common-height guarantee; reported headers do not authenticate chain state. Missing, invalid, future or legacy evidence is withheld. Reported zero votes stay zero; unavailable amounts are not zero votes.
Current stake and thresholds are shown only as current context. They are not used to reconstruct a closed proposal’s turnout or threshold result. This does not establish historical voter eligibility, voting weights or vote-close rules. Amounts are approximate displayed LUNC from reported micro amounts; these reads do not verify execution, payouts or delivery.
Quorum
Not available
Participation unavailable
Approval
Not available
1.32% decisive Yes
Veto
Not available
27.80% of participation
What this message can change—not a prediction of price.
106,826,194 LUNC
terra1lg85ytn3l78cxkuvh66tvscj2zxnvq55gnvgra
7 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.
30 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.
90 day target
This comparison applies to passed proposals.
Sample times are retained capture timestamps, not original upstream read times or verified chain heights. The nearest supported sample within 36 hours of each target is used; equally close samples prefer the earlier capture. Identical duplicates are merged and conflicting values at the same clock are withheld.
This is a change between two retained numeric samples, not complete coverage of the intervening period. Timing and metric changes do not prove the proposal caused an effect, executed a protocol action, paid a recipient or delivered a promised result.