Describe the bug
When we import the full columbus-5 genesis it will cause terrad to panic on start-up due to an error when reading "raw blocks" in goleveldb. Which would indicate that the initial import, which is done via Tendermint, is successful however the subsequent read from Cosmos-SDK fails with a "block overflow" error.

To Reproduce
Build the 2.0.3 release and bootstrap it with a Columbus-5 genesis export

Context & versions

• Debug genesis import (Tobias, Vinh)

Problem definition
Investigate PebbleDB for speed improvements (PCI 4.0/NVME) to the backend, discontinue support for goleveldb/rocksdb.
Investigate BadgerDb for dealing with "large KVstore blobs"

Feature specification
Provide benchmarking data for "terrad" using different KVStore configurations in order to gauge the different performance profiles when dealing with various types of data (lots of small values, lots of big blobs, mixed)

Additional context

• Study LSM-based KVStore architectures (RocksDb/PebbleDb)
• Study LSM-based w. seperate value log KVStore architectures (BadgerDb)
• Speak with Aaron about the state of the Read/WriteSource implementations for the orm
• Test case for user story: "Sequence of pre-orderered keys with 8B values"
• Test case for user story: "Sequence of unordered keys with 8B values"
• Test case for user story: "Sequence of pre-orderered keys with 8KB values"
• Test case for user story: "Sequence of unordered keys with 8KB values"
• Test case for user story: "Sequence of pre-orderered keys with 64KB values"
• Test case for user story: "Sequence of unordered keys with 64KB values"
• Test case for user story: "Sequence of pre-orderered keys with 4GB values"
• Test case for user story: "Sequence of unordered keys with 4GB values"
• Fix "unit test breakage" when running "go test --bench ."
• Implement test scripts for benchmarking
• Benchmark "KVStore" using RocksDB to establish baseline
• Benchmark "KVStore" using PebbleDB for comparison
• Benchmark "KVStore" using BadgerDB for comparison
• Benchmark "KVStore" with columbus-5 genesis using PebbleDB for comparison
• Benchmark "KVStore" with columbus-5 genesis using BadgerDB for comparison

Links

• LSM-tree research @ https://www.usenix.org/system/files/conference/fast16/fast16-papers-lu.pdf
• LSM-trees explained @ https://medium.com/swlh/log-structured-merge-trees-9c8e2bea89e8
• BadgerDB vs RocksDB @ https://dgraph.io/blog/post/badger-over-rocksdb-in-dgraph/
• GoLang profliing @ https://hackernoon.com/go-the-complete-guide-to-profiling-your-code-h51r3waz
• Test case @ https://github.com/classic-terra/documents/blob/main/test%20cases/performance-profiling-persistence-of-lsm-architectures.md

Problem definition
Currently, IBC feature is not available on x/wasm. This will prohibit smart contract from going cross - chain.

Feature specification
Enable IBC feature on x/wasm will allow dapp to go cross - chain. I am willing to host sessions, write documents to show how to write cross - chain smart contract.

Going cross - chain is the current trend of the whole Cosmos ecosystem:

• cross - chain swap
• cross - chain NFT marketplace
• cross - chain name service

We should embrace this trend

@ZaradarBH @inon-man @fragwuerdig

Additional context

• [ ]

Problem definition
After @faddat leaving the L1 there might be a threat of notional taking down relayers to Osmosis. Might be viable to set up an own relayer.

• Assess funding for this (we kinda need VPS with 32GB RAM, 20TB SSD disk space, might be very expensive)
• Optionally use public archive nodes
• Create/install/configure Osmosis full archive node
• Assess whether it's possible to use Classic full archive node from TCV
• Create/install hermes relayer
• Configuration of hermes relayer

Problem definition
Test import of columbus-5 genesis file and sync from genesis.

Feature specification
Columbus-5 genesis.json file loads correctly and syncs.

Additional context

• Test import of file and confirm if there is an issue.
• Sync a full node from genesis
• Test using the latest v1.0.5-archive release

• Review payment process for development team and implement standard best practices for payment remittance
• Create standardized reporting available for the Luna Classic community to be able to review following each payment remittance.
• Develop standard practices to allow for ease of end of month, end of quarter, and year end reports.

