RIP: Accounting Improvements

[ECWireless]

Project Idea

Our goal is to make our accounting data easily exportable and readable to a CPA, and easily accessible to other Raiders (while automating the process along the way).

If done successfully, we expect this to allow a greater understanding of treasury behavior, and greater confidence in making financial decisions in 2023.

This RIP is part of the December 1st Brigade.

Project Submitted By

• @mr_bluesky
• @ECWireless
• @Tufnel_Enterprises

Summary

Our long-term goal can be split into four objectives: gather, analyze, interpret, plan, and systematize. Although, given the shortness of the 1st December Brigade sprint, we are trimming our objectives this month to be simply: gather, analyze (partial analyzation), and systematize; with potential future sprints being dedicated to the other objectives. A breakdown of the objectives is below:

1. Gather - Create a spreadsheet that gives a clear sense of what and when tokens have come in and out of the treasury

2. Analyze - Categorize the "ins" and "outs" into groups (e.g. RIPs, Raids, one-off member compensation, operational expenses, legal, hosting etc...) and charts (e.g. month-to-month breakdown of fund outflow and inflow)

3. Interpret - Form interpretations of the categorized info (e.g. who are our 20% clients? How has our inflow changed month-to-month the last year? What sectors of the web3 space is our top clientele?)

4. Plan - Decide on how to manage funds moving forward (e.g. How much can we spend on RIPs the next two quarters? Should we aim for an amount of inflow per quarter? How much do we set aside for other fun activities? Do we need to find a professional for advice? Should we commit to trying to generate non-clientele revenue? Should we review/revamp tokenomic discussions)

   • It may be hard to quantify the ROI of RIPs. But even an intangible measure of return would help to shed some light on what would be an appropriate % to allocate toward RIPs, which also help inform voting when proposals go up. Not that past results always have to dictate future actions, but it's at least a starting point

5. Systematize - Create a low-friction process in which these stats and records can be easily kept while raids are ongoing rather than doing damage control after the fact

   • Create an environment where data is permanently refreshed and available (DungeonMaster API)
   • This should be a regular, recursive exercise. Not only to track progress, but also because as things evolve, opportunities to drill into particularly profitable niches may present themselves.

Why should we build this?

While something like DAOHaus Books and Dune Analytics is great, they don't export the data in a way that a CPA could comprehend

• Unix timestamps need to be dates
• wXDAI needs to be denominated correctly
• Assets need to be converted to USD

We need to have a record of our assets' value at the time it entered our treasury, and at the current time, in order to capture capital gains and losses.

Additionally, there is plenty of our own data that we've collected through DungeonMaster that we can utilize using our own APIs, which would provide a lot of insight to us internally:

• We can map applicant addresses to Discord handles
• We can map inflows to Smart Escrow Raids (and further map that with DungeonMaster)
• We can easily map more specific information about where outflows are going (e.g. RIP funding, hosting repayments, etc...)

Ultimately, any Raider should be able to get this formatted data very easily, and not have to go through a lengthy process anytime they want to understand our financial behavior. Other options either don't format correctly, charge too much, or aren't extendable enough to combine with our own unique data (RIPs, raids, smart escrows, DAO members, etc...)

Deliverables

• Inflow/outflow asset price data cache in DungeonMaster API
• Comprehensive accounting spreadsheet for Gnosis DAO, which is particularly formatted for a CPA
• Comprehensive accounting spreadsheet for mainnet DAO
• Build a simple bot that automatically exports and formats treasury data
• Add a simple "Treasury"/"Accounting" page to DungeonMaster
• Write-up of things we learned + "where we go from here"

Timeline

• Started: December 19th
• Deadline: January 12th

Raid Party Skills Needed

• Backend
• Frontend
• Python Bot Developer

Cost (in USD)

$4,500

[ECWireless]

Retrospective + Next Steps

Introduction

In the summary section of our original RIP, we identified our step 1 as the "gather" phase, which has turned out--given the magnitude of the task--to be the entirety of this RIP. The goal of gathering was to "create a spreadsheet that gives a clear sense of what and when tokens have come in and out of the treasury." In the pursuit of this, we built two concrete pieces of deliverables: a treasury bot, and a treasury page in DungeonMaster.

While both of these were delivered successfully, it's remarkably clear that there are still numerous gaps in RaidGuild's accounting data, which are non-trivial to try to recover. That being said, it has turned out that the vast majority of the important data is easily discoverable, and easily linkable with other DungeonMaster data.

In the future, both of these learnings should be pursued more: we need to fill the small gaps in our data (though 100% completion of this is potentially impossible), and we need to continue integrate our data with DungeonMaster in a way that's very easy for members to access, and--farther down the road--very easy to analyze.

Cool things learned

