Expense tracking & reimbursements

[raucao]

This is a big one, and I think one GitHub issue is probably not the perfect venue for discussing it, but maybe we can hack a quick MVP for it first, then iterate on it and open seperate issues.

The first step here would be the pure tracking, not the actual remuneration. So, for example, @5apps is currently sponsoring servers for various open-source projects, including Kosmos. Ideally, one could create an expense of type "recurring/monthly" and just enter all monthly expenses one contributes combined, with the details in the description. Later on, we can then use that data, but still decide what and from which point in time to remunerate. I.e. we don't have to decide how to actually treat those expenses yet, but at least we can start tracking the pure data.

[bumi]

I think it is easiest to do the recurring/monthly expensives off-chain first and create each month an expense on-chain. I think this makes it easier to do the actual payout and have a paid/unpaid status.

I'd suggest storing the following data:

• recipient (address)
• amount
• token - ETH, wrapped bitcoin, whatever the vault supports)
• IPFS hash - description with details of the expense with e.g. invoices
• paid (bool)
• approved (bool) - approved by voting for example
• createdByContributorId

[bumi]

The expense tracking app would call the vault (#172 #145) to do the payment. (the recipient can withdraw through the expense app)

[raucao]

Somehow, we did not document in here what we discussed in the calls since then. The idea was to do it completely manual at first, and document what we do, so we can translate it into an on-chain solution.

We can actually start doing this now, because we have enough money for infrastructure sitting in a new Kosmos multi-sig safe since yesterday (using current Kredits accounts for signing).

@bumi @haythem96 @velasquez @fsmanuel Anyone of you interested in joining a brainstorming/planning call about this?

[bumi]

yeah, let's do a planning call. - for me ideally anytime next week.

:+1: for a manual process first to see exactly what needs to be implemented on-chain.

though I'd start with recording expenses on-chain soon. that should be rather simple as it just stores some data and references to an IPFS document. Did we already discuss what schema we want to use? anybody knows if there are some standard schemas?

[raucao]

It's only Tuesday. I was actually hoping to manually log some expenses this week, and thus have some requirements ready for implementing on-chain. I assume we need a veto window, as with everything else, so the payouts are going to be delayed.

I don't think the schema is as important as e.g. the question in which currency to pay out (and how to auto-convert tokens), because if you log an expense, and then the price of a non-stablecoin token falls 20% over the course of a week (which can and does obviously happen sometimes), then whoever paid for the expense is not being remunerated enough. (And vice versa, if it rises 20% then the payout is unfairly high.)

The other big question I see is about who can propose an expense under which conditions (for veto etc.). For example, a core contributor's expense proposal could require more vetos to reject than a proposal by a newcomer. Or, it could be a first example of weighted veto power, in where you need n% of overall contributions to execute a veto. Or, we could start with no vetos at all, but only core can log expenses (for pure documentation purposes), but that's obviously not enough for production usage.

[raucao]

@bumi I opened a PR for the expense schema for the IPFS documents.

I think on chain (i.e. in the contract storage) we only need:

• ID (numeric, same as for contributors and contributions)
• Token (A currency code, or a contract address? How do people do this?)
• Amount (uint16 should be enough I guess)
• Recipient account (address)
• IPFS hash (split up, same as the other contracts)

My initial thought is that it doesn't matter who the recipient is. But I'm not sure how this would be verified when it doesn't map to a contributor. I also don't know if we need the address of the person proposing the expense in storage, or if "sender" is accessible in some other way.

Edit: forgot to add confirmedAtBlock and vetoed. I think for the very first iteration we should just copy the exact behaviour from Contribution. For more complex behaviour, we'll likely want to change both to use/import the same code later anyway, right?

[raucao]

Added #195 for the contract setup. I think it makes sense for it to be separate, so that we can have smaller PRs for the actual features (instead of a single long-running monster PR).

[bumi]

I started looking again in some related aragon apps as those made quite some progress it seems: https://github.com/AutarkLabs/open-enterprise/blob/dev/docs/GETTING_STARTED.md#install-the-allocations-app

maybe we can get some inspiration there. Sadly it does not fit fully to our intended process it seems.

maybe we can discuss the currency topic at the call today briefly? I am a bit indifferent there. I'd like to be as far away from fiat as possible... but all invoices we have will be in USD/EUR. But I also rather hold BTC than some USD/EUR coin.

[raucao]

Nice one! Looking at their roles I just realized that it would indeed be nice to not pay out immediately, but only allocate the funds, and then you could do only one tx to withdraw for several expenses at once if you wish (using the same concept/code as for new kredits withdrawals).

Not necessary for the first iteration, where it's only about logging and maybe vetoing, of course.