# PT v4.1: Draw Percentage Rate (DPR)

Here I present a new way of computing chance using a Draw Percentage Rate. The DPR allows prize pools to operate autonomously, automatically scale prizes as deposits grow, and offer infrequent larger prizes. The existing V4 prize pools can be modified to support this new model.

Note: this is a very technical post and serves as a primer to the DPR concept that will be introduced next week as part of a broader push to simplify the protocol.

# Background

PoolTogether V4 introduced the idea of a prize pool network: a set of prize pools that share prizes. This is accomplished by dividing the probability space proportionally to the liquidity held by each prize pool. The “probability space” is the total number of combinations available; in PT we call this the total picks.

For example: if a prize pool has 50% of the TVL for the network then that pool is allocated 50% of the probability space. If there are 1000 picks, then the prize pool is allocated 500 picks, and users within that pool get a portion of the 500 based on their share of the TWAB. In this way chance is distributed fairly across the entire prize pool network.

However, this approach has downsides:

1. The probability space is fully allocated every draw; this means that on average the grand prize will be awarded once per draw. We cannot have less frequent, larger prizes.

2. Each prize pool needs to be aware of the TVL of the prize pool network which means, because the data lives across blockchains, that governance has to push that data to each chain for each draw.

How can we avoid this complexity?

# Draw Percentage Rate

The prizes that a prize pool wins are the returns for the pool. The ratio of prizes to prize pool TVL can be considered a percentage rate. Let’s explore the Percentage Rate for an example prize pool network.

Assume the total prize amount is \$1000 and we have three pools in the network:

• Pool A: \$10,000
• Pool B: \$20,000
• Pool C: \$30,000

The Network TVL is \$60,000. Each pool will be allocated a portion of the probability space (chance) like so:

Chance = Prize Pool TVL / Network TVL

• Pool A Chance = (10,000 / 60,000) = 0.166
• Pool B Chance = (20,000 / 60,000) = 0.333
• Pool C Chance = (30,000 / 60,000) = 0.5

We can see that Pool C, with 50% of TVL, gets 50% of the probability space.

Now let’s calculate the expected value of the draw:

Expected Value = Chance * Total Prize

• Pool A EV = 0.166 * \$1000 = \$166 per draw
• Pool B EV = 0.333 * \$1000 = \$333 per draw
• Pool C EV = 0.5 * \$1000 = \$500 per draw

What do these winnings look like in terms of percentage rate?

Percentage Rate = Expected Value / Prize Pool TVL

• Pool A returns = \$166 / \$10,000 = 0.0166
• Pool B returns = \$333 / \$20,000 = 0.0166
• Pool C returns = \$500 / \$30,000 = 0.0166

Intuitively, this makes sense. \$1000 prize for \$60,000 TVL is \$1000/\$60,000 or a 0.0166 rate of return. It’s the same for all prize pools on the network. The Draw Percentage Rate is 1.66%.

### Eliminating the Network TVL Variable

If we explicitly set the Draw Percentage Rate, then we can calculate Chance without Network TVL.

Let’s solve for Chance with the above Expected Value equation:

Expected Value = Chance * Total Prize
Chance = Expected Value / Total Prize

We can substitute Expected Value with another formula: the Percentage Rate. Let’s solve for Expected Value with the Percentage Rate equation:

Percentage Rate = Expected Value / Prize Pool TVL
Expected Value = Percentage Rate * Prize Pool TVL

Now let’s substitute the EV equation into the Chance derivation above:

Chance = (Percentage Rate * Prize Pool TVL) / Total Prize

Great! We’ve eliminated the Network TVL variable. Let’s try it out:

• Pool A Chance = (0.0166 * 10,000) / 1000 = 0.166
• Pool B Chance = (0.0166 * 20,000) / 1000 = 0.333
• Pool C Chance = (0.0166 * 30,000) / 1000 = 0.5

Fantastic! If we explicitly set a DPR for each pool, then we no longer need to rely on knowing the Network TVL. We just need to make sure the DPR is the same for all prize pools across the network.

# Draw Percentage Rate in Action

Now that we’ve defined the DPR and can derive chance from it, we can have arbitrary prize distributions!

## Example Prize Distribution

DPR: 0.02%
TVL: \$10m

Prize Distribution:

Prize Est. Count
\$100,000 1
\$8,333 12
\$2,083 48
\$521 192
\$130 768
\$33 3072
\$8 12288
\$2 49152
\$1 196608

Chance = (Percentage Rate * Prize Pool TVL) / Total Prize
Chance = (0.0002 * 10,000,000) / 1,000,000 = 0.002

