Proposal: Link an asset to specific quorum slice

[bonen]

To me the unique strength of Stellar is it's concept of quorum slices and the idea that trustlines have to be explicitly established.

We are working on anchoring a financial instrument onto Stellar. To comply with (EU) regulations we need some sort of control over the ledger. We can not just say, the truth equals what's accounted on the 'mainnet'.

Both because we don't have enough control over what direction the people behind the mainnet take and because its inherently difficult to define the mainnet with 'fluid' quorum slices.

So we plan to instead make a statement about which specific quorum slice can be considered the truth in case there ever will be a lack of overlap between Stellar nodes. However there will still probably be still confusion among investors as the asset will stay 'active' on the deviated set of nodes. Would it be an interesting feature (and computationally feasible) to be able to link an asset to a quorum slice? So that operations concerning that asset are only validated if the quorum slice accepts them.

[MonsieurNicolas]

I think what you are talking about is having a better integration between SDKs and an issuer's validators: right now there is no link between them from a transaction submission & verification point of view.

Basic idea is that if I somebody cares about asset X issued by Y, then what I want when querying the ledger is to know that this ledger is the one that Y will agree to.

I can think of two ways to do this:

• having Y run a validator with a quorum set Q.
  • Y then happens to have a local "blessed" copy of the ledger, so it can also operate a Horizon node (or other services) that clients can rely on.
• Y publishes a quorum set Q
  • issue there is figure out a good solution to translate this into a trusted data set. In particular, which Horizon server(s) will be able to provide enough data for SDKs to verify that Q agrees to whatever is returned.

[bonen]

Yes I agree. The first way you mention is what we are currently doing. But that still allows for asset holders to be easily mistaken about the ledger Y will agree to (in case of a dispute). Mistakes can easily happen because they can connect to other nodes which instead of giving them a warning will give them an answer..

The main 'use case' to anchor your asset on Stellar is to enable asset holders to exchange it for another asset. If two issuers Y1 and Y2 don't agree about the quorum set (there is no overlap) it's pretty risky to exchange these assets, because you could end up with a partially successful transaction. This is something I believe is not solvable; in the end if two issuers don't agree about a standard/protocol/history there is no interchangeability.

This risk is currently not explicit for asset holders, it would be nice (and I believe important to have financial institutions adopt it at scale) if it becomes explicit.

The first solution you mention I think is not sufficient because you would need to connect to two horizon servers simultaneously and still have no certainty that both atomically accept the transaction.

So I believe it would be a huge step forward if an asset holder is aware for every asset what is the quorum set he can trust. Assets that have overlap in their corresponding quorum sets can be safely / atomically swapped. Assets issued by parties that don't have overlapping quorum sets can not be atomically swapped (at least not risk free from a legal standpoint).

To achieve that transparency I think you're second suggestion could be a good direction! What do you think?

[stanford-scs]

I think the mechanism for this already exists. You should place the issuers domain in AccountEntry::homeDomain of the issuing account using a SET_OPTIONS transaction. If that is set to issuer-domain.com, then following sep-0001, you should serve a toml file at https://issuer-domain.com/.well-known/stellar.toml that has an ASSET_VALIDATOR pointing to the official validator for the asset.

So I agree the existing documentation and ecosystem support for this might be weak, but I would at least use the ASSET_VALIDATOR tag as a starting point.

[theaeolianmachine]

@bonen did @stanford-scs's comment around SEP-0001 solve your issue? If not, it's probably worth getting additional feedback on our mailing list, and potentially making a CAP if it feels like it's gaining support.