Process for: RFC --> TC --> GP

What are your thoughts on including lent and borrowed positions in the proposed voting model - is this an intended feature or a potential oversight?

In this model, the lender retains a claim on the same XRD / LSULP that the borrower has taken possession of. If both positions are considered voting-eligible, more votes can exist than issued XRD / LSULP. Rehypothecation can amplify this effect further.

This is not to say that a similar dynamic could not apply to LSU as well, as a market could potentially develop for it, but this appears less likely in practice.

Could this introduce dynamics where voting power is not always aligned with XRD price increasing?

As long as free floating XRD is eligible for voting, most ancillary markets will not materialize, I believe, given they introduce complexity and locks in liquidity, including staking LSUs.

But, as you stated, if there’s a way to game the system, it will be done.

Rehypothecation complexifies things a great deal, as you’ll need to fully account all of it in the proper and accurate way - a huge task, it seems, specially if it’s not immediately clear that the asset in question is of such type and actively used for gaming the system.

if by chance there’s a system that misses the potential double accounting, than it can immediately be coupled with and amplified immensely - nobody will notice if you do it with a few K XRD … but a few M XRD can sway a vote in a significant way.

To compound on the risk, since we’re mostly agreed on using snapshots anyways … they can all be immediately dissolved and unwind back to liquidity as soon as they’re captured, making it even more insidious and difficult to track, I sus.

Also unclear to whom the voting power should be attributed too, in such cases, as both ends of the deal are, in principle, aligned with XRD price by locking liquidity into longer term instruments? I honestly don’t see this to be a linear or simple decision.

Where there’s a will, there’s a way and I personally don’t have a doubt that if possible to game it, someone will craft a business out of selling voting power - and I sus that XRD’s price movements will be less of a concern for anyone involved in such endevours.

For now, it seems the best risk management strategy might be to hold the horde of displeasured community members and stick with only the basics? :sweat_smile:

Anyways, I know you want Octo’s view, not mine, but I couldn’t help myself in dropping this comment, as I have been fighting this for quite sometime inside my head and can’t shake the intuition that there’s already enough in place to build such a system :sweat_smile:

If you want to include DeFi, I think borrowed XRD should count and lent XRD should not. This will avoid any double counting.

2 Likes

Yes, that prevents double counting. But why should we include borrowed positions rather than lending positions?

Lending XRD typically preserves long-term economic exposure to XRD, borrowing XRD is typically driven by a utilization need (e.g. collateralization, short selling, or acquiring voting power). While borrowing may be neutral in some cases, it can also be negatively aligned with XRD price appreciation — for example, when borrowed XRD is used to take a short position.

If that principle is applied consistently, what about DEX pool positions? LPs could be viewed as providing an interest-free loan to the pool, while retaining a claim on the pool’s assets, similar in nature to a lending position. Would these positions be excluded under the same logic?

Given these cases, I would argue that, for now, we should perhaps stick to LSU only. Decisions like this should be built carefully from first principles, as you have advocated, with a solid rationale that would survive scrutiny from an external observer. The approach taken here sends a signal about our credibility.

More broadly, I think this discussion points to a bigger question: how should rights embedded in assets be handled? Radix positions itself as asset-oriented and ready for modern finance, yet the engine today appears to model assets primarily as things, rather than as claims that carry intrinsic rights and issuer obligations. Is there room to have a broader debate on this first?

Capital market assets (equities and bonds) are fundamentally claims on issuers and come with rights. An equity holder, for example, has an entitlement to dividends and a right to vote at an AGM. In an asset-oriented model with accounts, resources, and components, should the onus really be on the issuer to trace through every application and component to identify the entitled owner at the relevant record or snapshot date?

If not, should we consider whether this can be handled more elegantly at the protocol level — i.e. revisiting what it means to be an ā€œassetā€ in Radix Engine / Scrypto? For example, and for illustration purposes:

Should there be a rights manager alongside the resource manager?

Should rights be represented by a separate token linked to the primary asset?

Should rights always travel with the asset, or should they be separable?

Should rights be optionally non-transferable when an asset is lent out?

If we explore solving this harder problem directly, we may arrive at a more natural foundation for governance and other entitlement-based mechanisms at the protocol level, rather than inferring rights indirectly from balances and DeFi positions. The conclusion may ultimately be that modelling assets as things at the protocol layer is optimal, and that assets as claims belong at the application layer. However, if we reach a conclusion that assets as claims could belong at protocol level, this could really strengthen Radix’s positioning as a true global asset layer. The direction taken here could also potentially have implications for how scalability is achieved in a practical sense.

2 Likes

No - thanks for responding. I think this is an important issue to discuss and one where it’s worth trying to arrive at a consistent and defensible position. It’s good that Octo put this out there. Maybe you are interested in my follow up reply to him.

It’s rather simple: other way around is not feasible.

If an account ā€œownsā€ 100 XRD, there is no way of knowing it’s not borrowed. If you count lended XRD, and not borrowed XRD, a construction like this could exist:

Account A lends 100 XRD (has 100 vote power),
Account B borrows 100 XRD (and has 0 or -100 vote power, whatever you prefer) and sends them to Account C. Account C looks as though it has 100 XRD (and has 100 vote power).

Now, the Account A lended XRD is double counted.

The only option, if you want to avoid double counting, is to give voting power to the person that owns the XRD.

If you want to be completely accurate, you can take the utilization rate into account as well. For instance, when the utilization rate of an XRD borrow/lend pool is 30%, you can still count 70% of a user’s lended XRD towards their vote power without any double counting.

As for your point about if this would be a relevant discussion for DEX LP as well, I wouldn’t say so. Borrow/lend is different from normal DEX LP, since the issue here is that 1 XRD can be both borrowed and lended. 1 XRD put into an AMM only has 1 owner, so no risk of double counting.


To be honest. The more I think about including DeFi positions in voting power, the more difficult it becomes. I’d say starting with just voting with XRD and LSUs would be easiest. I don’t think things need to be perfect from the start.

2 Likes

yes, understood. So I would say we are coming at it from different perspectives - you are looking at it from what is technically achievable to include and have no double counting, I am more coming at it to ensure there is a consistent principal applied in terms of what is included in any voting power.

1 Like

Yea - sorry for not engaging with your angle - it’s a good thing to look at, but I’d need to think some more about it before I can form a coherent thought :sweat_smile:

I’d be of the opinion that we first get initial governance in place, with just XRD/LSUs, and then we can think about added complexity.

2 Likes

yes, sure start easy is a way better