Tim Daubenschütz
    • Create new note
    • Create a note from template
      • Sharing URL Link copied
      • /edit
      • View mode
        • Edit mode
        • View mode
        • Book mode
        • Slide mode
        Edit mode View mode Book mode Slide mode
      • Customize slides
      • Note Permission
      • Read
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Write
        • Only me
        • Signed-in users
        • Everyone
        Only me Signed-in users Everyone
      • Engagement control Commenting, Suggest edit, Emoji Reply
      • Invitee
    • Publish Note

      Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

      Your note will be visible on your profile and discoverable by anyone.
      Your note is now live.
      This note is visible on your profile and discoverable online.
      Everyone on the web can find and read all notes of this public team.
      See published notes
      Unpublish note
      Please check the box to agree to the Community Guidelines.
      View profile
    • Commenting
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
      • Everyone
    • Suggest edit
      Permission
      Disabled Forbidden Owners Signed-in users Everyone
    • Enable
    • Permission
      • Forbidden
      • Owners
      • Signed-in users
    • Emoji Reply
    • Enable
    • Versions and GitHub Sync
    • Note settings
    • Engagement control
    • Transfer ownership
    • Delete this note
    • Save as template
    • Insert from template
    • Import from
      • Dropbox
      • Google Drive
      • Gist
      • Clipboard
    • Export to
      • Dropbox
      • Google Drive
      • Gist
    • Download
      • Markdown
      • HTML
      • Raw HTML
Menu Note settings Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
Versions and GitHub Sync Engagement control Transfer ownership Delete this note
Import from
Dropbox Google Drive Gist Clipboard
Export to
Dropbox Google Drive Gist
Download
Markdown HTML Raw HTML
Back
Sharing URL Link copied
/edit
View mode
  • Edit mode
  • View mode
  • Book mode
  • Slide mode
Edit mode View mode Book mode Slide mode
Customize slides
Note Permission
Read
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Write
Only me
  • Only me
  • Signed-in users
  • Everyone
Only me Signed-in users Everyone
Engagement control Commenting, Suggest edit, Emoji Reply
Invitee
Publish Note

Share your work with the world Congratulations! 🎉 Your note is out in the world Publish Note

Your note will be visible on your profile and discoverable by anyone.
Your note is now live.
This note is visible on your profile and discoverable online.
Everyone on the web can find and read all notes of this public team.
See published notes
Unpublish note
Please check the box to agree to the Community Guidelines.
View profile
Engagement control
Commenting
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
  • Everyone
Suggest edit
Permission
Disabled Forbidden Owners Signed-in users Everyone
Enable
Permission
  • Forbidden
  • Owners
  • Signed-in users
Emoji Reply
Enable
Import from Dropbox Google Drive Gist Clipboard
   owned this note    owned this note      
Published Linked with GitHub
Subscribed
  • Any changes
    Be notified of any changes
  • Mention me
    Be notified of mention me
  • Unsubscribe
