The community will be thankful that this is funded. I think we can drum up enough support from validators.
I need this tool, down to support a long time community member with a very reasonable spend
PFC will support this.
but I think you need haven’t got operating costs in here. (not just FCD) but day to day management.
WDYT of adding a ‘operating’ stream or some kind of ‘perpetual/endownment fund’ that generates yield that you can use to run it.
- I Fully Support This.
- Let’s also community involved in raising capital as well.
- Keen to ape my own $LUNA/$UST into making this happen too.
This existing saves me a truckload in accounting and opens the door to many future #LUNAtics.
It’s a no-brainer.
When can expect an official response from the Rapid Grants Committee for TrackTerra’s proposal?
This proposal was submitted to you 15 days ago. You are far overdue in your responsibilities to the Terra community.
guess we are in the same boat fellow Lunatic…
worked closely with Papi, he wants what is best for the ecosystem. This is a tool the community needs. This is why we have a community fund. for sure a yes Vote from me.
Thanks again for all the help on that side project Papi, I know it became a nightmare. But ya stayed up many hours, on a holiday, without ever asking for compensation. Solidified my trust in you.
This is a reasonable point. Today server costs are relatively cheap . Our upkeep is pretty cheap just now, server costs come in at around 45$ a month. This could maybe scale up to 200$ a month worst case. The other upkeep cost is time maintaining rules for the parser, although i expect this will be relatively minimal.
Our ultimate goal is for popular tax softwares to adopt our codebase for internal native integrations , but even once that happens we will still have users who use our CSV export functionality, but overtime as native integrations occur i expect actual use of our tool will decrease.
With that said rather than a perpetual endowment , i would propose a small amount of funding that we can tap in to for maintenance costs of the app. Conservatively i think 10k would cover this .
As this will be an on chain proposal we also have the issue of price spread from the time we post our proposal to the time it passes. Thus i would propose we convert our UST costs to Luna at the time of the proposal and then buffer the total amount by 10% . Any excess funds will go to our maintenance fund.
Is this agreeable?
Maintenance and Upkeep - 10,000$
These funds will be held in the multisig and deployed to cover the costs for any upkeep or maintenance. If we do not get to our stretch goal of implementing NFT marketplace support we will tap in to upkeep fund to cover those development costs. This maintenance fund will also cover hosting the app (excluding FCD)
Proposal updated to include 10k for maintenance and 3880$ (10%) to cover any negative price volatility during the voting period.
Agree, we need a fully functional system.
Loans / borrows should not show up as a taxable income.
Swaps between luna/bluna/nluna etc should be considered for “like kind exchanges”.
Loans/borrows are covered.
There is no concept of like-kinda exchange in crypto. You could try to argue these are “pool deposits” and not new assets but thats a hard argument to make if you do things with the new asset like deploy it in to lp and such. Check out
That irs doc is about truly different cryptos or gold vs silver.
There is like kind exchange in other contexts.
Luna vs bluna are essentially identical in every meaningful way.
Usdc vs usdt vs usd vs ust is like kind exchange as well. They leave it up to the filer to decide as far as we know
They’re not. How would you then account for bluna-luna lp or swap transactions where there is a loss. The popular crypto tax apps dont support this at all. Like-kind rules dont apply to crypto. ( Crypto Taxes in 2021: Tax Guide w/ Real Scenarios | Koinly) .
There could be an argument that these are pool deposits but then you lose cost basis for the assets when you lp or swap them. It makes more sense to treat them as swaps.
This is a must have. It’s actually a win-win investment for the ecosystem as well. Otherwise there will be a natural incentive to buy and hold vs. doing multiple complex transactions that cause a reporting burden. Quite the contrary If we have consolidated EOY reporting.
Also Papi, in addition to the initiatives you mentioned I hope accruing Anchor loan interest will be reported since this will at least offset the distributions of anchor tokens.
One other key component is providing the price when non-stable coin staking rewards are received (LUNA, ANC, PSI, etc). This establishes some basis in these rewards since we are being taxed on them.
Anchor aUST investments will be treated as swaps ie UST to aUST and vice versa as this will cover the cost basis and profit tracking of aUST investments. Beta actually supports this today.
Proposal is live. We assumed a luna price of 41$ for the proposal.
Voting against, community funds should be kept for more important matters.
stake.systems’s vote is NO on this proposal, in line with our commitment to vote against proposals that are tapping into the community pie.
Why vote NO on community proposals?
- there are a lot of very good projects out there, but also there are a lot of scams or unjustified requests for spending. More is not always better. We do not like more. We like less. Because less is more cost-effective and easier to manage than more. Also, we do not believe in advertising, so naturally, we won’t vote for any marketing bullshit.
Why vote no on TrackTerra?
- Not all countries mandate the type of reporting TrackTerra is doing. So this is a particular use case that is more suitable for certain countries. This has to be solved by the local community because there are many types of local needs, which can be pretty legit and very important for some people, but not for everyone. Terra community funds cannot possibly solve any country’s legislation problem.
I see the community funding as a reserve for doing work that targets the protocol, performance, and security of the network. Any type of tooling, on most of the other projects, is just a byproduct of a very good community and the project itself. We should not pay for tooling. Tooling should and will remain open source.
TrackTerra is applicable for most countries that require reporting of crypto currency transactions. TrackTerra provides processed data and APIs so that Terra blockchain data is consumable by popular tax softwares (which have further considerations for specific regions).
I’ve worked on TrackTerra for many months prior to this proposal. Im building TrackTerra because it’s something i personally need and it’s clearly a need for a majority of community members. Im a big believer in creating value and being frugal with community spend funds which i why im contributing to this project as an unpaid advisor and also why we have no monetization scheme and are releasing all of our code open source.
As an aside i dont think your delegators are aware of your approach towards community governance, while being frugal and skeptical of use of community funds is good practice , a blanket no vote on all community spend proposals seems like a unfavorable practice and an unproductive use delegated funds.
I think @stake.systems is right although i would formulate it differently. It makes no sense to fund this project: if people need it, let people pay for it, it’s as simple as that.
If you do not have the funds to start and you have a market, find investors. Let me tell you that any reasonable investor would not use their own money, given that you have:
- no business case
- no long term view (what happens when the funds for the maintenance costs are missing?)
- no explanation of what we are building (what on earth are your popular tax reporting softwares???)
- no control (me and my friend will need to agree to unlock the funds ).
This is a big problem we currently have with DAOs. People vote like sheep just because they can and because they are not spending their own funds. If you want money, create value first.