Problem definition
We are currently not able to use upgrade handlers for "chain upgrades" due to issues with the version map. Fixing this will allow us to workaround the "genesis import issue" and adopt the upgrade strategy which seems to be preferred by the Cosmos developer community.

Feature specification
TODO - Spec

Additional context
TODO - Tasks

Tasks

• Determine block height required for this update. (Ed) Should be end of March, prior to release of v2.0.4
• Write first proposal with fixed configuration, submit to Agora for voting (Ed)
• Confirm if antehandler fix will be in v1.0.5, based on result of governance vote. (Steve)
• Communicate required update to validators (Ed)
• Create proposal repository in github, with workflow (Ed)

Acceptance Criteria

• Proposal has been passed or rejected.

Problem definition
Investigate updating to canonical version of Tendermint v0.37. Ensure the priority and compatibility with Oracle transactions (tx) compared to other keeper tx’s once we adopt Tendermint v0.37.

Feature specification

• Discuss whether or not we want to maintain current oracle tx implementation
• Discuss whether or not we want to switch to CometBFT
• Implement version of Cosmos SDK that fits whichever strategy is adopted
• Implement version of Tendermint / CometBFT that fits chosen strategy
• Consider refactoring terrad to ensure int64 is always used as its priority. Only int32 is used for weighting
• Implement release, test, and move to canonical

Additional context
.

Acceptance criteria

• Go/No-go on canonical version

What: We will establish an external "product owner" group that can help keep us focused on the right "epics" and provide feedback on issues during planning sessions
Why: It will help us ensure that we stay on target and focus on things that are valuable to our investors

• Select COC members (@StrathCole @PFC-developer @DJTrev)
• Brief COC members
• Invite COC members to team sprint planning

• Report on status of development and progress against schedule
• Use scorecard metrics to display whether project is on-schedule and within budget
• Provide update on status of last bi-weekly sprint, and include details of work to be completed in next sprint
• Highlight any issues, risks or opportunities discovered

• Actions in this workflow must be: within a repository owned by classic-terra, created by GitHub, or verified in the GitHub Marketplace.
• Move push and pull image from DockerHub to our GHCR

Problem definition
Currently the amount of spam proposals in Deposit phase is unbearable. In order to prevent spam in the Deposit phase it would be nice to have a min. initial Deposit that the proposer has to submit alongside the proposal. This feature is available in v0.47 of SDK. As we won't move to 47 in the near future it's probably legit to backport that feature.

• Assess the viability of this task
• Backport the feature
• Upgrade handlers

Describe the bug
Using --dry-run with a terrad tx does not work. It returns an error of "key not found"
Error: key with addressFB26CA0B8B9B0CD04CD8C51949F2EBD6A1161521not found: key not found

Without dry-run, the tx works as expected.

To Reproduce
add --dry-run to any tx send

Context & versions
any version of terrad

(if applicable) suggested solution
If you know the solution to the bug, let us know!

I'm currently downloading a snapshot that contains terra's latest state.

I would like it if other team member can explicitly check to ensure that this is a non-breaking change:

git clone https://github.com/classic-terra/classsic
cd classic
git checkout v1.0.x
go install ./...
terrad init test
cd ~/.terrad
aria2c -x5 https://dl2.quicksync.io/columbus-5-pruned.20230102.0410.tar.lz4
lz4 -d columbus-5-pruned.20230102.0410.tar.lz4 | tar xf -
terrad start

The chain should convert the database, then start. There should be no apphash error.

When that's done, I'm good to go with work towards upgrading to sdk v0.45.x

You should expect for the transition to take genuinely a long time.

• Implement support for IAVL 0.19.4 in Cosmos-SDK release/v0.45x

Problem definition

We need to establish a fully fledged e2e test flow that will allow us to do all the existing testing, as well as regression, UI and fuzz testing.

I. Why we need to setup an automated testing framework?

In many cases, we have observed that unit test isn't enough to guarantee that the whole system will not break. We simply got lucky when Ed found a problem through his manual system testing that may not always happen.

In some cases, not even the unit test is correct due to writer misunderstanding of required logic.

II. Framework

1. Standarize writing unit test (we can even go further with a ci to check). A PR should include:

• feature specification (in written markdown file in a folder called feature-request) (Gherkin language)
• unit test write

2. a full - fledged e2e test flow through ci that does following flow

