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
    • Invite by email
      Invitee

      This note has no invitees

    • 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
    • Note Insights
    • 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 Versions and GitHub Sync Note Insights Sharing URL Create Help
Create Create new note Create a note from template
Menu
Options
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
  • Invite by email
    Invitee

    This note has no invitees

  • 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