The two best things to have come out of this RIP are 1) that RaidGuild's accounting data is now in a place (literally and figuratively) that can be easily analyzed for patterns, and 2) coming to the realization that combining accounting data with DungeonMaster can provide very rich insight.

So how should RaidGuild analyze its data? The most obvious answer is to render the data into different types of financial charts, in order to identify general trends. Ideally, this visualization tool would be built into the accounting page in DungeonMaster, and should be highly flexible regarding data it is able to show.

To bring even greater insight, though, RG should categorize the "ins" and "outs" into groups, such as RIPs, Raids, one-off member compensations, operational expenses, legal, hosting, etc... The best way to do this is likely through the use of DungeonMaster's current data, plus additional data we add to DM.

Being able to break our expenses down into groups is important enough for basic bookkeeping, but it also would strengthen our ability to interpret and plan in the future. How has our RIP spending trended relative to our income? What was our most expensive RIP, and once we know what it is, can we gauge how much value it brought? What Raids have brought in the most income, and what sector of the web3 ecosystem are the projects within? Have our Raid project sectors trended towards anything specific? All of these can really only be answered once we've broken down where exactly our income came from, and where it went.

Bad things learned

The primary issue we came across in this RIP was inaccessible data. While the vast majority of the important data is readily available, to make it completely compliant, we likely have to fill in the gaps.

Easily the biggest gap is in understanding where income came from before the use of Smart Escrow. Before Smart Escrow, the standard way to split funds was through a Gnosis Safe, which means if we want to connect spoils with specific Raids, we have to somehow track down all previous Gnosis Safes, and somehow label which Raids they were used for. Not only is this hard enough, but most Safes were used for multiple Raids, and many of the Raiders on them are no longer active.

There is no particular path forward for this issue other than continuing to try and solve it. There's a decent chance the only way to do is clunkily and manually.

Finally, RaidGuild has plenty of activity within its Minion safes, which admittedly were not accounted for at all in this RIP. This luckily is likely an easy thing to iterate on in the future, but understanding the behavior and purposes of the Minions is an additional challenge.

Current state

The current state of accounting is that every RaidGuild member now has 2 avenues for easily getting treasury data: 1) they can either ask the DMInsight bot something like, "What is RaidGuild's accounting data for 2022?" and the bot will reply back with a CSV. And 2) a member can simply go to dm.raidguild.org, and visit the accounting page to see the same data.

Next steps

Given our two concrete goals, plus "bad things learned," there are three next steps and two paths forward. The two paths forward are to iterate more on the Accounting page, and build out the DMInsight bot to be truly useful and insightful.

In pursuit of the accounting page path, there are two next steps. The first is to complete the tasks that were out of scope for this RIP:

• Calculate capital gains
  • Capital Gains are difficult to calculate, given we aren't sure how to deal with ragequits
  • We also aren't sure at this point if RG would be subject to capital gains taxes, since we aren't certain on RaidGuild's legal standing
• Add a table that represents RG's revenue, expenses, assets, liabilities, equity
• Figure out how to split these 3 types of inflow:
  • Tribute
  • Yeet
  • Spoils (done)
• Figure out how to split these 3 types of outflow:
  • Subscription Expenses
  • RIPs
  • RageQuits
• We need to record Gnosis Safe addresses in DM if we want to keep records of specific Raid accounting
• We need specific block timestamp data for token prices
  • Currently, previous token price data is set as the average (or maybe closing) price of a given day, since that is all CoinGecko offers
  • We should try to find price data for every block in history, if possible
• We need to organize and render Minion data
• We should separate out USD value into its own column(s), so that you can do the above easily and also filter by USD value

After a decent number of these tasks are tackled, the next step should be to create flexible visualizers for as much of the data as possible.

As for the bot path, there is a long list of features it could potentially offer. For now, though, we should build it out to be a secondary interface with DungeonMaster, and perhaps all other RaidGuild data.

While the first two next steps have no solid plans in moving forward--with no one yet owning them--@ECWireless plans to continue work on the DMInsight bot, and will link to a new related RIP shortly.

Conclusion

Where we are now is in a place with a lot of data; accounting data, raid data, member data, etc... This data is now more accessible then ever, but still difficult to interpret. RaidGuild should take this opportunity in the bear market to organize, categorize, and analyze this data in order to better understand itself, and more strategically direct its future.

[plor]

This is a great retrospective and #126 follows up on this. I would suggest we close this. Is there anything that should be documented in md form in "PROPOSALS/"?

[plor]

Also, link to txs for payout would help here. Not a big deal though.

[ECWireless]

Here's a link to the processed proposal: https://app.daohaus.club/dao/0x64/0xfe1084bc16427e5eb7f13fc19bcd4e641f7d571f/proposals/408

[plor]

I'm going to close this. Thanks.