/ xrp

Towards a balanced scorecard for XRP and a data-driven approach to valuation

Dario Boriani

Dario Boriani

Read more posts by this author.

Read More

For a while now I have been thinking about crypto valuations. This is still a very fuzzy subject, because of a lack of widespread adoption of digital assets or revenue streams from which to gauge growth, and so on.

Still, as a holder of the digital asset XRP, I find myself wanting to sink my teeth into something more concrete than mere speculation as to future adoption and price. While people talk about xCurrent, and how financial institutions are trialing it or using it while also joining RippleNet, the use of xRapid together with XRP is still embryonic.

In my previous post I discussed the information on XRPCharts7, raised some questions, and offered some suggestions to reflect on. In this post, I want to continue along those lines and discuss how to gauge the progress of XRP using various criteria that seem to me to be worthy of consideration.

I believe enough data exist to develop a clearer understanding of how things are going in near-real-time rather than having to cobble together bits of news, rumors, and the like, hanging on supposed announcements, or have to expectantly rely on quarterly reports, interesting as they may be. So, I am just going to jot down a few ideas and hope they serve as food for thought. You have to start somewhere.

Ideas about valuation: back to...er, back from the future

It strikes me that no one really knows how to value digital assets. It is still very early days as far as adoption, and price is tied to speculation by small-time investors and manipulation by big players, in the absence, as yet, of regulation.

A while back I read a very interesting attempt by someone to arrive at a sensible floor value for the price of XRP around 2020, based on institutional adoption and taking into account amounts held by various parties making markets as well as the reuse (inventory turns) of any XRP token involved in transactions over a time period of choice, say 24 hours. Read all about it here.1

A DCF (Discounted Cash Flow) model was suggested here and is discussed here, with the comments hinging on whether the model is thought to apply -- as XRP may or may not be deemed a security -- and whether XRP's valuation can be completely or partially divorced from Ripple's own fortunes. It is one thing to say that the open-source XRP ledger would continue to exist even if Ripple were to disappear overnight, but it is quite another to discount the push that Ripple can generate for XRP adoption just by continuing to build Ripplenet and offering partners additional savings by transitioning from xCurrent to xRapid/XRP.

In any event, these future valuations, most going out three to five years from now, range over a couple of orders of magnitude, with some arriving at figures below USD 5 and others estimating an eventual price of several hundred dollars.

Models for the valuation of other digital assets (DAs) have appeared on the Internet. One is based both on the eventual money base (hoarded, plus actually used coin) for Bitcoin and on an investor's hurdle rate (risk and desired return relative to other investment possibilities), and is presented here. This approach hypothesizes a future money base -- and thus price, given the fixed supply of the DA itself -- and projects it back to the present using the risk-adjusted hurdle rate.

These are all interesting thoughts in their own right, and one can spend weeks and months trying to tweak the various models or coming up with new ones. In my modest opinion, with a known supply of XRP, about a third of which in circulation and the rest in a rolling-horizon escrow and tied to specific access rules for the next 5 years at a minimum, it all comes down to unknown demand and additional potential uses, most as yet unforeseen. This is the 'weakness', if we want to call it that, of speculative valuations trying to deduce a present value from a future one which is anchored in the nautical equivalent of a grassy bottom, traditionally a difficult one to trust as a secure hold for your boat. If anything is possible and the range of scenarios is almost infinite, how useful a forecast can one come up with?

My question is, can we come at this from a different angle? What can we do with information that is available now, and that can be extracted from data that are being collected or can be collected today? Can we get a picture of XRP's health and as early investors develop a sense of its potential, based on concrete evidence rather than simple (or sophisticated) guesswork as to future adoption? In what follows, I will attempt to take a few steps down this path.

What is a balanced scorecard?

Balanced scorecards have been around for a while. A balanced scorecard is similar to the complete physical and full blood work your physician might order for you when trying to get the big picture and what to treat or act on first. As you may suspect or have heard from the name, a balanced scorecard provides a snapshot of an organization's situation according to a few categories or dimensions judged important to gauge the overall health of the enterprise. While in theory many such dimensions exist, over time, they have reduced to a standard few, including: financial, customer, learning and growth, and internal processes and operations. Take a look at the image below, sourced from Norton and Kaplan5:

bsprocess
Balanced scorecard.5

