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.
Title: Proposal to Reintroduce the 1.2% Burn Tax for $LUNC and Implement Transaction Fees for $LUNC and $USTC Introduction: We propose the reintroduction of the 1.2% burn tax for the $LUNC token and the implementation of transaction fees for both $LUNC and $USTC tokens. These measures aim to reduce the supply of each token asset, which can create value through increased scarcity and demand as transaction volume grows. Rationale: 1. **Reducing Supply**: The burn tax and transaction fees will reduce the circulating supply of $LUNC and $USTC over time. As tokens are continually removed from circulation, their scarcity increases, potentially driving up their value. 2. **Price Stability**: By reducing supply, we can promote price stability. This is particularly important for $USTC, a stablecoin, as it ensures that its value remains close to its peg, benefiting users and traders. 3. **Encouraging Long-Term Holding**: Transaction fees and burn taxes encourage users to hold their tokens for longer periods. As they pay fees and see the benefit of a decreasing supply, they are more likely to hold rather than constantly trade, which can lead to a more stable market. 4. **Value Creation with Volume**: The introduction of these measures can significantly benefit from increasing transaction volume. As more transactions occur, the cumulative effect of the burn tax and fees becomes more pronounced, accelerating the reduction of token supply. 5. **Network Sustainability**: The burn tax can contribute to the long-term sustainability of the network by creating a deflationary mechanism that reduces inflationary pressure. Implementation: 1. **Reintroduction of the 1.2% Burn Tax for $LUNC**: Implement a 1.2% burn tax on every $LUNC transaction. The tokens collected through this tax will be burned, permanently removing them from circulation. 2. **Transaction Fees for $LUNC and $USTC**: Implement a dynamic transaction fee structure for both $LUNC and $USTC. The fee can start low and increase based on transaction size or frequency to discourage excessive trading. 3. **Gradual Rollout**: Roll out these measures gradually to allow the community to adapt and provide feedback. Community Involvement: Engage with the community to gather feedback and build consensus for these changes. It's essential to address concerns and ensure the changes align with the project's goals and community expectations. Monitoring and Evaluation: Regularly monitor the impact of these measures on supply, token value, and user behavior. Adjust the burn tax rate and transaction fees as needed to maintain a balance between reducing supply and encouraging transactions. Conclusion: By reintroducing the 1.2% burn tax for $LUNC and implementing transaction fees for both $LUNC and $USTC, we aim to create value through increased scarcity and demand as transaction volume grows. These measures have the potential to benefit the project's sustainability and the token holders over the long term.
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
21 Oct 2023, 03:45:05 UTC
Vote closed
01 Nov 2023, 15:48:43 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: 30753076 · 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.
Manual success criteria required
This proposal does not map cleanly to a chain-wide metric. Delivery evidence must come from its stated milestones.
/cosmos.gov.v1.MsgExecLegacyContent/cosmos.gov.v1beta1.TextProposalReported response header height: 30753076 · 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
13.40% decisive Yes
Veto
Not available
3.55% of participation
What this message can change—not a prediction of price.