This means that the prize pool should only have 0.2% of the probability space for the \$1,000,000 in prizes. Assuming a daily draw, that means we’d get:

Prize Est. Daily Count Est. Yearly Count
\$100,000 0.0020 0.7300
\$8,333 0.0240 8.7600
\$2,083 0.0960 35.0400
\$521 0.3840 140.1600
\$130 1.5360 560.6400
\$33 6.1440 2242.5600
\$8 24.5760 8970.2400
\$2 98.3040 35880.9600
\$1 393.2160 143523.8400

Now we can have arbitrary prize distributions! You can see that the \$100,000 prize will occur every year and a quarter, or so, on average.

# Summary

Introducing a Draw Percentage Rate will allow us to:

• Have arbitrary prize distributions
• Have prizes that occur less frequent than daily
• Eliminate Governance acting as an oracle
• Show the EV for a prize pool as a simple DPR %

# Next Steps

The PT Inc. team is planning on developing this code along with additional improvements as part of a push to simplify the protocol. We will require:

• PT auditing resources.
• Governance to install the new contracts when they are ready.

12 Likes

Love the idea and nicely put and explained. As we all know big headlines have the possibility to attract more people. I of course will fully support the funding for audit.

I guess that the DPR% could be modified by governance?

What I also do not currently understand is how are these modifications introduced on top of the current smart contracts. Are original smart contracts modified or is this an additional feature built on top of it?

4 Likes

How do the changes achieve this?
It seems like we’re just shifting from governance pushing a daily network TVL to governance pushing a DPR once in a while. Governance is still acting as an oracle. Even though it is operating with much simpler data.

4 Likes

Yes, exactly. I envision it’s a parameter set explicitly by governance, just like the prize distribution itself.

Governance just needs to set the DPR to be the same across pools on the network. Or perhaps not- if one yields much better or worse than others. I’d imagine we’d eventually have a spread between DPR and yield APR as a buffer.

We’d just swap out the PrizeDistributionFactory for a new one based on the DPR.

It’s shifting from a being an oracle to a set-and-forget control.

An oracle pushes external data on-chain; in this case TVL from prize pools on other chains. This data needs to be pushed frequently and verified.

A control is something Governance can set to whatever it wants, and is done only so often as needed. It’s much safer!

4 Likes

I’m very excited for this and thank you for the quite comprehensible post So, if I understand correctly governance will no longer need to keep track of TVL, but now instead it’s the yield percentage in order to set the DPR. Meaning that if Aave suddenly drops it’s yield from 4% to 1%, governance would need to quickly adjust the DPR in order to maintain prize liquidity, am I correct?

Would this prevent us from using more “variable” yield sources? (For example one that quickly ranges from 5 to 10% APR)

7 Likes

This modification brings more autonomy and efficiency to the distribution of prizes, I see it as a great evolution, I love the idea, it was supported %100.

5 Likes

Thanks for this clear writeup. I like how this enables prizes to be less frequent than once per day. I also like how it allows us to have chain-specific tiering. I think those are two of the most requested updates for V4. While not as highlighted, I also picked up on this enabling us to use different yield sources per chain. This may not be immediately put to use, but I can see how it’s a great thing to have in our toolbox.

The modular design of the code, allowing us to swap out the PrizeDistributionFactory, shows the power and flexibility of V4.

So yeah, I only have a fan post. Thanks @Brendan

6 Likes

This seems like a major improvement! Has my vote!

2 Likes

in Est. Yearly Count they used the wrong formula.
If I play ten times a lottery with a P(X)=10% , it doesn’t mean I’ll win the 10th time. I need to use the binomial probability to calculate my chance of winning at the n-th time

1 Like

This sounds interesting- could you elaborate?

We could boil down the question to this:

In a six-sided die, how many times (on average) will “2” be rolled over 365 rolls?

1 Like

Basically the probability you wrote in that column results higher than the actual probability calculated with the binomial distribution.
Mind that this error can affect also other parts of the project related to probability and funds, in ways I can’t tell you in advance.

The average of the question makes you ask, formally, the E(X), the expected value
You can use this one instead Binomial Random Variable Expected Value Calculator - Analytics Calculators
But you asked something that they generally say in betting games that belong to the monopoly. So you have to weight the outcome, E(X), for the prizes (minus the cost of entry, almost zero in our case).

1 Like

let me clarify further: E(X) doesn’t give a probability but a measure.
I probably misread where you wrote “count”

1 Like