A balanced scorecard is meant be a performance management tool. It is akin to a closed-loop process controller -- think of the programmable thermostat in your home that controls the HVAC. When you aim for a given ambient comfort level, you set a reference or target temperature as input to the system, a measurement is made of the current temperature, the difference between the two is calculated, and an intervention is made to correct and reduce a non-zero difference by turning the heating/cooling system on or off. This is all done at some periodic rate. Most process controllers do it automatically via an algorithm -- a sequence of computational steps -- involving data acquisition by some sensor, signal conversion, error calculation, control signal calculation, and control signal output and actuation. As an aside, beyond simple on/off, the bread-and-butter of industrial control is the PID (proportional, integral, derivative) algorithm. There's no shortage of fancier ones, and this is an area where many predictive algorithms and ideas were first hatched and got going, eventually extending to prediction in other domains.

An analogous situation occurs in organizations. It takes people, meetings, persuasion, sensible discussions, dealing with biases and poorly-argued viewpoints, achieving consensus, implementating, reviewing, and so on to 'steer the corporate ship.' A well-thought-out scorecard shows how things are going and points in the direction of needed corrections. The similarities between industrial control and organizational improvement are many, although you won't get much of an argument from a thermostat. Once AI is fully incorporated, however, you may -- I'm only half kidding here.

Specifically, a scorecard asks questions to help us along in various categories:

  1. Financial: how does our organization appear to its shareholders?
  2. Customer: what do customers think of our product or service?
  3. Innovation, Learning, and Growth: how is learning tied to our growth?
  4. Internal/Operations: what processes do we need to master?

Other, complementary dimensions, such as Staff Satisfaction, are being added to newer scorecards.

Note also that, as the above figure shows, under each category we find Objectives, Measures, Targets, and Initiatives. Objectives are what you are trying to accomplish, Measures are indicators of eventual success, Targets are actual values to aim for within each of those Measures, and Initiatives are the projects you need to undertake or things you need to address to achieve the Objectives.

While nothing is particularly new about these indicators taken one by one, the balanced scorecard's unique perspective is that every dimension scored is considered to be equally important to strategy, hence the qualifier 'balanced.' This is much more difficult to accomplish without such a consensus-based tool. The all too common alternative is an uncoordinated, conflict-prone, fragmented approach to monitoring and improvement, where some things can end up being ignored depending on the priorities of the moment and there is no consistency in assessment from period to period. I am partial to the consensus and balanced aspects of this strategy, much as I am to the consensus algorithm for validating transactions on XRP's ledger. To me, they seem to align in holistic fashion.

Other scorecards exist, but there is general agreement that most important metrics can be aggregated under 4-6 dimensions, and a sense of the health of an organization can be quickly developed from them.

CSFs, KRIs, KPIs, and PIs

In an organization which is performance-minded and truly mindful of the customer, Customer Success Factors (CSFs) stand for those areas of focus that are most important to manage. KRIs, or Key Result Indicators, are usually measures focused on recent or historical results. KPIs (Key Performance Indicators) and PIs (Performance Indicators) tell you what to focus on, and are mostly monitored and managed in near-real-time.

How might this apply to a digital asset such as XRP?

XRP is not an organization, Ripple is. But Ripple is a privately held company, meaning only a modicum of information to work with is available to us on the outside. After some thinking, I have summarized my understanding of Ripple's mission and objectives in the following terms:

Ripple is in the business of licensing payments software to financial institutions and building a payments-and-settlement infrastructure for the Internet of Value (IoV) that is centered around interoperability of ledgers and is guided by the vision of eventually moving value worldwide as easily, quickly, and transparently as data move today.

Speaking of transfer of value, a previous post discusses why and how to specify transfer of value formally as a means of anchoring designs to a perspective that aims to protect the rights of the customer from the start6.

14---1-3-
Laying the foundation.

It stands to reason that, given its significant ownership stake in XRP, Ripple is interested in the token doing well over time and appreciating significantly, something that will be necessary as xRapid comes into play and the amount of value moved per transaction increases in magnitude. So, from this angle, it is even more important to find a way to assess how XRP is doing. Price should follow value, but how does one establish value?

Basic ideas that can go into assessing the health and value of XRP

As we know, XRP is the digital asset that Ripple is positioning for settlement. In my opinion, there are both technical and non-technical dimensions of importance to collectively gauge the value and progress/utility of XRP.

Technical dimensions

The first technical dimension that comes to mind is performance.

