Skip to content
Valuations
Valuations in Index Wallets
Read the Thread
More
Share
Explore

Valuations in Index Wallets

The Plan

We've made quite a bit of progress on getting to a framework for answering some of our longstanding questions about Index Wallets. Remember we used to refer to this work as Deposition, because we're "Deposing the Endorsement Dictator" and we since learned that we couldn't quite answer the important questions analytically. So we went on a long meandering journey to find the right framework to evaluate those questions that we have.
I believe we now have that framework.
Let me document our work from last time and the elements we came up with. First a list of all the relevant classes:
Player
ProductDemand
Wallet
Index(Wallet)
Product
Vendor(Player)
Offering
Market
What we imagine we're annealing to is this:
Every Player has some private valuation, a wallet, and product demand
That demand is governed by a demand curve which says how much of a certain product they'll buy at a given price
Some Players are also Vendors, Vendors have product demand just like players, but they also have Offerings which are available in the Market
Every day a Vendor resets their valuation based on what maximizes their expected profit
In order to figure that out, we'll need to equip our Vendors with the ability to forecast their revenue based on their change in valuation. The primary problem we face on this front is that we need to implement general intelligence to enable players to optimally play here. We don't want to need to do that, though we'll get there eventually. Instead, what we want to be able to do is to in the next 40 minutes or so get to an interesting result that comes from reasonable assumptions.
What I would argue is that there are two possible ways to do that:
we can try to evalutate the dynamics of a two player game of vendor wars, where there is one customer and two vendors competing for their revenue, we allow the vendors to compute the optimal moveset, accounting for strategic play
we can try to show the steady state dynamics of a network
From my conversations with Ken, the second one would be the more interesting result. The problem is that we won't be able to implement strategic play because it's computationally intractable. Let me explain: When the Vendor tries to set their valuation, they look out at the market and they plot a curve which tells them how much they would make for every change in valuation. Literally, the loss that they're computing is:
- purchasing_power(wallet + expected_earnings, new_valuation)
by minimizing that quantity they're moving around their valuation until the earnings that they get from changing their valuation increase enough that the decrease in value to their purchasing power on the next turn is worth it.
As I pointed out, there are two problems with this approach:
customers don't smoothly switch between vendors, so you can't compute a gradient
doesn't account for how other people change their valuations
Let's take these each one at a time: #1 customers don't smoothly switch between vendors, so you can't compute a gradient
We assume that customers buy their product from the cheapest vendor. This means that if apples are available for $5 from vendor A, and $7 from vendor B, the customer is going to buy all of their apples from vendor A. Let's say that vendor B reduces their price by $1, down to $6, they won't notice any benefit from their price reduction. It's not until they get their price below that of vendor A that all of the purchasing from that customer switches to them. In our ideal world, that transition would occur gradually so that we could compute a gradient and then perform gradient descent. But in the absence of pure gradient descent we have to find a smarter search strategy for our vendor to follow. It turns out that there is one: let's take a vendor's perspective, how will they figure out how to price their products?
Of course, they'll look at their competitors. They'll say, "they're selling stuff at that price, so I guess if I want people to buy I need to be at or below that price." Normally, that would mean that there's a single dimension to all this, which is quite easy to solve for: they set the price at $5, I should set it at 4 (or whatever $5 - meaningful_inc is). But with index wallets, changing a valuation has impacts on your purchasing power, so the actual way to solve this problem is more like:
list the customers that will purchase from your competitors at the current price
imagine changing your valuation to something that would cause them to buy from you
check whether their switching value would account for or overcome the loss to purchasing power, if so, switch
You'll notice though that this approach has three problems:
the combinatorics of checking all combinations of possible customers
other players changing their valuation based on your move
competitors anticipating this move and responding immediately, taking back their customer but hurting your purchasing power
#2 we've already mentioned as a problem, and #3 we've noted is out of scope for this simulation, so we'll start by addressing #1.
What is the time complexity of checking the combinations of possible customers? At first approximation, it's bad, O(2**k) where k is the number of customers. But, it might not be that much of a crisis. This is where this thread comes into play:
see screencap or
Read the Thread
⁠
⁠
⁠
image.png
⁠
⁠
I think that in that model we were assuming that you got a proportion of the customer's purchase. Now we're throwing that out. Maybe it's a good simplified model, and it's probably informative, but we'll be better served by modeling as closely as possible real world dynamics and then we can relax to coarse graining.
Ok, so let's solve this combinatorics problem. Essentially, what matters is that there are a bunch of vectors in some space, representing the wallets of customers. Then there are the vectors of our competitors, representing their valuations. By accounting for pricing, can create a new space out of that information.
Let's get an example set up:

calculations
⁠
[[
@A
[2.8754.3125]33.0625
@1, 10 for $46
][
@A
[4.1739130434782616.260869565217391]48
@10, 1 for $48
][
@A
[46]46
@10, 10 for $100
]][[
@B
[64]46
@1, 10 for $46
][
@B
[4.53]34.5
@10, 1 for $48
][
@B
[64]46
@10, 10 for $100
]]
⁠
⁠
⁠
[
@A
[2.8754.3125]33.0625
@1, 10 for $46
][
@B
[4.53]34.5
@10, 1 for $48
]
⁠
⁠
⁠
​
⁠
⁠
←the valuation you think you’ll get for this

Market Offers
0
Name
Valuation (Input)
Price
Total Revenue
1
1, 10 for $46
1,10
000
46
0
2
10, 1 for $48
10, 1
000
48
0
3
10, 10 for $100
10, 10
000
100
0
There are no rows in this table
⁠
(don’t think of Wallet as the actual wallet contents but rather the ratio between the assets)
Customers
0
Name
Demand
Valuation (Input)
Wallet (Input)
1
A
4
10, 1
4, 6
2
B
5
1, 10
6, 4
There are no rows in this table
⁠

So now we’ve made progress on showing the steady state dynamics of a network of players paying one another with index wallets. We’ve found that we can think of the competitive landscape through the lens of Market Offers, each of which renders some revenue if adopted. This will help us set up a search process for each competitor seeking to optimally set their valuations in the context of a customer set.
The initial property we’re looking to show is that given some set of demand from the customer base, the economy settles down to a steady state.
The second property we’d like to demonstrate is how the system can adapt to

Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.