Subscribe
# On further rationalizing the ROI metrics in the OCEANDAO ## Table Of Content [Toc] ## Problem Statement The oceanDAO mandates all proposals to publish a "Return-On-Investment" calculation along with their proposal [1]. The idea being that if only "positive ROI projects" get funding by the oceanDAO, then the oceanDAO will return an overall positive ROI. In the wiki, similarities to VC funding are mentioned [2]. Over the oceanDAO's past existence, however, this ROI metric has lead to numerous misunderstandings and conflicts within the DAO. In this document, I'd like to enumerate some of the problems that a grantee like rugpullindex has encountered with a heavy reliance on this rather theoretical and subjective metric framing. ## Insufficient distinction between _lag_ and _lead_ metrics Generally speaking, when optimizing a process it's useful to track a variety of metrics that can serve as a proxy for the success of the optimization. However, to successfully navigate using a metric-driven development approach, it's advicable to distinguish metrics between _lag_ and _lead_ metrics: - **Lag metrics**: Describe the thing you're ultimately trying to improve (e.g. the goal of increasing customer satisfaction or increase in sales/revenue) - **Lead metrics**, in contrast, describe new behaviors that may drive success in lag metrics. A good rule of thumb is that **lag metrics** *lag behind time*, while **lead metric** *lead the way*. The oceanDAO ROI document, however, makes no distinction between these two types of metrics. It's separating between "primary" and "secondary" metrics, but those don't caputure the concept of lead and lag metrics. I think, the oceanDAO ROI document should specifically make a conceptual distinction between different types of metrics and which are useful for tracking the near and/or long term. ## ROI calculation mandate promotes dubious practice of generating arbitrary positive ROI calculations Is anyone aware of any oceanDAO proposer that, in the last second, withdrew their proposal because they've noticed that their ROI calculation won't turn positive? In this case I'll just point out that clearly the tail wages the dog. Nobody would stop their project if their ROI calculation turned out negative. I think we can all agree that it wouldn't make much sense either. Instead, an author is expected to fiddle with the calculation until its return becomes non-negative. Naturally, we can't expect any of the calculations to carry much signal regarding the actual return of the project. The calculation's existence is based on the idea to be non-negative and that's what their authors optimize it for. ## The data set market is emergent and it may not be useful to speculate on its near term value To convince yourself of this statement, just look at the numbers of the OCEAN marketplace today. If you actually do the research, you'll see that over the last 6 months there were hardly any data set consumptions. I'd argue that the total amount of data consumption remains in the five figure dollar range (it's only a guess). Most charts on rugpullindex are correlated heavily with OCEAN - because there's simply no trading happening on these data pools. So speculation isn't happening either yet. Of course, none of this is meant in a bad way. It's merely addressing today's reality. If e.g. we at rugpullindex wanted to show a purely rationally-calculated ROI based on "network revenue" generated through users clicking from our website to buy on the OCEAN market - our *bang* would most likely be lower than the *buck*. Not because we did a bad job, but because the timing of our product and the timing of OPF's marketplace simply hasn't fully aligned with reality yet. Simply put: full product/market fit hasn't been achieved yet. So then, why do a bang/buck calculation if bang is necessarily smaller than buck? An example based on Evotegra. For 21 EXCANE-93 at a price of 980.27€, they've achieved a total value locked of 20k EUR which would only allow the participation of e.g. a single round in the oceanDAO. Obviously though, they've generated much greater bang than that, but applying the ROI framework yields no useful calculations. Even if the Ocean Marketplace team were to propose in the DAO with a ROI calculation, it's likely they should be rejected on its basis too. Dont' get me wrong, they're arguably doing a great job building things. But they neither have managed to capture a *bang* that is high enough to justify the monthly *buck*. It's because we have to assume that most value will be captured in the future and over a longer period of time than just today. So clearly, we're talking about returns of investment on a much longer scale, e.g. that through all the work done now - maybe in 5 years a ROI will become clearly positive. ## oceanDAO teams aren't in control when it comes to measuring The primary fundamental metrics are "total ocean consumed", "network revenue" and "total value locked". However, to measure these metrics rationally and without some bogus assumption in their ROI calculations, oceanDAO teams require infrastructure that puts them in control when measuring. In the case of RPI, since we've started tracking our outbound clicks, we've sent more than 500 people to promising data sets on the OCEAN marketplace. Undoubtably, some investors have taken the information provided on the website to further their investment decisions. There might have been some buys! But they don't show up anywhere and RPI isn't aware of them. This is because it's very challenging for RPI to rationally track which clicks actually facilitated a sale. Given that the Ocean Marketplace has no way of reporting back to RPI when a sale has occurred, we're unable to know what happens on their site. Personally, I doubt this problem can be addressed in the short term as building a sales referrer system is not a trivial task either. I've [submitted](https://github.com/oceanprotocol/market/issues/811) an issue on the marketplace for the time being. What is becoming clear from this situation, however, is that RPI isn't in direct control of delivering any of the required metrics as we can't speed up or prioritize work on the Ocean Marketplace single handedly. We're not in control. For now, we're left to speculate and that's the opposite of rationalization. ## oceanDAO teams lack vital legal support structure for serving the required metrics Another option that a project can take to rationalize their ROI is by e.g. directly spinning up a data token pool and measuring e.g. the amount of OCEAN staked. One example of this is DataUnion's data token pool. But also with this, there are several hurdles that will first have to be overcome by teams before any ROI measurements: - The project will have to spend money on a lawyer that can advise them to set up shop in a crypto-friendly juristiction - The project will have to either relocate or be willing to take the potential risk of still being liable in their juristiction. - The project will have to advertise the token to a degree that *bang* > *buck*. But then also the question is: If the oceanDAO team is capable of spinning up their own token legally and advertise it - why ask for funds from the oceanDAO in the first place as selling their token might be a more value-capturing activity? ## Arbitrariness in calculation of ROI leads to continous controversy As a continous receiver of funds from the oceanDAO since round 2, I've probably read more proposals than is good for me. One situation that I believe will lead to further continous controversy is the arbitrariness in calculation of ROIs. There's simply no authority for ROI calculation that stands out. Everyone is on the side lines and the ROI document itself isn't giving clear guidance either. E.g., there's not a common understanding of probability. It's commonly understood that like 90% of all startups will eventually fail and that their value will be zero or negative. Then why do many proposers state a `chanceOfSuccess` rate of much more than 10%? There's a vastly different perception of what is truly valuable and what's not. E.g. in one of the last rounds there were proposals that calculated ROI's for newsletters in the range of more than $100000. While I tend to agree that given an enormous success, a news letter could yield more than $100k, I think popular examples are vast outliers in a pool of mainly valueless news letters. But hey, I don't doubt that these efforts weren't done with best intentions in mind. But then the second problem is that in case the project returns in a secondary round, at that point: How can we now rationally update our ROI calculation? The worst part of this is: If controversy emerges, it's unclear which party is "right" or doing things in the proper way. It's because there's no proper way. ## Monthly ROI reviews haven't helped me As I've said earlier, in the beginning of a project's lifecycle, calculating the business' ROI is definitely a helpful exercise in understanding where its value may sit. However, having to show up with an updated ROI calculation on a monthly basis hasn't provided any value and mainly frustration to me personally. Between R2 and R8, not many of the fundamentals of rugpullindex have changed. Amongst other things, we still want to eventually launch an index token that allows users to buy exposure to data sets. So between R2 and R8: What has changed that we could report on? - We've started tracking our web analytics - We've started tracking our customers of the API - We're starting to track other metrics - We've managed to continously ship However, one could argue that none of these things influence either bang, buck or chanceOfSuccess. We're not tracking anything related to network revenue or other fundamental OCEAN metrics as simply we can't. For the most time, we've logically resorted to building product as this has arguably lead to a positive outcome in the oceanDAO votes. There'll definitely be the day where we want to launch the index token to our users. On that day, we'd like to publicly track e.g. network revenue to TVL. But until that day comes, somehow it should be possible for us to make a rational case to the oceanDAO for why OCEAN holders should vote for our product. We'd appreciate if the oceanDAO appreciated to measure REAL and existing metrics *first*. I'd like to make clear that I'm not "against" the ROI calculation. Rather I'm arguing FOR AN IMPROVED concept of tracking the metrics within the oceanDAO. I think distinguishing between types of metrics can help. Further education and deliberate moderation can help too. I just would like to avoid continuing with the status quo as it's frustrating for many. ## References - 1: https://github.com/oceanprotocol/oceandao/wiki/Grant-Proposal-Template - 2: https://github.com/oceanprotocol/oceandao/wiki/On-ROI#similarity-to-venture-capital - 3: NEWPORT, Cal. Deep work: Rules for focused success in a distracted world. Hachette UK, 2016.