To begin with, speed is of the essence for XRP to have the desired utility and for market makers to be exposed to volatility for only a brief time period. We know current numbers indicate it all occurs within 3-4 seconds, although perhaps with ancillary systems playing a role this can go to 10 seconds or so. The exact number is not important at this point, only that it may be a feature or metric for one of the dimensions. One could consider also the settlement times of the top 3 competing digital assets, and calculate a relative difference to gauge the lead or gap.

Real time: absolute or relative?

Speaking more broadly, it is important to establish whether a product specification of '3-seconds for settlement' is truly a pressing need for all customers or is an impressive feature and nice-to-have for many who can live with a transaction time of 10 minutes instead. Real-time is not always represented by an absolute figure, the speed-of-light option, or the tiniest time slice. Rather, it is the time that is useful for a response to occur or some important action to be taken, and so it is a relative measure. If, for any reason, you need only act upon a system every half hour, it is expensive and not too useful to be sampling data every 15 milliseconds. If, on a periodic basis, your system is able to respond within a time frame that is sufficient to achieve the corrections needed to the process being controlled, then that controller is operating in real time for all practical purposes. I just mention this by way of context. Exposure to volatility is a risk, of course, and likely much higher the longer a transaction takes.

Errors and mistake-proofing

Another thing that seems important is that speed is of no use if the transaction generates errors. All these transactions are supposed to be 'well-configured' before occurring, so that, for example, a transaction would not happen unless the funds or item of value to be transferred existed in the amount needed and this was known ahead of time, and unless the sender and receiver had been specified and checked to exist. There are a number of ways in which a transaction's lack of readiness to occur is detected and/or prevented. (see the legend in Transactions by Result on XRPCharts.) Exception-handling code can also help to take care of many undesirable situations, but if one could robustify the whole setup and ensure preventable errors cannot occur at all it would be even better.

Just as in process design we prefer mistake-proofing to error detection and subsequent fixing-and-patching as a philosophy, and just as quality's true north is zero defects, one of the best preventive approaches is to develop formal specifications and designs that can be proved correct. This is not easy in general, and especially for concurrent systems, which is also why sometimes only critical parts of a system are subject to formal specification and verification. Ripple has mentioned using invariants as part of their design and code, which is a good thing and also relatable to formal specification. For a bit more on this topic, I refer you to my previous post.6

Other dimensions

Getting off the technicals for a moment, what other things come to mind that we could assess XRP and its progress by? Remember, a balanced scorecard must try to cover complementary areas, not just one at the expense of the others.

We all suspect that more exchange listings are better than fewer. We also think more pairings of XRP with fiat help. Both of these could indicate greater acceptance of XRP in general, or awareness by the exchanges and others that demand for XRP is growing at the individual speculator level and is foreseen to increase on the institutional one as soon as regulation is in place. It is my understanding that exchanges are not the only places where XRP is transacted, so this may mitigate the positive impact of additional exchange listings.

What about community? I think community is important, from at least two angles. One is the growth of initiatives such as decentralization, Codius, xPring, and Cobalt, which concern and are meant to encourage developers, at least initially. The other is from the POV of sentiment, meaning opinions of XRP holders, prospective holders, regulators, and others.

What do we have so far? I see a few dimensions, with a few metrics under each, to wit:

  1. Performance/Technical: speed (time) of settlement of token, percentage correct transactions per time period, percentage correct (closed) ledgers per time period. Note these do not correspond to XRP alone, but obviously involve xRapid and the network. Still, when it is all in play, public expectations may be placed, rightly or wrongly, on XRP and how it performs.
  2. Customer-facing/Ease of ownership: number of new exchanges listing XRP per time period, number of new XRP/fiat pairings offered per exchange per time period, and online/offline wallets offering XRP 'storage'. Some of these could easily go under Growth, but I am trying to distinguish and give (retail) customers a voice as this keeps them in the loop as valuable testers and triggers for future changes.
  3. Community: some measures concerning both developers (projects) and XRP holders.
  4. Growth: number of validators added and Ripple-controlled validators dropped per time period (this could end up under Technical/Decentralization.) Number of new corridors seems relevant -- by way of illustration, basic topology shows the paths in a fully connected set of nodes grow as follows: 10 nodes/45 paths, 100 nodes/4,950 paths, 1,000 nodes/499,500 paths, 10,000 nodes/49,995,000 paths.) I will also mention partnerships, but I will qualify it narrowly as partners actually/newly using xRapid/XRP period-to-period (and in what volume). Only partners moving from xCurrent to trialing xRapid/XRP and those moving from trial to production in a specific time period should appear. Growth can also occur in new job postings and employees joining Ripple, offices opening in other countries, conferences attended and TV appearances by executives, tweets, articles, all of which may well impact the pace at which development occurs and relationships are developed. For now, I would prefer not to consider most of these other than for sentiment, of which more later.
  5. Learning and innovation: embedding means of learning continuously, whether driven by human experience or based on data analysis via machine learning, seems important. Ripple can benefit from positioning itself as a continuously learning organization, both from the point of view of the technicals and from the fast-morphing ecosystem angle.
  6. Process and Data: I believe process is central and as impactful as network growth to the future of XRP. This is the most difficult to gauge from the outside, but I think that as Ripple matures and starts paying greater attention to process, this will affect the speed with which growing complexity can be managed and sustainable changes made to features, designs, and specifications so as to increase reuse.

