MakerGAAP Accounting Ledger

This post is also available on the MakerDAO forums for comment and discussion.

Executive Summary

Some of our chefs are contributors to the Strategic Finance Core Unit at MakerDAO. As part of this work, we have built a transaction-level dual-entry accounting ledger on the back of our experience diving into MakerDAO's protocol-level financial data.

Each of these reports is auditable down to the transaction level and can be cross-checked independently for consistency and correctness.

We are aiming to make a significant contribution to advancing the state of on-chain accounting, by providing tools that will take the ecosystem a step closer to a gold standard for DAOs:

• Real-time
• Independently verifiable and auditable
• Open-sourced categorization choices

Background

On-chain protocols iterate and improve over intermediated financial services through full transparency into accounting movements. However, on-chain protocols have no conventional or established framework for accounting choices, leaving significant room for interpretation.

MakerDAO has had, since March 2021 at least, published regular monthly reports that aim to interpret on-chain activity in an easily-digestible convention for token holders who are used to balance-sheet driven financial statements. These reports are all produced with on-chain data, with aggregation at the query level in order to facilitate processing time.

We take a principles-based approach to our choice of accounting standards. This means these reports will not reconcile to US GAAP or IFRS, nor should they aim to. We are focused on finding adequate representations of the underlying economic reality of an on-chain protocol, with adaptations to the choices we make for representing smart contracts.

In our view, the direction of motion for on-chain accounting will be along principles vs rules, providing guidelines to identify the ‘function’ of a smart contract call and show the recommended ‘mappings’ for recognition in an accounting perspective, rather than try to write or fit rules that won't necessarily suit every possible smart contract.

This probably means that future comparability may be limited by the specific choices different financial statement views of on-chain protocols make, but will be broadly recognizable.

Methodology

We have extended this work by creating a data set over 2m rows long containing every single transaction in MCD since launch. Each transaction is then categorized into two matching accounts according to the following chart.

	
  	.
├── Assets/
│   ├── Collateralized Lending/
│   │   ├── Crypto-Loans/
│   │   │   ├── BTC/
│   │   │   │   └── BTC
│   │   │   ├── ETH/
│   │   │   │   └── ETH
│   │   │   ├── Liquidity Pool/
│   │   │   │   ├── Stable LP
│   │   │   │   └── Volatile LP
│   │   │   ├── Other/
│   │   │   │   └── Other
│   │   │   └── stETH/
│   │   │       └── stETH
│   │   ├── Legacy/
│   │   │   └── Stablecoins/
│   │   │       └── Stablecoins
│   │   └── Money Market/
│   │       └── Money Market/
│   │           └── D3M
│   ├── Liquidity Pool/
│   │   └── PSM/
│   │       └── PSM/
│   │           ├── Non-Yielding Stablecoin
│   │           └── Yielding Stablecoin
│   ├── Real-World Lending/
│   │   └── RWA/
│   │       ├── Private Credit RWA/
│   │       │   ├── Off-Chain Private Credit/
│   │       │   │   └── (Most our RWA vaults atm)
│   │       │   └── On-Chain Private Credit
│   │       └── Public Credit RWA/
│   │           ├── On-Chain Public Credit
│   │           └── Off-Chain Public Credit /
│   │               └── (MIP65)
│   └── Proprietary Treasury/
│       └── (ENS, stkAAVE, COMP and whatever Messari sends us)
├── Equity/
│   ├── Protocol Surplus (MakerDAO Surplus Buffer)/
│   │   └── Gross Interest Revenues
│   │   └── Liquidation Revenues
│   │   └── Trading Revenues
│   │   └── MKR Mints Burns
│   │   └── Sin
│   │   └── Direct Expenses
│   │   └── Indirect Expenses
│   └── Proprietary Treasury/
│   │   └── (ENS, stkAAVE, COMP and whatever Messari sends us)
│   └── Reserved MKR Surplus/
│       └── MKR Token Expenses
│       │   └── Direct MKR Token Expenses
│       │   └── Vested MKR Token Expenses
│       └── MKR Contra Equity
└── Liabilities/
    ├── Circulating Dai/
    │   ├── Interest Bearing/
    │   │   └── Dai/
    │   │       └── (DSR)
    │   └── Non-Interest Bearing/
    │       └── Dai/
    │           └── (Regular Dai)
    └── Locked Dai/
        └── (one day meb)

For on-chain accounting, transactions are the relevant source of truth and pro-forma statements such as this one are a choice of convention.

An individual row in this data set would therefore look as follows:<

This data set is created in Dune Analytics, using an open source query that extends our previous queries and lists individual transactions before classifying them. This dataset now lives in a dune table called maker_ethereum.accounting. The logic used to create this dataset is open source and found here.

We integrated this data set into a Snowflake instance. All aggregation is done after the fact in a PowerBI report. The benefit of this is that the dashboard allows one to dig into specific transactions (at the hash level) that make up any figure on the MakerDAO balance sheet.

Planned future improvements:

• Add teleport revenue
• Consider alternative approaches for RWA revenue
• Automate the backend data pipeline to enable potentially updating more frequently
• Alter the dune table slightly to add a unique key so that data refreshes can be incremental and thus more frequent

MKR Token rewards

On token rewards specifically: On the balance sheet, we balance them with contra equity so that they do not affect the protocol surplus, and on the statement of changes, we put MKR expenses into their own section so that they may be considered or not at the discretion of the user.