Import from clipboard

Paste your markdown or webpage here...

Advanced permission required

Your current role can only read. Ask the system administrator to acquire write and comment permission.

This team is disabled

Sorry, this team is disabled. You can't edit this note.

This note is locked

Sorry, only owner can edit this note.

Reach the limit

Sorry, you've reached the max length this note can be.
Please reduce the content or divide it to more notes, thank you!

Import from Gist

Import from Snippet

or

Export to Snippet

Are you sure?

Do you really want to delete this note?
All users will lose their connection.

Create a note from template

Create a note from template

Oops...
This template has been removed or transferred.
Upgrade
All
  • All
  • Team
No template.

Create a template

Upgrade

Delete template

Do you really want to delete this template?
Turn this template into a regular note and keep its content, versions, and comments.

This page need refresh

You have an incompatible client version.
Refresh to update.
New version available!
See releases notes here
Refresh to enjoy new features.
Your user state has changed.
Refresh to load new user state.

Sign in

Forgot password

or

By clicking below, you agree to our terms of service.

Sign in via Facebook Sign in via Twitter Sign in via GitHub Sign in via Dropbox Sign in with Wallet
Wallet ( )
Connect another wallet

New to HackMD? Sign up

Help

  • English
  • 中文
  • Français
  • Deutsch
  • 日本語
  • Español
  • Català
  • Ελληνικά
  • Português
  • italiano
  • Türkçe
  • Русский
  • Nederlands
  • hrvatski jezik
  • język polski
  • Українська
  • हिन्दी
  • svenska
  • Esperanto
  • dansk

