Dividend Revenue Sharing

With the official announcement of Rafiki soon Interledger-enabled wallet providers will have upgraded payment systems on Interledger, charting to a new territory where developers world wide finally has the power to manage their own custom subscription and more flexible tipping--a pretty big upgrade from what previously limited to receiving payments. This would translate to more tools for everyone to create a business model better fit for their business and audience behaviour. Pretty soon, we’ll see more awesome experiments and Interledger implementation as the next iteration of Rafiki testnet becomes available for developers to play with.

Now, I'm sure you are as excited as I am waiting for the next version of Rafiki live testnet. Interledger payments enabled by the new and shiny Rafiki will be more flexible than current Web Monetization API, but doesn't really have the convenience of no sign up plug-n-play subscription across websites like Web Monetization API has. Another the crucial capability that Rafiki lack compared Web Monetization API is revenue sharing, as currently, the Web Monetization API doesn't seem to have a clear path on how implementing revenue sharing on Interledger payments.

Neither does Web Monetization API, actually. Interledger and OpenPayments aren't designed to include revenue sharing natively in their specification. And currently Web Monetization API does revenue share with a workaround that rely on probabilistic means--of which, based on the laws of probability, will eventually pay contributors fairly given enough volume of transactions happen.

The problem with Probabilistic Revenue Sharing that Web Monetization API uses is that it is mainly works for micropayments that is small in value but very high in volume. For a products made by 20 people that cost $10, say, have about 30 weekly sales, using Probabilistic Revenue Sharing to compensate contributors randomly is simply having a lottery. This likely resulting to a situation that doesn't favor small time publishers and teams of content creators, especially when they just get started where contributors who don't get lucky in their probabilistic revshare draw might got discouraged by the zero balance in their wallets. Probabilistic Revenue Sharing is awesome for Web Monetization but we probably have to move on to something new to get the most out of Interledger payments.

Now, since most Interledger payments aren't using STREAM mechanism unlike Web Monetization, of course splitting payment at Interledger level will be simpler than before. The previous product that cost $10 could just be split at $0,2 to every creators that contribute to the product at the time payment got processed. This of course will have to go through a middleman payment pointer address as to avoid confusion for paying customers. However, since they already create a payment pointer, chances are they're going to use that not only to receive payment for their products, but also to receive payments for Web Monetization API for their blog posts, or to get paid regularly with monthly subscription using Interledger mandates. Now this is how things are starting to get complicated.

With simple payment with invoice mechanism you could just split payment once a money arrived at the middleman payment pointer address. But for splitting Web Monetization stream you'll have to hook up on the server and create a several ongoing stream to different recipient, and many of us have no clue how it will impact the performance once the stream branched to, say, one hundred recipients at the same time. As for splitting subscription payments? Good luck with that, my friend.

This is not to say that splitting revenue with Rafiki isn't feasible. We can also try something that agnostic to whichever Interledger payment we're going to use. I'm propose to use a method that everyone is already familiar with: wait until the wallet filled up with money then do payouts regularly to contributors. This is what I'd call Dividend Revenue Sharing, aka Payout Revenue Sharing, aka How Everybody Share Revenues In Real Life.

Enough for my rambling. Let's get into a (not real) demo.

// this could be reused revshare pools from Web Monetization API
const revShareRecipients = [
  {
    "name": "Johnny",
    "payment_pointer": "$my.wallet.com/johnny",
    "email": "johnny@email.com",
    "shares": 0.6 // in percentage
  },
  {
    "name": "Samantha",
    "payment_pointer": "$my.wallet.com/samantha",
    "email": "samantha@email.com",
    "shares": 0.3 // in percentage
  },
  {
    "name": "Young",
    "payment_pointer": "$my.wallet.com/young",
    "email": "young@email.com",
    "shares": 0.1 // in percentage
  },
]

// do a cron job that regularly call a function on a server at fixed interval
async function scheduledDividendPayout() {
  if (thereIsMoneyInMiddlemanWallet() === true) {
    const accountBalance = await getAccountBalance(middlemanWallet)

    revShareRecipients.forEach((recipient) => {
      const moneyToBePaid = accountBalance * recipient.shares
      try {
        await sendPayout(recipient.payment_pointer, moneyToBePaid)
        notifyPayoutTo(recipient.email)
      catch(err) {
        console.error("Payout failed :(. Maybe try again later.")
      }
    } 
  }
}

The example above is not an actual working code. But it should be recognisable that the script intends to be used to distribute all balance to contributors at a fixed interval. This should be a middleman wallet that not tied to anyone's personal account, if possible, and ideally there should a method to make it transparent for involving parties to audit the wallet like how open source maintainers managed fund in OpenCollective--though this is a feature most likely for wallet providers to decide.

This method does have its own pros and cons; aside from simpler all-in-one revshare implementation, the fact that the Interledger will have to deal only one payment pointer will provide more accurate and fair compensations to what Probabilistic Revenue Share does for low volume transaction, because we don't need to wait the laws of probability to work its magic to compensate contributors fairly. Not to mention, in case there were unused balance in Web Monetization account at the end of the months, Web Monetization companies like Coil will probably distributed the remaining balance to all of the payment pointers subscribed users visited in that month--this not including all of the payment pointers that didn't get lottery from Probabilistic Revenue Sharing draws, which could further murky how people get compensated in a community where revshare is a common norm. Dividend Revenue Sharing is simply counted as one payment pointer and thus will be calculated as one entity by Coil and other WM providers while at the same time, will split revenues based on splitting the real amount of balance the payment pointer wallet received. There will be less confusion on the payment because there's already a wallet acted as middleman to manage who's going to get how much and so on.

The cons are, well, isn't really a cons depending which angle you're looking at it. Wallet providers will be the one who are going to implement Rafiki, and they'll be the one who decided the features and the APIs us developers going to use--though we can expect the implementation will be standardized based on how the Interledger specs and something like how the OpenPayments standard goes.

Now, I'm sure Interledger team has been working hard on Rafiki, working closely with wallet providers and I'm pretty sure they'll heard us developers loud and clear, as in this early stages of Interledger we all benefits from learning from each other. However, not to mention that different wallet providers might not providing the same experience, features, and API design, I'm also pretty sure many in the community will have novel ways of payments and bleeding edge business models that is not covered in current Interledger use cases, like revenue sharing, perhaps, and having to wait for wallet providers to polish the sharp edges for us instead of doing it ourselves kinda feels a little bit, well, less adventrous.

NOTE: This is a follow-up post for my recent "Revenue Sharing on Rafiki Mega Thread". If you have another solutions for Rafiki-based Interledger payments, please do visit that post and let me know your thoughts!