Terra Classic statsLUNC · USTC · ON-CHAIN DATA
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.
Terra Classic Infrastructure Proposal - Why Allnodes Deserves Your Support Have you ever heard of a silent hero? One that stands by you, rain or shine, asking for nothing in return? Meet Allnodes, the unsung champion of the Terra Classic blockchain. Here's Why They're Remarkable: 1. Reliability Like No Other: TFL wallets rely on RPCs provided by Allnodes. Guess what? In the last six months, there hasn't been a single downtime or issue. That's right, not one! Publicnode by Allnodes isn't just a solution; it's a reliable solution. 2. Generosity Beyond Measure: From the very beginning, Allnodes has been offering their top-notch services for free. They've never once asked for a penny, even when times were tough. 3. A Pillar of Support: When TCVITA approached Allnodes for infrastructure, they hoped for regular payments. But when TCVITA could only pay for a month, did Allnodes walk away? No. They stood firm, operating at a 100% loss, just to ensure Terra Classic had the support it needed. 4. Commitment That's Unwavering: Allnodes has been a beacon of stability for Terra Classic. Whether it was a critical update, a bug-fix, or nodes transitioning to v2.2.1, Allnodes was there, ensuring everything ran smoothly. 5. A Promise They Stand By: Regardless of how the community votes, Allnodes has vowed to continue providing everything they currently offer. Their dedication is unwavering, and they've proven time and again that they're here for the long haul. 6. Value Beyond Measure: Just to give you an idea of their commitment, hiring just one developer at Allnodes costs more than what's being proposed. They're willing to go above and beyond for the community, and that's something truly special. In this proposal, a pivotal point I wish to stress is the importance of consistency in our payment approach to endpoint providers. If we choose to pay one provider, then we should extend this courtesy to all. Conversely, if we decide not to pay one, then none should receive payment. Allnodes serves as a prime example of this principle. Despite not receiving payment, they have affirmed their commitment to not discontinuing any infrastructure essential to our blockchain. This commitment from Allnodes underscores the idea that even if we decide not to fund any of the endpoint providers in the future, our chain's integrity remains intact and will continue to receive unwavering support from Allnodes. In Conclusion: Allnodes' dedication to upholding our blockchain infrastructure without expecting payment highlights the core values they uphold. Our blockchain ecosystem is rooted in principles like balance, diversity, fairness, and equality. We believe in offering advantages to every contributor, ensuring no particular group gains undue favour. Now, we have a chance to show our gratitude. An optional monthly payment is on the table, not as a fee, but as a token of appreciation for everything Allnodes has done for us. Let's come together and give Allnodes the recognition and support they truly deserve. After all, heroes should be celebrated, shouldn't they? Allnodes Infrastructure Allnodes has been a backbone to the Terra Classic blockchain, providing a comprehensive infrastructure service suite that ensures our blockchain remains robust and responsive. The cost of this infrastructure far exceeds the proposed optional payment amount not even counting the team of dedicated developers. If compared to other providers, the optional payment is nominal, yet provides a high level of dedication, care & commitment. Here's a breakdown of what Allnodes provides: Endpoints: 1. Eight LCD: Light Client Daemon that facilitates interactions with our blockchain through a REST API. 2. Eight Mantlemint - Fast core optimized for serving massive user queries. 3. Eight RPC/gRPC: Remote Procedure Call, which provides a method for our nodes to communicate. 4. Eight FCD: A crucial bridge that fetches, interprets and indexes data from the blockchain, allowing smoother blockchain data queries for applications. Specification of Infrastructure: 1. Unlimited traffic - Currently serving 35 million requests every 24 hours 2. Load Balancing with High Availability: Ensures uninterrupted service even when single nodes face issues. 3. Geo-Balancing: By distributing the load based on geography, they ensure faster and more efficient responses for global users. Important Information: The Allnodes/publicnode infrastructure is currently utilized by the TFL products for Terra Classic and several dApps/entities on the chain. Optional Payment Amount Proposed - 150M LUNC Per Month YES – Yes, fund Allnodes with an optional monthly payment of 150M LUNC NO – Do not fund Allnodes with an optional payment ABSTAIN – The community can decide NO WITH VETO – Not Applicable Signed - Jay/HappyCattyCrypto https://commonwealth.im/terra-classic/discussion/13320-terra-classic-infrastructure-proposal-why-allnodes-deserves-your-support-hcc
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
27 Sept 2023, 21:49:16 UTC
Vote closed
04 Oct 2023, 21:49:16 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: 30752769 · 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: 30752769 · 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
30.57% decisive Yes
Veto
Not available
0.06% of participation
What this message can change—not a prediction of price.
150,000,000 LUNC
terra120ppepaj2lh5vreadx42wnjjznh55vvktwj679
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.