MKR expenses are accounted for in 3 accounts (Vested MKR Expenses, Direct MKR Expenses, and MKR Contra Equity), and the pathway depends on whether a vesting contract was used or not. With this setup, MKR Contra Equity is a stub account that effectively tracks (by counterbalancing) all issued tokens that have left the pause proxy, and Vested MKR Expenses is an account that can track MKR currently in Vest contracts.

Also very noteworthy, when a DSS Vest stream is opened or yanked and tokens move between the Direct MKR Expenses and Vested MKR expenses accounts, we do not assign a monetary value to these transactions. We only assign a monetary value once they leave the Pause Proxy, via a vest contract or not.

Display token

We have enabled functionality of 2 display tokens, DAI and ETH. To do this, we assign a DAI value and an ETH value to every transaction.

This allows us to output the report in DAI and in ETH, for both balance sheet views and statement of changes views. A button can be found at the bottom of the report to toggle between these presentation tokens.

If we simply converted each base token value to the presentation token value at the time of the transaction, the cumulative result in the end would be a balance sheet that is worth an amount different from what our balance sheet is worth. For example, if we got an airdrop of $ENS worth $2m at the time but $500k today, simply converting to DAI value at the time of the transaction would lead us to believe we have $2M of ENS today. We would need a $-1.5m cumulative line item to balance this. This is precisely what we've done.

For every base token, every primary label (assets, liabilities, equity), and every day, we have added a line item that represents the value of this type of currency translation, specifically how this value has changed from the prior day. To do this, we had to work backwards:

1. For every given day, we calculated how much the cumulative amount (one cumulative amount per primary label - assets, liabilities, equity) of base token would be worth at the end of the day.
2. We subtracted the cumulative of instantaneously converted values from this value to produce a cumulative daily version of the desired line item.
3. We took the delta from the previous day to "uncumulative" this figure, so that it can be aggregated at any length of time that is desired (at minimum daily though).

The output of these conversions can be directly seen in views of the report, labeled as "Currency Translation to Presentation Token". The result in the balance sheet view, which is cumulative, is fairly intuitive. It is worthwhile to mention some nuance in the statement of changes view: while every other line item in that view represents activity in the time period being viewed, this line item represents the currency translations within the period of base token activity within the time period and of the base balance accumulated prior. For instance, if we have earned some AAVE prior to March that is worth 1000 DAI at the beginning of March and 1200 DAI at the end, this 200 DAI would be represented in this line item along with any currency translations of AAVE accumulated within March.

Another important callout is that we do not do these cumulative currency translation corrections for MKR expenses - these are treated independently (also counter-balanced to 0) and solely converted to the display token value instantaneously, as it does not make much sense to show how the value of spent MKR would have changed if we hadn't spent the same MKR amount until today.

Aggregated reports

The main reports are denominated in DAI or ETH only and include the Governance-controlled assets (stAAVE, ENS and COMP) on the DS Pause Proxy. MKR in the DS Pause Proxy is always excluded, as in our view it represents authorized but unissued tokens for the protocol. Counting them would be falling into the same trap that any system which counts endogenous collateral as part of its assets falls into. MKR expenses are accounted for but either counter-balanced (in the balance sheet view) or placed into an independent category (in the statement of changes view), so that the end user can include or exclude at their discretion.

We take a simplified cash-based view for on-chain protocol accounting. In this instance, there is only a balance sheet at given periods that count stock (Balance Sheet) and a reconciliation bridge between two periods that counts flow (Statement of Changes in Protocol Surplus). Therefore there is no 'third' statement of Token-Flows, as they are all effectively token flows. At any point, to see all of the transaction-level data that makes up a cell, right click the sell and “drill through” to the Full Table. To toggle between DAI and ETH presentation token, click the button on the bottom left.

Balance Sheet

Below is a cumulative view of MakerDAO assets, liabilities, and equity, at various levels of aggregation. Feel free to click through these levels of aggregation or to dive into the months of a particular year by right clicking the year and selecting “drill down”. To toggle between DAI and ETH presentation token, click the button on the bottom left.

It is noteworthy to mention that, while traditionally in accounting, liabilities and equity are negative, we have made the choice to not follow this convention to make the numbers more intuitive (accounting minds can mentally multiply every figure in these categories by -1 to produce the convention they are accustomed to). This would make calculating the check easier (Asset = Liabilities + Equity), but would show negative revenues which is unintuitive.

open in new tab

Statement of Changes in Protocol Surplus

Following is a statement of changes to protocol surplus made from the same source data. This is a reconciliation of changes from period to period for the balance sheet above. These changes can be summarized as changes from net protocol income along with changes in token holdings. To toggle between DAI and ETH presentation token, click the button on the bottom left.

open in new tab

Next Steps

• Please provide your comments on the MakerDAO forums
• We invite the community to provide their views on the above work
• We look forward to a lively discussion over the choices we made
• We will be as reactive as we can to adapt any prevailing consensus different to our own choices, with the aim to make it maximally useful to the community
• We have open sourced the query we used to produce this data set and welcome constructive feedback
• If there are third-parties who will be leveraging this data or a fork thereof, especially for commercial distribution (gm Messari), we request you to:

1. Cite the source of data appropriately
2. Make a (voluntary) community contribution to the protocol through an ETH or ERC-20 transfer to the governance-controlled Pause Proxy address: 0xBE8E3e3618f7474F8cB1d074A26afFef007E98FB

Special thanks to Chef lyt: (twitter/dune)

‍