• upgrade testing:
  • for chain (if exists, else use current terrad): do an upgrade gov test to newer chain binary
  • for wasm (if there are changes to wasm, else use current wasm files): change to newer wasm files
• regression testing (change to system should not break existing one)
  • backend:
    • chain should run normal
    • ibc should work normal
    • wasm should run normal
    • state sync should run normal
  • frontend: api testing of most important transaction types and query
• fuzz testing:
  • some nice background reading: https://github.com/osmosis-labs/osmosis/blob/main/simulation/ADR.md
  • we need to care only about events that invoke a state change, we then create randomized request to these events:
    • transaction: create randomized request and broadcast multiple times
    • begin block: randomized environment condition that invokes a begin block logic (Ex: system time, number of validators, ...)
    • end block: randomized environment condition that invokes an end block logic (Ex: system time, number of validators, ...)
    • init genesis: create randomized genesis state

It is hard to invoke a begin, end block logic without first understanding what environment condition it relies on.

Feature specification

• Outline general framework as goal for testing refactor
• Specification and activity diagram of multiple pipelines
• Review the existing workflows and determine what we can re-use.
• Refactor existing workflows to fit into new "pipeline architecture".
• Implement new actions / workflows for missing test types (Unit testing, Integration testing, System Test, Fuzz Testing, UI Testing)

Additional context

Acceptance criteria

This issue needs to be broken down into multiple issues. This one is more like tracking issue.