The above categories are by no means exhaustive, and degrees of overlap exist between them. A first pass for an XRP scorecard from a high-level perspective might look like the following, with dimensions somewhat aligned with those of a typical company scorecard:

Dimension - typ. organization What it is Dimension - XRP What it could mean - XRP
Financial defined earlier Performance zero-defects
Customer defined earlier Customer (retail) ease of ownership and use, provable safety
Customer (institutional) custodianship, low volatility, ledger interoperability
Growth defined earlier Growth market share, market expansion via redefinition of value (IoT, IoV)
Learning and Innovation defined earlier continuous improvement mindset, machine learning
Internal/Operations defined earlier Process and Data governance, synergistic POV
Community (public) public sentiment
Community (developers) platforms, initiatives

Balanced scorecards - a high-level view.

Let me now expand a little on what we already have here. Each table below corresponds to one of the XRP dimensions, and is analogous to those mentioned earlier -- financial, operational, related to learning and growth, and customer-oriented. Traceability is not 100%, for those who may be aware of that aspect.

What do the headers in the tables below mean?

Below are brief descriptions of the table headers for the tables that follow.

Dim stands for dimension. I have discussed dimensions above.
Obj stands for objective, or the overall goal to achieve for that dimension.
Init means Initiative, or what project or action is being undertaken to achieve the goal. I leave this column blank, as I am not privy to internal information.
Metric means what a success criterion by which to judge progress towards the objective.
Target stands for the minimum desired value to achieve for a given metric during the period in question. It could be an absolute measure (ex. settlement time of 3000 msec.) or it could be a relative one with respect to the previous period (ex. # of trusted validators added = P + N, where P is the number existing in the previous period and N is the number added (or lost) in the current period. No attempt is made here to calculate these numbers, except, for example, '0' as a target for zero defects.
Type and Unit refers to whether a metric is continuous (divisible, in milliseconds, ex. time) or discrete (countable, not divisible, unitless, ex. # of validators or # of nodes.)
Actual refers to the value of that metric for the current period, or the period that has just ended if the scorecard is evaluated then.
Delta refers to the difference between Target and Actual, and is for the time period in question relative to the previous period. It could be month-to-month, week-to-week, or day-to-day, depending on data collection and processing capabilities as well as need.

Table 1. Technical dimension for XRP scorecard.

Dim Obj Init Metric Target Type, Unit Actual Delta
Performance minimize volatility -- Settlement time (max.) 4000 C, msec.
Performance minimize volatility -- End-to-end Tx time (max.) 10000 C, msec.
Performance increase public trust -- Ledger-close errors 0 D, none
Performance customer satisfaction -- tesSUCCESS3 (Transaction by Result) 100% C, %
Decentralization increase public trust -- # of trusted non-Ripple validators P+N D, none
Decentralization increase public trust -- Agreement - % of validators differing with consensus (pass) 0 %, none
Decentralization increase public trust -- Disagreement - % of validators differing with consensus (fail) 0 %, none

Table 2. Growth dimension for XRP scorecard.

Dim Obj Init Metric Target Type, Unit Actual Delta
Growth retail adoption -- # of new accounts none D, none
Growth ease of ownership -- # of exchanges that added XRP P+N D, none
Growth ease of ownership -- # of new fiat/XRP base pairs P+N D, none
Growth institutional adoption -- # of partners moved to xRapid P+N D, none
Growth institutional adoption -- # of partners using XRP in production P+N D, none
Growth adoption -- volume of payments using XRP P+X% C, USD
Growth market creation and penetration -- # of new corridors P+N D, none
Growth network stability -- # of nodes on current/stable 'rippled' version P+N D, none

Table 3. Learning dimension for XRP scorecard.

Dim Obj Init Metric Target Type, Unit Actual Delta
Learning embed learning in org -- continuous improvement initiatives P+N D, none
Learning embed learning in org -- machine learning initiatives P+N D, none

Table 4. Community dimension for XRP scorecard.

Dim Obj Init Metric Target Type, Unit Actual Delta
Community (devs) redefine market -- # of new projects on ILP ledger using XRP none D, none
Community (public) increase public trust -- Sentiment towards XRP Pos Pos/Neut/Neg, none

Table 5. Process and data dimension for XRP scorecard.

Dim Obj Init Metric Target Type, Unit Actual Delta
Process understand business -- # of internal processes audited/baselined (Six Sigma) that involve XRP % of total C, %
Process improve business -- # of internal processes improved (Six Sigma/Lean) that involve XRP % of baselined C, %
Process & Data quality -- volume of XRP-related activities with zero defects P + X% C, %
Process & Data make change sustainable -- # put under governance P + X% C, %
Process & Data become learning org -- # of machine learning (ML) and process mining initiatives involving XRP data and processes started/completed P + N C, %

As you may note, not all entries in all tables are complete, as the purpose here is not to show a detailed design, and Initiatives, for example, is something only Ripple could decide on.

Periodicity and assessing progress

A scorecard is evaluated periodically. I don't discuss this aspect here, but it is clear that some metrics should be monitored on a 24x7 basis, while others may require less frequent measurement -- recall what I said earlier about 'real time' as being relative to the operating context rather than absolute in magnitude. Deciding on frequency of measurement is part of the overall design, and can generate useful discussions as to where and how best to allocate resources.

As to progress of initiatives towards a target, which can be associated with virtually any project-based activity, it pays to view things as not started, started (no distinction made as to stages of progress), or completed. This is because percent completion allows gaming of numbers and, together with fuzzy requirements, leads to scope creep and schedule and budget overruns. A simple, discrete count is more transparent -- 'not started' status is a 0, started is a 1, and completed is a 2, or similar convention. Anything that is not completely done does not get additional partial credit over something that was just started. This delayed-credit approach also acts as stimulus to those involved.

Conclusion

I have made a first, quite rudimentary attempt to frame aspects of XRP in a way that could get all of us holding XRP closer to understanding 'the health of the patient' at any point in time, and decoupling it from mere guesswork based on subjective expectations as to future adoption, made worse by the impact of as yet unimagined and completely new uses.

The concepts presented here have their general roots in ideas developed for the standard balanced scorecard5, but stand on their own as a means of gauging 'progress' and eventual utility for a digital asset such as XRP. The scorecard in development here makes no claims as to completeness. Importantly, the scorecard is not based on speculation about levels of future adoption, but proposes to explicitly track progress via measurement of period-over-period changes in selected indicators and give these needed visibility, while integrating a variety of measures at least partially derived from data currently graphed on XRPCharts3.

I started with a look at XRPCharts in my previous post, and I wanted to continue with something concrete that might represent the next step up in digestible, near real-time information developed from raw data about XRP -- whether these are currently being focused on (settlement time) or not (sentiment) -- and on the potential synergy of continuous improvement and machine learning to support sustainable change. I do not think that we are hopelessly stuck in a nebulous future of receding horizons when it comes to developing reasonable estimates of value if we shift our optics to the wealth of data available to us now and we frame them with tools such as the ones described here.

I hope I have succeeded in at least given readers of this post something to think about. All errors are mine.

In closing, I believe this, and you can quote me if you agree:

With visibility and clarity comes understanding, and transparency ceases to be a futuristic talking point. In my opinion, these are true pre-requisites to valuation based on growing utility.

References

  1. http://cryptoizzy.blogspot.com/2017/05/xrp-valuation.html
  2. https://www.youtube.com/watch?v=nSwSJQf1FOg&t=12s
    3.https://www.reddit.com/r/Ripple/comments/8n63ii/xrp_valuation_334_an_incorrect_model/
  3. https://www.investopedia.com/articles/investing/050914/easy-way-measure-bitcoins-fair-market-value-doityourself-guide.asp
  4. Kaplan, Robert S. and Norton, David P., The Balanced Scorecard: Translating Strategy into Action, HBR Press, Sept. 1996.
  5. https://xrpcommunity.blog/a-proposal-for-a-quality-specification-for-the-transfer-of-value
  6. https://xrpcharts.ripple.com/#/metrics

All images © 2000-2018 Dario Boriani.


Did you like this post by Dario Boriani?

Send some love: