$PHOTON token design

[Giuseppe Natale]

I think it's worth discussing more in depth how the $PHOTON token system would work in practice. For now, let's leave out the issue of how these design choices would map in the context of offering the same "liquid staking" for the Cosmos Hub as an external liquid staking provider. I wanted to focus the attention on the section https://github.com/atomone-hub/genesis#phatom1-the-more-deflationary-version-of-atom1

Also for the record, I will refer to $PHOTON here even though the document talks about $phATOM1 (and sometimes interchangeably also $phATOM), but it's meant to be the same thing. Btw I kind of like the idea of getting away from the prefixTOKEN convention for this experiment - hence why I am using just $PHOTON - I am advocating for removing this explicit link in the name. In the end, we are trying to create a token backed by $ATOM1 but that can have it's own independent existence. But I am digressing.

1. $PHOTONs give in general no governance rights
   1a. $PHOTON holders can have governance voting power for certain specific proposals, related to $PHOTON itself (e.g. raising the tax cap). Interesting, but complicated to achieve fairly without $PHOTON token-locks (cause e.g. I could vote with a flash-loan otherwise). More clarity around how $PHOTON holders could be allowed to vote is required

2. underlying $ATOM1s are auto-staked proportionally to existing voting power. Would be interesting to understand what would be the minimal changes required to attain this without a need for constant rebalancing whenever VP distribution shifts (if at all possible). And would this rebalancing consist of regular re-delegations, subject to re-delegation slashing rules? I also think figuring this out is important to minimize the Principal-Agent problem: https://eprint.iacr.org/2023/605. See also my reply in #13 (comment)

3. a 10%-capped tax is deducted similarly to a validator commission (this cap can increase as specified in the section) on the auto-staked underlying $ATOM1s non-$ATOM1 rewards (see #41 (comment)). Aside from that, no other tax is applied, and underlying $ATOM1s are auto-compounded so that the percentage share of $ATOM1s bonded through $PHOTON over the total $ATOM1s supply can only decrease due to slashing events. How is this tax set? fixed number through governance? dynamic? Is validator commission bypassed?

4. $PHOTON only accrues $ATOM1s rewards, other non-$ATOM1s rewards are forfeited (this is actually not the case: see #41 (comment))

5. The $ATOM1s bonded toward auto-staking do not count toward calculating the bonding ratio target of 2/3 in either the numerator or denominator.

6. A total of 1 Billion $PHOTON are only allowed to exist, the invariant being that if all the $ATOM1 in circulation would be converted to $PHOTON, it would be for at most 1B $PHOTONs and never more.
   In classic liquid staking derivatives, the conversion formulae are, as for example shown here:

   • when bonding x $ATOM1 tokens to mint y $PHOTON liquid staking tokens, y = x * y_t/x_b where x_b is the amount of tokens already bonded through liquid staking and y_t the total issued liquid staking tokens currently in circulation. Initially, when y_t = 0, the conversion x to y is 1:1.
   • when burning y $PHOTON liquid staking tokens to unbond x $ATOM1 tokens, x = y * x_b/y_t, where x_b and y_t are the same as above. This second formula I assume would not change even in our case. The redemption $PHOTON to $ATOM1 should rely on the actual $ATOM1s available. Where we want to probably make a change is in the formula to convert from $ATOM1 to $PHOTON

   If we want to add the 1B max (noted as y_max) $PHOTON invariant, a simple approach might be to use the percentage share of the x $ATOM1 that gets bonded over the total x_t $ATOM1 supply. We would introduce a "virtual" conversion rate that could equate to:

   C = (y_max - y_t) / (x_t - x_b)

   Using the same notation as above. Therefore whenever someone bonds x $ATOM1s for y $PHOTON the conversion would happen as:

   y = x * C

   while the redemption of x $ATOM1s from y $PHOTON would follow the formula:

   x = y * x_b / y_t

   Considerations:

   • If the ratio of x_b/x_t increases (because staking reward > inflation), there is an incentive to bond more $ATOM1s to get $PHOTON as you "steal" some of the $ATOM1s from the $PHOTON-bonded "pool", up to equalizing with the inflation rate (you decrease the redemption rate because you "dilute" the existing $PHOTONs, but redemption rate still remains higher or equal than the conversion rate). It is also true however that the amount of arbitrage that can be done is actually limited by the $PHOTON to $ATOM1 redemption mechanism (which is essentially supposed to be rate-limited from my understanding). In the end, if you care about getting the true staking reward rate, you should stake $ATOM1s yourself and not bond to get $PHOTONs. The guarantee $PHOTON gives you is only that you will not be taxed through inflation.

   • when a slashing event occurs, the proportion of $PHOTON-bonded $ATOM1s over the total $ATOM1s supply x_b/x_t diminishes, since in proportion the $PHOTON-bonded $ATOM1s x_b decreased more than the total $ATOM1s supply x_t due to the total $ATOM1s staked being less than 100% (in the case of 100% $ATOM1s bonded it would decrease equally in proportion and the ratio would not be affected). The mere fact that there are less x_b causes the redemption rate to go down, which in case it goes below the conversion rate (or rather it's inverse) would disincentivize bonding more $ATOM1s for $PHOTONs as you will immediately incur in a loss of $ATOM1s when depositing, while everyone else's $PHOTONs will increase their redemption power. However, assuming the protocol works as intended, since the growth rate of x_b is faster than x_t the redemption rate will eventually recover. The case in which this is not true is either if bond ratio of $ATOM1 is 100% or if the protocol constantly slashes validators. Both cases are impractical and the second one in particular would already disincentivize by itself $PHOTON bonding, so conversion/redemption dynamics would only exacerbate this (disincentivize $PHOTON bonding more), not be the cause by themselves. And maybe this is fine.
     The opportunity cost of not bonding your $ATOM1s to $PHOTON right now and wait instead is marginal. It could even actually be that conversion rate after a slash event is still lower than redemption rate. Actually, this is expected in most cases.

7. We have to define how redemption works in practice. What about re-using some of the ideas in https://github.com/tendermint/atom_one/tree/c0f7d935930fedb700866c079a7056729e87d899#article-3c-the-photon-token ?

I'd love feedback, especially on point 6 (I am open to the possiblity that all I did there was completely flawed 😂). And in general to explore more in depth the dynamics of the dual-token model.

[Pipello]

A total of 1 Billion $PHOTON are only allowed to exist

Q: Could this hard limit of 1B be changed through governance? Not sure what would be the use case, I am curious where the 1B number comes from, is it arbitrary number?

other non-$ATOM1s rewards are forfeited

Q: for example ICS rewards right?

[Giuseppe Natale]

Q: Could this hard limit of 1B be changed through governance? Not sure what would be the use case, I am curious where the 1B number comes from, is it arbitrary number?

It's an arbitrary number, but can never be changed. It's a hard cap, in perpetuity. With "lost coins" this will also eventually become deflationary in practice.
But it's also true that 21 (millions) is half of 42. So everything's arbitrary innit.

Q: for example ICS rewards right?

yes, this is also what jae states (except maybe missing a "neither") but since there is a "nor" I assume - and it makes sense to me - that they are forfeited yes.

the AtomOne hub offers a trade that makes $phATOM deflationary: non-atom rewards nor taxes are applied to auto-staked $ATOM1 bonded $phATOM holders, and with the right conversion equation (which adjusts for $ATOM1 inflation) we can construct a perfectly fixed $phATOM supply (say of 1 billion $phATOMs) no matter how many $ATOM1s bond to $phATOMs.

$PHOTON becomes a way to avoid the inflation tax. But you forfeit non-$ATOM1 rewards and governance rights, and there’s still the risk of slashing, plus you are not guaranteed any reward more than the guarantee of not getting diluted (but you can and probably will get more)

[0xFDg]

About point 6 ther're problems.

If we use C = (y_max - y_t) / (x_t - x_b) , when C>0 ?
(y_max - y_t)>0 is always true , the same is for (x_t - x_b) because y_max >y_t in all condition, except for y_max=y_t. The same for the other cases.

The problem is when we would like C = 1.
For obtain C=1 signify that: (y_max - y_t) = (x_t - x_b)
First problem, we will never have this condition for obvious reasons (x_t <y_max into the initial fase ) , and this is true in particular if y_t < x_b .
In other word, C will never be equal to 1 whit condition similar to the actual condition in real life.
Taking a real value about Strider and ATOM :

ATOM = 292586163;
stATOM = 3307416  % with condition that stATOM<ATOMbond for mint stATOM itself
C = (1000000000 - 3307416)/(292586163 - 3307416+1) = 3.4454

The minimum value of C in this condition is 3.4454 and in semistationary system condition the C value can only increase.

Probably we must think another approach if we desire to set a maximum value for phATOM1.

[Giuseppe Natale]

C is not supposed to be 1. For it to be 1 it would mean that somehow 1$ATOM1 gives you 1$PHOTON, and it actually doesn't matter.
C is just a "virtual" conversion rate, I haven't thought about its bounds. Why would they matter?

C is supposed to float and diminish over time, but so is x_b / y_t supposed to grow in the other way, except in the case of slashes.
This is inevitable (for C) since $ATOM1 supply increases exponentially.

Think about stATOM on stride. The conversion rate now around 1.27 will grow indefinitely, unless slashes occur.

EDIT: To further clarify, there is no inherent constraint of C being 1. This would only mean that whenever you bond 1$ATOM1 you get 1$PHOTON, and this will happen in practice (eventually, as $ATOM1 supply grows and equates 1B), but it's somewhat irrelevant. Or I am missing something or misunderstood your comment

[0xFDg]

I understand, I was just testing myself to understand the limits of the formulation you proposed, I am fascinated by the mathematical abstraction of a target, C=1 was just to evaluate the boundary condition of C and under this condition the conversion rate, from my analysis (if it is correct), is out of bounds to define an LST.
I am happy to help and will see if I can come up with some ideas these days. I am afraid that if we don't engineer every little aspect of these algorithms someone may attack the pools or legitimately steal the funds.

But, ther's another aspect to discuss, about :

2. the Voting Power, ther's a problem. If we legittimate Decentralist we will have :

• Decentralist : high importance in voting
• ATOM1 stakers : low importance in voting
• phATOM1 : low importance in voting

Maybe we have to restructure the voting power , 2 class on 3 will not have voting power. For me phATOM1 are like a Government bond, is it fair to let bond buyers choose what a nation should do ?

[Giuseppe Natale]

Decentralist : high importance in voting
ATOM1 stakers : low importance in voting
phATOM1 : low importance in voting

phATOM1 would not get voting rights except for matters related to the token itself (see point 1a and jae's discussion in the related paragraph in the genesis readme) but the details of that are to be figured out. $PHOTON is again only a "deflationary" view of $ATOM1 that allows you to avoid the inflation tax. With it being liquid, we cannot allow $PHOTON token holders to have voting rights or a governance takeover is always a threat.

Aside from that, I see no reason for making a hierarchy such as the one you propose. No higher entity with more voting power. 1 $ATOM1 is 1 vote as it is now. Alternatives could and should be explored on how to also reform governance, but it's outside the scope of this discussion, see #40 and #7
Decentralists is supposed to not have any authority over AtomOne. AtomOne is in the hands of its stakers, as for any Cosmos blockchain (supposedly).

[Giuseppe Natale]

C=1 was just to evaluate the boundary condition of C and under this condition the conversion rate, from my analysis (if it is correct), is out of bounds to define an LST.

$PHOTON is not really meant to be an LST. That's the key. It's different. With an LST you have no guarantees of finite supply of the LST either, in the same way you have no fixed supply of the underlying. You only know that if everything goes well, the LST will give you more underlying over time, and hence its supply should grow at a lower rate.
Here, we are trying to bound the supply of $PHOTON, because it's not meant to be an actual LST, but a "view" of $ATOM1 that rids itself of the exponential inflation.

Of course, this implies trade-offs, because only the "classic" LST formulae imply "fairness" in the conversion rate. Here instead, since redeeming $ATOM1s from $PHOTON is intentionally rate-limited, the idea is to create an independent token that is backed by $ATOM1 but it's in fixed supply, not an LST where there is arbitrage between the market and the protocol exchange rates.

From https://github.com/tendermint/atom_one/tree/c0f7d935930fedb700866c079a7056729e87d899#about-security-and-the-need-for-atomphoton-separation

Once there are ATOMs and PHOTONs, and the hub finds good ways to incentive PHOTON usage, we will end up promoting PHOTON more than ATOMs, and the market cap of PHOTON should theoretically eclipse that of the market cap of ATOM. There’s much more money in circulation than the market cap of VISA/IBM/FED combined.

[Jae Kwon]

I'm going to start updating this comment here as I read.
(in case I repeat something already discussed I will delete it)

Interesting, but complicated to achieve fairly without $PHOTON token-locks (cause e.g. I could vote with a flash-loan otherwise). More clarity around how $PHOTON holders could be allowed to vote is required

Interesting, the tragedy of the commons problem and everyone is tempted to lend their $PHOTON unsuspecting a hostile vote to increase taxes.

Bonding $PHOTON again (beyond $ATOM1 to $PHOTON bonding) could help but without a long term bond, and with an open set (from all $PHOTON holders) the loan attack still works on the scale of months, though if the unbonding period was long enough like 10 years (!!) maybe this could work to align incentives and prevent flash loans from ever making a profit. Now we're maybe talking about 5 year, 10 year, 20 year bond notes that have voting power.

Bonding with weight given to (bond_time x bond_amount) is dangerous because a small set can take over governance in the long run. But capping min(bond_time, X years) x bond_amount or having some function with a curve that flattens out over time might work. This could help temper the vote of new bonders, and makes an attack take longer to initiate even if they were ready to take the hit during the unbonding period.

underlying $ATOM1s are auto-staked proportionally to existing voting power. Would be interesting to understand what would be the minimal changes required to attain this without a need for constant rebalancing whenever VP distribution shifts (if at all possible). And would this rebalancing consist of regular re-delegations, subject to re-delegation slashing rules?

No, it should be possible to implement this without needing to do actual re-delegations, but just managing a special pool of "shares". The pool would have its accumulated slash adjusted everytime somebody else gets slashed, or something like that. And this pool would not be used for calculating bond ratio, etc.

a 10%-capped tax is deducted similarly to a validator commission (this cap can increase as specified in the section) on the auto-staked underlying $ATOM1s. Aside from that, no other tax is applied, and underlying $ATOM1s are auto-compounded so that the percentage share of $ATOM1s bonded through $PHOTON over the total $ATOM1s supply can only decrease due to slashing events. How is this tax set? fixed number through governance? dynamic? Is validator commission bypassed?

I think I forgot to write that $ATOM1 inflation SHOULD NOT be taxed for $PHOTON holders, because while it makes sense to tax $ATOM1 inflation for bootstrapping purposes, the $PHOTON is better when it is more deflationary, and a 10% tax of inflationary $ATOM1 to $PHOTON would mean that if the annual compounded inflation rate is 10% or 20%, then annually 0.91% or 1.67% of underlying $ATOM1 is being transferred to $ATOM1 stakers from $PHOTON holders. But the tax need only apply to non-$ATOM1 "real" income from tx fees.

Also, I'm not sure 10% is the right cap either. Arguably, isn't it sufficient that the $PHOTON token be merely deflationary $ATOM1? Not really, because then people will seek out liquid staking services. AtomOne could try to ban those, but that's not the cat & mouse game we want to play if we can avoid it, and, I don't think we can ban them if we want to support partyhubs. That's why I set the cap at 10%, but maybe the maximum bound acceptable is the highest % tax that would prevent unwanted liquid staking services. If we could ban unwanted liquid staking entirely, and I think we can, arguably we can have a very high tax rate, and even consider 100%, but it makes more sense to have something less than 100%, or rather to frame this as a reward.

Can we support officially sanctioned services like $PHOTON AND support partyhubs WITHOUT enabling "liquid staking" e.g. by banning all other interchain account staking? If the partyhubs get the full staking rewards, then people will just make a PHOTON "partyhub".

NOTE: if the inflationary tax on $ATOM1 did apply to $PHOTON, in the long run, the rewards of the tx fees will favor the $ATOM1 stakers... interesting...

Maybe the right question is, what SHOULD we be doing?

If too much of the tx fees go to $PHOTON holders and not enough to $ATOM1 validators, will the network become insecure? Some validators will self-stake, others will not as much. Nevertheless since we need to provide minimum income for all validators equally, any self-staking should be extra and not needed for continuous safe operation. Arguably validators could rely also on self-delegation for ongoing operations, but unless the UBI is sufficient we are risking insecure validators. Also note, we should require that the UBI should be used strictly for infrastructure costs with minimal expectations.

From where does the validator UBI come from? Taxing from the whole revenue stream of tx fees. If we tax the $PHOTON holders too much they will just seek out "liquid staking" or join a shell partyhub, but all blockchains require security so there is no undue pressure to keep this tax low. What matters is that users get the expected value from the cost of security. Even if the validator tax is high, it could be worth it.

Is 10% enough? Is it too high? e.g. see mintscan.io,but it doesn't show the full picture. In some sense it is really low, because in Bitcoin some might say that 100% of the mining rewards and tx fees go to the miner, but we need to weigh this against the expenditures especially electricity and hardware. Theoretically the return on investment tends to go to zero if the market is perfectly efficient. What other comparables are there?

A total of 1 Billion $PHOTON are only allowed to exist,

That was from the previous prop82 days, but according to everything we discussed above (and the earlier portions of the README) it could be lower after staker slashing (if the exchange rate from $ATOM1 -> $PHOTON didn't change before and after the slashing event). And if we end up taxing $ATOM1 inflation to $PHOTON this is like a continuous slight tax on underlying $ATOM1 of $PHOTON and implies yet another exponentially inflating token, albiet with slow inflation. And if you buy the rough consensus of central bankers, maybe 2% a year isn't that bad. Haha, just kidding.

thinking...

[Giuseppe Natale]

Interesting, the tragedy of the commons problem and everyone is tempted to lend their $PHOTON unsuspecting a hostile vote to increase taxes.

Optimism allows for token-determined VP to vote on governance without lockups. Maybe worth looking into.

In general, if we "snapshot" the current $PHOTON holders at the time of prop submission maybe that could limit who can vote. But that would also cripple the system a bit. Plus what about PHOTON existing elsewhere via IBC (maybe they can't vote and that's it?) - EDIT: nah, this seems too contrived.

Bonding with weight given to (bond_time x bond_amount) is dangerous because a small set can take over governance in the long run. But capping min(bond_time, X years) x bond_amount or having some function with a curve that flattens out over time might work. This could help temper the vote of new bonders, and makes an attack take longer to initiate even if they were ready to take the hit during the unbonding period.

Maybe you don't even need to bond, just to hold. You accumulate VP the more you hold without moving your tokens. This VP is reduced proportionally when you move out tokens, up to becoming 0 when you transfer them all. VP is not transferred alongside tokens. You always start from 0 whenever you receive $PHOTONS.

No, it should be possible to implement this without needing to do actual re-delegations, but just managing a special pool of "shares". The pool would have its accumulated slash adjusted everytime somebody else gets slashed, or something like that. And this pool would not be used for calculating bond ratio, etc.

That is my feeling as well.

Also, I'm not sure 10% is the right cap either. Arguably, isn't it sufficient that the $PHOTON token be merely deflationary $ATOM1? Not really, because then people will seek out liquid staking services.

I think it's sufficient actually. Especially if my considerations around the conversion formula hold. we haven't seen liquid staking play out in environments where tx fees exceed inflation. I think if we just design the mechanism so that we simply guarantee no inflation tax that is sufficient. If you want the benefits of the protocol, you stake $ATOM1, if you want to preserve your ownership percentage while remaining liquid so to speak, you use $PHOTON.

A tax on fees and excess on inflation is something I would endorse, this is also the same as other LS providers, and it can be up to 100% yes.

Can we support officially sanctioned services like $PHOTON AND support partyhubs WITHOUT enabling "liquid staking" e.g. by banning all other interchain account staking? If the partyhubs get the full staking rewards, then people will just make a PHOTON "partyhub".

staking through interchain account should be prevented. Bonding for $PHOTONs through ICA why not. But Yeah I would ban other liquid staking protocols. I don't see liquid staking as a positive thing, and never saw it. If we disable interchain staking, the way alternative liquid staking would be implemented would be very clunky and I doubt anyone in their right mind would use those en masse.

[0xFDg]

Okay, if I understand you correctly, we are trying to fight ATOM through the features it has repudiated, inflation, using the mirror mechanism of ATOM1-PHOTON inflation. I reformulated your formula from another point of view.

Considering ATOM1 airdrop 3/2 to actual ATOM supply ATOM1 = 438879244.5
Considering PHOTON_max = 1000000000
Considering inflation rate at 20% for 15y and 2/3 ATOM1 in stake we reach ATOM1_6.7y = PHOTON_max after t = 6.74 years using Compound interest formula f = [x*(1+r).^t].
Using C = (PHOTON_max - y_t) / (ATOM1_5.7y - x_b)
Ideal value of y_t = 7534917.38989109 (using the actual stATOM supply normalize to ATOM1 genesis supply, ideal data)
Ideal value of x_b = y_t+1;

The C value will follow this curve starting from t = 6.74 considering to ideal cumulative Compound interest from x_b on y_t :

It means we have to use a dynamic C rate adjustment where if it is ATOM1<PHOTON_max we have to set a different ratio, perhaps a modified formula of y = x * y_t/x_b for the first ideal t = 6.74 years, after we can use C = (y_max - y_t) / (x_t - x_b).

All data are based on Compound interest; I hope the analysis can help

[Jae Kwon]

the AtomOne hub offers a trade that makes $phATOM deflationary: non-atom rewards nor taxes are applied to auto-staked $ATOM1 bonded $phATOM holders, and with the right conversion equation (which adjusts for $ATOM1 inflation) we can construct a perfectly fixed $phATOM supply (say of 1 billion $phATOMs) no matter how many $ATOM1s bond to $phATOMs.

$PHOTON becomes a way to avoid the inflation tax. But you forfeit non-$ATOM1 rewards and governance rights, and there’s still the risk of slashing, plus you are not guaranteed any reward more than the guarantee of not getting diluted (but you can and probably will get more)

The README.md has a conflict so this is probably causing confusion.

According to what I wrote in the comments above, this "trade" doesn't work because some portion of the non-atom rewards SHOULD be applied to $phATOM holders. In fact I proposed most of it, or 90%, because of the max 10% tax applied to $phATOM. But the non-deflationary aspect remains the same.

I am going to reword it to:

$phATOM. In order to incentivize the usage of $phATOM, the AtomOne hub offers a
trade that makes $phATOM deflationary: non-atom rewards are taxed with an immutable cap, but inflated atoms are not for $ATOM1 bonded $phATOM holders, and with the right conversion

[Giuseppe Natale]

that makes sense.
I'll edit the first post.

[Jae Kwon]

we haven't seen liquid staking play out in environments where tx fees exceed inflation

We need to design the constitution with this in mind; it must work from bootstrapping (where your assertion is true) all the way to scale, and it should even be able to withstand economic shocks (less txs).

[Jae Kwon]

2. If we legittimate Decentralist we will have :

We won't, except in a restricted form. AtomOne is strictly owned by the $ATOM1 stakers, and probably not at all the $PHOTON holders either, except to the degree that $PHOTON can have their own governance within a well defined (restricted) domain.

[Giuseppe Natale]

@0xFDg the curve you show for C is somewhat expected. C has at the numerator a "fixed" quantity and at the denominator an exponentially increasing quantity. So it exhibits the behavior of 1/x^n

But nonetheless, I appreciate the numeric experiments.

[Jae Kwon]

@giunatale * This second formula I assume would not change even in our case.

It's the other way around because going from PHOTON back to ATOM1 is potentially dangerous to governance.
The README has some of this but it isn't yet decided. See this section:

• Widen the gap in bidirectional conversion price between $phATOM and $ATOM1.
• Limit the amount of $ATOM1 that can be released per time period auction.
• Essentially the same as above with some conversion curve.

Widening the gap is interesting, the point is to create a separation between the ATOM1 and PHOTON tokens over time, and it only works if there is a use case for PHOTON (e.g. it is the only fee token required to be supported in all shards). The gap makes round trip conversion more and more expensive, but there would still be an efficient market price, and this market price will fluctuate more or less between the min and max bounds set by the gap (otherwise you could get a better price from PHOTON bonding or unbonding). I can see this being beneficial to detach the market fluctuation forces of PHOTON from ATOM1.

If the demand for PHOTON goes up, should the price of ATOM1 go up correspondingly? It shouldn't have to necessarily. Otherwise, with the rise in demand for PHOTON we would be creating an incentive for people to buy ATOM1 just to acquire more PHOTON. While this might sound good for ATOM1, it is the root cause of the hostile takeover problem because a lot more ATOM1 would be (indirectly) held by those who haven't been as active in voting. The more ATOM1 is bonded to PHOTON, the harder it is to prevent a hostile takeover attack. With the gap you can have a wildly successful PHOTON without having to worry about this problem.

One might ask, why not just have a one time auction or ethereum-fundraiser-style system for ATOM1->PHOTON (where PHOTON isn't backed by ATOM1, and ATOM1 is only a means to acquire/buy/bid for PHOTON)? It was pitched on the hub, but since the hub didn't have a constitution to enforce anything about it to give it utility, so the community generally rejected the proposal for this type of PHOTON. Whereas with this $phATOM1 type of PHOTON backed by ATOM1, you can get most of your ATOM1 back in the early stages.

I'm not really happy with this slash-creates-gap mechanism because, well, there's really no sense in the timing of the gap except that it enables the gap so I put it in the README as a feeler, but I will make a PR to edit it. It probably makes more sense to introduce a gap simply on a schedule. So year over year the amount of ATOM1 you can get from the PHOTON token can go down exponentially, while the amount of PHOTON you get from ATOM1 stays the same function to make sum(PHOTON) = 1billion (for example).

Do we want the gap though? If instead we can have no gap but charge a small tax on the ATOM1 inflation going to PHOTON holders, then over time the underlying ATOM1 backed by PHOTON would decrease slowly exponentially. But then PHOTON is merely a less inflationary token, not a deflationary one. This is another option.

Let's say that the non-PHOTON validator staked ATOM1 vs the PHOTON bonded ATOM1 was at a ratio of 1:1. Then this is more secure than a 1:10 ratio (unless the throttling mechanism from PHOTON -> ATOM1 was onerous). Maybe a good question to ask is, what should the ratio be? What are the tradeoffs? What are the real life comparables? And then it would be easy enough to cap the gap so to speak to ensure that the ratio doesn't become unbalanced. 1:100 seems very insecure for example. So if the ratio climbs high enough it makes sense for the gap to become higher too if the ATOM1 -> PHOTON demand is still too high despite the premium for this direction as per the gap.

[0xFDg]

I have think about problems and I have some suggestions:

PHOTON back to ATOM1 is potentially dangerous to governance.

1. I think for avoid this problem to delegate ATOM1b (atom arriving from PHOTON) through a party hub which design an algorithm that take a decision giving different weight to each validator based on features, re-delegate dynamically the compound interest of the reward and cut off the validator from the voting power. Idea to better define based on the paper

Principal-Agent problem: https://eprint.iacr.org/2023/605.

1. PHOTON is actually not a fungible token (LST) and it is a kind of store of value that monetizes the trust of ATOM1, then we can use directly a fix value of PHOTON = Smax = 1e+9 and use for swap a formula similar to Loan formula, something like that S = b * (Smax/(b0*((1-g)+r)^t + g)) with 0<g<0.1 design on p slashing ratio value. The sense here are use directly a fix amount of Smax and to allocate a g (% of b0 ATOM1) quantity non in stake for prevent Principal Agent attack, burning it or redistributing it into the pool for rebalance after a slashing attack.

2. But using directly a fixing value of Smax can create an imbalance, we can fix it.

Maybe a good question to ask is, what should the ratio be? What are the tradeoffs? What are the real life comparables? And then it would be easy enough to cap the gap so to speak to ensure that the ratio doesn't become unbalanced. 1:100 seems very insecure for example.

How to set ? simply, we set b0 and s0 value of ATOM1 and PHOTON directly with the airdrop giving maybe a who vote yes a % of PHOTON ,or with other criteria (to set and define better), fixing the starting point ratio. Into a simulation I have test a value of PHOTON equal to 10% of the total supply of ATOM1 and an initial ratio will be 1:30, editable by managing the parameters.

4. I suggest to force mint of PHOTON only from us, disincentivizing the pool ATOM1-PHOTON, ATOM1-X , the less they are the more controllable they are.

I haven't studied it thoroughly yet but perhaps, using this formula I proposed, it would be better to give the ability to mint PHOTON also with other assets besides PHOTON, making it more robust. But now it's just a thought out loud.

[Giuseppe Natale]

It's the other way around because going from PHOTON back to ATOM1 is potentially dangerous to governance.
The README has some of this but it isn't yet decided. See this section:

Yes, I was just saying that ultimately the redemption should use the real $ATOM1s available (or give less even) but we should not make any virtual conversion that implies "minting" of $ATOM1. But then how the redemption works in practice, well that's very interesting to explore. I was assuming that redemption formula for simplicity, cause designing the redemption system so that we create separation and disincentivize arbitrage against the protocol rates is imho key for this thing to work (point 7)

I will read more in depth the rest and reply as soon as I can read more calmly.

[Giuseppe Natale]

@0xFDg

I think for avoid this problem to delegate ATOM1b (atom arriving from PHOTON) through a party hub which design an algorithm that take a decision giving different weight to each validator based on features, re-delegate dynamically the compound interest of the reward and cut off the validator from the voting power. Idea to better define based on the paper

$ATOM1 is proportionally delegated to all validators in the set based on existing VP. See point 2 and jae's reply on how to possibly achieve this efficiently. This is important to mitigate the Principal Agent problem.

What Jae was saying there about "being dangerous to governance" means that if someone acquires a large supply of $PHOTON and redeems the $ATOM1s underlying, they could take over governance if they acquire enough to pass proposals by themselves. And in general this is a threat for hostile takeover.

PHOTON is actually not a fungible token (LST) and it is a kind of store of value that monetizes the trust of ATOM1, then we can use directly a fix value of PHOTON = Smax = 1e+9 and use for swap a formula similar to Loan formula, something like that S = b * (Smax/(b0*((1-g)+r)^t + g)) with 0<g<0.1 design on p slashing ratio value. The sense here are use directly a fix amount of Smax and to allocate a g (% of b0 ATOM1) quantity non in stake for prevent Principal Agent attack, burning it or redistributing it into the pool for rebalance after a slashing attack.

I don't understand that formula and what the terms are, except b0 (the $ATOM1s already bonded?) and what is the rationale behind it. What is r? what is t? is g just = p? also p by itself does not define alone how much capital % is at risk of slashing.
I am not sure I understand what is the rationale.

The Principal Agent problem is not really related, because it's more regarding how "liquid" stake is distributed across validators. We already address that with the auto-stake. The problem we are addressing with the conversion/redemption mechanism is two-fold:

• create $PHOTON and $ATOM1 separation, $PHOTON is backed by $ATOM1 but you can't easily redeem $ATOM1 from $PHOTON. We want to allow people to have a "liquid" version of $ATOM1 that is not subject to inflation tax (or it is just marginally), but we want to get rid or mitigate as much as possible the takeover risk.
• create a deflationary view of $ATOM1 if possible - with a capped max supply of $PHOTON that maybe even decreases over time.

How to set ? simply, we set b0 and s0 value of ATOM1 and PHOTON directly with the airdrop giving maybe a who vote yes a % of PHOTON ,or with other criteria (to set and define better), fixing the starting point ratio. Into a simulation I have test a value of PHOTON equal to 10% of the total supply of ATOM1 and an initial ratio will be 1:30, editable by managing the parameters.

The ratio that matters is $ATOM1 staked regularly / $ATOM1 staked through $PHOTON-bonding. Not between $ATOM1 and $PHOTON in circulation. I hardly think the ratio is 1:30

I suggest to force mint of PHOTON only from us, disincentivizing the pool ATOM1-PHOTON, ATOM1-X , the less they are the more controllable they are.

Governance is the body that decides how this is managed. But the issue is $PHOTON burning (or rather, redemption), not the minting. If we put $PHOTON in a sandbox so that it doesn't affect $ATOM1s staking/governance dynamics much, then that is desireable. That's what we are aiming for actually.

it would be better to give the ability to mint PHOTON also with other assets besides PHOTON, making it more robust. But now it's just a thought out loud.

https://github.com/atomone-hub/genesis#role-as-atom-liquid-staking-provider

XXX Try to make this work with one $phATOM using bonding curves within bounds with all three tokens. This would still rely on imperfect measures like present AMM rate and can lead to manipulation and losses, but you can still maybe restrict these losses by restricting the bounds, say to 2:1 1:2.

This isn't necessarily to exclude. But it comes later. It would be nice - and very interesting to explore - to have one $PHOTON for all liquid staked assets the chain on-boards but it's a problem that deserves its own treatment. Plus I don't understand how your formula helps or is helped by allowing other assets to mint $PHOTON.

[Giuseppe Natale]

@jaekwon

I mainly agree with most of everything written. I want to put emphasis to

unless the throttling mechanism from PHOTON -> ATOM1 was onerous

yes. Imho it should be. I am of the idea that it should be a bid to the lowest amount of $ATOM1s-per-$PHOTON bidders are willing to take per round, with the maximum being more or less the formula I wrote since it uses the real $ATOM1s available. And with the amount of $ATOM1s per auction available as a % determined by the ratio of natively staked $ATOM1 vs the $PHOTON-bonded $ATOM1.
That assuming we have an auction mechanism, maybe a revised mechanism wrt the one you proposed in the atom_one constitution (the link I share at point 7)

If the ratio is largely tilted towards $PHOTON-bonding, we want to tighten the % that can be unbonded from $PHOTON since it impacts more on the smaller amount of $ATOM1s natively staked.
We could make this % dynamic to allow the total $ATOM1s that can be redeemed from $PHOTON be a fixed % of total $ATOM1s natively staked, say max 5% of the total $ATOM1s staked per auction period or something.

It's not really a matter of how many $ATOM1s are bonded through $PHOTON but IMHO more a matter of how many and how fast they can become liquid and then re-staked this time natively for hostile takeover.
Over time an attacker could still slowly accumulate, redeem $PHOTON and natively stake whatever $ATOM1s he can get at that round, but maybe this might make the redemption more and more expensive as the system reacts to the higher interest in $PHOTON->ATOM1 redemptions, and the amount of $ATOM1s at auction might decrease as well.

So if the ratio climbs high enough it makes sense for the gap to become higher too if the ATOM1 -> PHOTON demand is still too high despite the premium for this direction as per the gap.

I think this is the key. The gap shouldn't rely on slashes cause that is impractical, I think it should widen as the demand for PHOTON increases, making as you said the conversion back more onerous.

What are the real life comparables?

The best one I could think of is probably just the same you also have said somewhere else I believe: if $ATOM1 is bitcoin mining hardware, then $PHOTON is Bitcoin. the higher the demand for Bitcoin is the harder is to generally speaking find and buy mining hardware on the market. Moreover, the underlying cost of all mining hardware is in general much less of the total mcap of Bitcoin.

[Jae Kwon]

Reading...

[Jae Kwon]

I am of the idea that it should be a bid to the lowest amount of $ATOM1s-per-$PHOTON bidders are willing to take per round

I like this too. "Curves" as we know it by themselves don't give this throttling ability unless we make a special one that incorporates time. And the longer we can reasonably delay PHOTON -> ATOM unbonding, the more security with have at least with respect to that time.

as the system reacts to the higher interest in $PHOTON -> $ATOM1 redemptions

via the auction mechanism.

And the system can also react to the higher interest in $ATOM1 -> $PHOTON bonding by increasing the gap, which to me mostly means increasing the premium cost of $ATOM1 bonding required to acquire new $PHOTON. These premium $ATOM1 bonded tokens, unlike the base $ATOM1 bonded for $PHOTON, don't have to be redistributed back to the $PHOTON holders (otherwise the effect of this premium could be nullified once enough $ATOM1 is accumulated), unless there was an exponential bonding curve that targets the staked-$ATOM1 to photon-$ATOM1 ratio as we discussed above. The premium could just be burned perhaps?

[Giuseppe Natale]

The premium could just be burned perhaps?

maybe, or maybe go to $ATOM1 stakers.

And/or maybe some of the $PHOTONS from the bids could also be burned if there's overbidding on $PHOTON->$ATOM1 (irrespective of the fact that the bids fill or not) - and the $ATOM1s that aren't allocated due to it being a bid to the lowest offer might also be burned or distributed to $ATOM1 stakers