Goals of this one should be the creation and definition of smaller testing issues (which I don't know fully yet)

Problem definition
Since there are no centralized package for testing utilities on Terra, I often have to rewrite some helper functions like fund account, setup a testing app. In the long run, these centralized testing utilities packages will help save tremendous amount of time and effort.

Feature specification
Osmosis has mature testing packages, we should follow their practices:

1. https://github.com/osmosis-labs/osmosis/tree/main/app/apptesting
2. https://github.com/osmosis-labs/osmosis/blob/main/app/test_helpers.go
3. https://github.com/osmosis-labs/osmosis/tree/main/simulation
4. https://github.com/osmosis-labs/osmosis/tree/main/tests

Problem definition
Continuation of #67

Feature specification

• Script for deploying old chain smart contracts
• Change to new wasmvm and re-run tests
• Deploy new version of smart contract and confirm functionality after updating runtime

Acceptance Criteria

• Workflow is working correctly

Problem definition
A Governance proposal is required outlining the findings and recommended approach for the Cosmwasm upgrade.

Additional context

• Create an agora post outlining findings and recommended approach.
• Create a governance proposal which references the findings from the research conducted and recommends a proposed approach moving forward.

Problem definition
Adopt Jacobs suggestion of utilizing mev-tendermint on Terra Classic. Implement Agore proposal to kick start the debat in our community.

Feature specification
Complete mev-tendermint governance proposal

Additional context

• Publish mev-tendermint governance proposal

TODO

Describe the bug

This issue has to be further investigated. A guy named LbunPyro deployed the following contract on TerraClassic:

https://github.com/ZuluSpl0it/contracts/blob/main/contracts/cw20-bonding/src/contract.rs

The instantiated contract is here:

https://finder.terra.money/classic/address/terra1r8t57xzx4ekwc6ts7nc8cg0gsg7jrpf9pwmnug

The issue is that contract execution for the ExecuteMessage {"buy":{}} fails every time although there is enough fee coins in the ExecuteMsg and the gas limit is appropriate.

See for example failed tx hash:

https://finder.classic-terra.com/classic/tx/853E6564C776C7946FC4D5BF160B3BE79F080E0D403A785BAAA889AE78F33B8C

To Reproduce

Given above contract address try to execute message {"buy": {}}

Context & versions

This issue does not apply for any other messages that are accepted by the contract. Also: It does not seem to apply to Bombay test network, which basically does not implement the tax. The buy message from the contract is the only message that stacks other send messages on top of the response stack.

My first guess is that there is an issue with the tax handling. This has to be further investigated.

@faddat : Do you have someone who I can talk to and who is an expert on contracts? Just so that I can exclude any issues with the contract itself ...

Problem Description
There are many outdated and broken links within classic-docs.terra.money that need to be updated.

Feature specification

• Update existing links on classic-docs.terra.money

Additional context
.

Acceptance criteria

• Links have been updated

Problem definition
The current IBC version is outdated. We need to update the IBC-GO module to version 1.3.1

Feature specification

• Undertake research on Juno
• Implement the needed changes
• Testing on local net

Additional context
.

Acceptance Criteria

• Successfully upgrade to 1.3.1 and confirm correct functionality

Describe the bug
Confirm that we are able to sync from columbus5-genesis.json.

To Reproduce
Start terrad using original columbus-5 genesis file.

Context & versions
Original genesis file that starts from the first block of columbus-5.

(if applicable) suggested solution

Problem definition
Ed has talked with Binance and they are looking for us to look at options for whitelisting their wallets.

• Port over the whistlist code from classic-core
• Deploy it to a whitelist-concept branch
• Run unit tests to ensure code works
• Add Binance Whitelists

Problem definition
Assess the state of our current “version map” and determine how it can be patched to reflect the current state of our system.

Feature specification

Acceptance Criteria

• Upgrade is applied and is running correctly.

Additional context

• Confirm upgrade map has been fixed. Meet with @inon-man and confirm upgrade work completed will resolve issue. (Vinh)

Problem definition
Update methodology for managing branches, including main branch.

Additional context

• Develop strategy for managing branches
• Implement new strategy

Acceptance Criteria

• Branches have been cleaned up
• Team is successfully using new branching strategy

Problem definition
Right now Terra-Money and Terra-Rebels are the only canonical repositories approved by the Terra Classic governing consensus body, which make it hard for validators to accept PRs from the L1 team and for us to work towards increase "client diversity". So we need to create and submit an Agora proposal that hopefully pass and allow us to adopt a strategy based on @faddat suggestion around simply basing it of commit IDs from any repository.

Feature specification

• Repeal existing canonical repos in favor of a commit ID based solution with no organizational constraints

Additional context

• Write proposal
• Submit proposal for vote

Problem definition
Adjust ante handler to send 50% of “burn tax” to community pool & 50% to treasury burn wallet.

Feature specification
TODO - Spec

Additional context
TODO - Tasks

Problem definition
We need to ensure that the Oracle SHA256 patch we implemented to secure the oracle-feeder is pushed to the validators

Feature specification

• Patch oracle-feeder with feather.js changes from TFL
• Write up proposal to seek permission to update Oracle feeder with v1.0.0 release.
• Write upgrade documentation
• Prepare pre-release
• Test on mainnet
• Reach out to validators and notify them of required timing

Additional context
.

Acceptance criteria

• Validators confirm upgrade

Problem definition
Impact analysis of upgrade to Cosmwasm v1.1.1 to assess effect on migrating L2 wasm contracts from 0.16.6.

Acceptance criteria
Complete governance process and determine if community is ready for the upgrade

Additional context

• Set up feedback form with questionnaires in MS forms
• LuncBurnArmy to contact existing utilities and smart contract holders.
• Reach out to various DAO's (metagloria)
• Conduct analysis, develop document outlining pros/cons of implementing upgrade and impacts
• Review analysis and decide on whether or not to proceed.

Problem definition
Upgrading database to use tm-db.

Problem definition
Setup a finder for testnet

Feature specification
Finder is live on testnet

Additional context

• Deploy finder for testnet
• Ensure finders works as intended

Problem definition
Governance proposal required for release 1.0.5.

Additional context

• Create and post governance proposal related to release 1.0.5.

Problem definition
Test/Upgrade IBC denom whitelist.

Feature specification
Acceptence criteria

Additional context

• Create proposal for whitelisting IBC denoms
• Create release containing "IBC whitelisting" code
• Write test cases for ensuring the "IBC whitelisting" is not exploitable
• Perform regression testing on testnet
• Submit release to the validators

Describe the bug
When a user tries to transfer LUNC crosschain using one of the only functioning bridges (PortalBridge), the PortalBridge smart contracts unnecessarily require the user to reserve 1.2% of the required funds. This is counter-intuitive (since there's no reason for the user to reserve 1.2% now that the tax has been repealed) and has confiscated hundreds of millions of LUNC from users. Whether the transaction succeeds or fails, a 1.2% tax (+ gas) is assessed on the balance attempting to be transferred.

To Reproduce

1. use PortalBridge to bridge LUNC from the native chain to, eg, Eth mainnet (https://www.portalbridge.com/#/transfer)
2. try to transfer >98.8% of your full balance to Eth mainnet
3. follow the steps to transfer
4. lose 1.2%+gas of whatever you tried to transfer, be a failed txn enjoyooor

Context & versions
Not sure

(if applicable) suggested solution
Get PortalBridge to update their smart contracts

Problem definition
We found out that the LCD "estimate-fee" logic is calculated directly in the client which means we had to add in a "block height guard" to ensure that it added the "burn tax" correctly. The fix was done in October, but could do with some more testing.

Feature specification

• Add the "burn tax" to the "estimate-fee" query.

Additional context

• Fix "estimate-fee" bug in custom/auth/client/utils/feeutils.go
• Test software patch on full node mainnet
• Test bug fix on testnet

Problem definition
Determine viable strategies for enabling an "FIAT on-ramp extension" in the L2 GUI applications.

Feature specification

• Determine viable integration options
• Propose viable integration options (how we do it, who does it, when will it be done?)
• Develop wireframe outlining possible look + feel for embedded on-ramp
• Ensure implementation of selected integration option

Additional context

• Communicate with Jared and determine if this issue is being developed by TFL
• Abandon issue if developed by TFL

Acceptance criteria

• FIAT On-Ramp available in Station test environment as proof of concept

Describe the bug
There are historic problems with syncing from genesis. There are problems with the crisis checks, indexing bugs, and app hash errors. Creating a new branch and release candidate to fix. This release can be used for archive nodes.

To Reproduce
Try to sync from genesis

Context & versions
Every release has this problem. This aims to fix them.

(if applicable) suggested solution
Utilize the archive release if trying to sync from genesis

Problem definition
Currently, we have many spam/scam gov proposals. We should have a mechanism to prevent those.

Feature specification
Add initial deposit requirement for proposals, when the user wants to submit a proposal, they need to deposit a part of the government-required deposit.

Acceptance Criteria

• Proposal passed governance
• Solution implemented

Additional context

• Determine minimum deposit to charge users for submitting a deposit proposal.
• Create proposal for governance - set fee to prevent spam. (Ed)

Problem definition
It would be nice to be able to use cosmovisor to perform chain upgrades if we are going to be using upgrade handlers anyways, as this would enable a higher degree of automation around the release management process

Acceptance criteria
Decide on whether or not this should be implemented

Additional context

• Implement layer 1 dojo for using cosmovisor
• Speak with validators to confirm if they want to use cosmovisor (questionary)
• Explore why cosmovisor breaks the binary?
• Conduct research to determine how this integrates with software research proposals.

Problem definition
The Terra Classic documentation on https://classic-docs.terra.money/ is out of date and needs to be updated.

Feature specification

• Identify required changes
• Review required changes with L1 team
• Create fork of classic-docs

Additional context
.

Acceptance Criteria

• Documentation has been updated and published

Problem definition
A governance proposal for Classic v1.0.6 is required for the proposed whitelist changes to be accepted and pushed into production.

Feature specification
Proposal writeup and listing of Binance wallet addresses to be whitelisted.

Additional context

• Write agora post for Classic v1.0.6
• publish proposal for Classic v1.0.6

• Create a schedule outlining high-level target milestones and deliverables
• Identify and illustrate any dependencies
• Include roadmap in Medium article bi-weekly status update

Problem definition
We want to establish the most light-weight process possible for the L1 Task Force to enable us to coordinate our efforts.

Feature specification
Setup backlog project for GH org (not associated with any specific repo) and create issues based on proposal

Additional context

• Book onboarding meetings
• Prepare onboarding meeting agendas
• Setup backlog project for L1 Task Force
• Create GH team and assign members roles & responsibilities

● Update key stakeholders on anticipated development timelines and provide advanced notice for any action required on their part (i.e. Central exchanges, validators, etc.)
● Ensure budgetary and fiscal transparency is provided to Luna Classic community members
● Provide timely development status updates
● Encourage community engagement and obtain feedback
● Strengthen community and investor confidence in L1 Task Force and Luna Classic project

Problem definition
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]

Feature specification
A clear and concise description of what you want to happen.

Additional context
Add any other context or screenshots about the feature request here.