#How should we track Soroban Improvement Proposals and Standards?

10 messages · Page 1 of 1 (latest)

ocean egret
#

Currently, Stellar Core Advancement Proposals (CAPs) live in stellar-protocol/core and Stellar Ecosystem Proposals (SEPs) live in stellar-protocol/ecosystem. It's worth mentioning that in other ecosystems, like ethereum, there is no such separation between protocol improvements and ecosystem standards. (correction: in ethereum ERCs are a subset of the EIP RFC system)

Where/how should we track Soroban Improvement Proposals and Standards?

  1. Should Soroban env improvements be separated from ecosystem standards? I think that the line is a bit blurry sometimes. For example Auth Next (which is a protocol feature) requires contracts to implement the check_auth interface, which I think of as an ecosystem standard. Similarly, the native token contract, which is part of the env, depends on the token ecosystem standard. Given the cross dependencies it might be easier to have a single RFC system?
  2. Should these co-exist with stellar-protocol? Soroban is fairly detached from the current stellar-protocol
#

Some examples:

  1. The Standard Token Interface
  2. Custom Account Interface
  3. Metadata: standard ledger key and structure
last crescent
#

I think the key distinction is that ecosystems standards by definition do not need protocol changes to evolve --> I think we should keep the separation. Just like in Ethereum there are EIPs and ERCs. In the example above the existence & spec of check_auth is part of the protocol, but SEPs could be written to define what happens inside that function (like define how to allow composition between "smart wallets").

ocean egret
#

Just like in Ethereum there are EIPs and ERC
Small correction: In ethereum everything is an EIP. ERCs are a subset of EIPs that define application level standards

young ice
#

i think we should keep CAP's and SEP's as well, and i think that soroban should be listed under CAP's due to it being a core product functionality. most SEP's are for things that are like ecosystem integrations (such as authorization or asset metadata servers)

shell mantle
#

the built-in contracts (SAC for now) are kind of in a weird spot as their interface is defined at protocol level (as CAP), but probably we want the custom tokens to be compatible with its interface, which is why there could be a SEP as well. but I don't think it's too big of an issue

clever hound
#

My opinion is that as of now I don't see much reason to distinguish Soroban proposals and Stellar Classic proposals. Can always take the EIP approach and group CAPs into categories like "Stellar Classic" and "Soroban" if it ends up being confusing.

young ice
#

imo the term stellar classic breeds confusion because people might think it's a seperate chain

half bramble
#

I'm not sure where this goes but something I've been thinking about: "SEP" and "CAP" used to throw me b/c of the acronyms - I'd end up looking up what "SEP" and "CAP" meant over and over and what the difference was to remind myself. I think one term is clearer, but I also think spelling it out is better than always defaulting to the acronym. Something like "Stellar Standards" would make more sense to me. just a thought

pine copper
#

I agree with @last crescent and @young ice that there's value in keeping the CAP and SEP distinction. The proposals we can expect will still fit pretty well into both.

As an example, the Stellar Asset Contract is a protocol change and its introduction to the protocol is discussed in a CAP. There should also be a SEP that defines a standard token interface. The CAP can reference the SEP.

If someone was wanting to propose a new type of token with a new interface, it can be a SEP.