Documents

Help & Tutorial

How to use Book mode

Slide Example

API Docs

Edit in VSCode

Install browser extension

Contacts

Feedback

Discord

Send us email

Resources

Releases

Pricing

Blog

Policy

Terms

Privacy

Cheatsheet

Syntax Example Reference
# Header Header 基本排版
- Unordered List
  • Unordered List
1. Ordered List
  1. Ordered List
- [ ] Todo List
  • Todo List
> Blockquote
Blockquote
**Bold font** Bold font
*Italics font* Italics font
~~Strikethrough~~ Strikethrough
19^th^ 19th
H~2~O H2O
++Inserted text++ Inserted text
==Marked text== Marked text
[link text](https:// "title") Link
![image alt](https:// "title") Image
`Code` Code 在筆記中貼入程式碼
```javascript
var i = 0;
```
var i = 0;
:smile: :smile: Emoji list
{%youtube youtube_id %} Externals
$L^aT_eX$ LaTeX
:::info
This is a alert area.
:::

This is a alert area.

Versions and GitHub Sync
Get Full History Access

  • Edit version name
  • Delete

revision author avatar     named on  

More Less

Note content is identical to the latest version.
Compare
    Choose a version
    No search result
    Version not found
Sign in to link this note to GitHub
Learn more
This note is not linked with GitHub
 

Feedback

Submission failed, please try again

Thanks for your support.

On a scale of 0-10, how likely is it that you would recommend HackMD to your friends, family or business associates?

Please give us some advice and help us improve HackMD.

 

Thanks for your feedback

Remove version name

Do you want to remove this version name and description?

Transfer ownership

Transfer to
    Warning: is a public team. If you transfer note to this team, everyone on the web can find and read this note.

      Link with GitHub

      Please authorize HackMD on GitHub
      • Please sign in to GitHub and install the HackMD app on your GitHub repo.
      • HackMD links with GitHub through a GitHub App. You can choose which repo to install our App.
      Learn more  Sign in to GitHub

      Push the note to GitHub Push to GitHub Pull a file from GitHub

        Authorize again
       

      Choose which file to push to

      Select repo
      Refresh Authorize more repos
      Select branch
      Select file
      Select branch
      Choose version(s) to push
      • Save a new version and push
      • Choose from existing versions
      Include title and tags
      Available push count

      Pull from GitHub

       
      File from GitHub
      File from HackMD

      GitHub Link Settings

      File linked

      Linked by
      File path
      Last synced branch
      Available push count

      Danger Zone

      Unlink
      You will no longer receive notification when GitHub file changes after unlink.

      Syncing

      Push failed

      Push successfully