SAC and Issuers

[patent gyro]

In the protocol meeting today the point was made that an issuer account on classic has to be coordinated with for a contract to programmatically create, issue, and use a Stellar Asset Contract.

Regardless of the other decisions we're making this seems like a very inconvenient constraint we should find a way to eliminated for Stellar Assets on Soroban.

[deft forum]

Allowing a contract to be an account would solve this potentially. The factory contract would be the initial admin and classic issuer, and as such can do whatever it needs to do to transfer access over to some other contract.

This likely opens a v fun can of worms, tho

[granite adder]

Why Stellar Asset Contract can't be a fully transparent interface? I don't see any limitations aside from auth flags. As for the classic assets with enforced authorization, I think they shouldn't be bridged to Soroban by default. If someone want's to use them in Soroban env, it makes sense to create a wrapper smart contract for this purpose. So if the issuer wishes to allow using assets with authorization on Soroban, they can create a smart contract for this purpose, And if the issuer didn't provide such a contract, it means that the use of such tokens in Soroban is restricted,

[patent gyro]

The issue is that a contract can create a token for an issuer+asset code, but can't mint or change the admin without the issuer taking action.

i.e. the flow to create a usable SAC from the Soroban side is:

1. Deploy token contract.
2. Initialize with asset code and issuer account id.
3. Create issuer account on classic (if doesn't exist yet)
4. Submit tx that changes the token admin from the issuer to a contract.

I think we should try and eliminate steps 3 and 4.

It's worth noting step 1 and 2 can be called by anyone.

[granite adder]

Please correct me if I'm wrong, but I don't see a need to do step 1 and 2 at for Stellar Classic assets at all. What's the point of deploying a standard contract for this purpose? Execution environment could simply treat such assets as assets issued by a virtual contract (that don't really exists on the ledger). Therefore, the friction exists only for Soroban-only tokens that should be bridged to Stellar Classic, right?

[patent gyro]

That's a good point. @elder cove if the SAC contract is going to become only for SAC and not other tokens, do we need a deployment step anymore?

There's probably some cases you need the token contract to be defined explicitly. Assets on Stellar Classic don't exist until someone trusts them. But contracts on Soroban are reversed.

[granite adder]

The contract id of a classic asset from the Soroban side is fully deterministic, all interface methods are standard functions, so the deployment step will only unnecessary grow the state.

[steady marlin]

So how would you use a Soroban token in Stellar Classic?

It seems like you would need the deployment step for that to work backwards

[granite adder]

Let's expand on this. As I see it,

• Soroban-only token, which is created as a pure contract on Soroban, can't be directly used on classic.
• Stellar-classic token (identified by hash({assetCode},{assetIssuer})) can be used in Soroban environment directly, without creating an issuer contract. Transfers, trading, liquidity staking, etc.

The transfer (or any other operation) of the token, bound to the Stellar classic asset that does not exist in Stellar Classic world makes no sense, and strictly speaking, is impossible. How you obtain such tokens in the firs place, if they weren't issued? Such an operation should require some action from the issuer account side, and that' ok. Because otherwise people could do weird stuff. For example, I could mint some tokens (let's say, GBPC) on behalf of Circle's USDC issuing account. That makes zero sense,

[patent gyro]

Agreed, I'm not saying someone should be able to issue tokens from another account. I'm saying there should be someway for all of that to be true, except it be possible to create a token and issue from the Soroban side without having to coordinate.

[deft forum]

Is there possibility for the issuer account to signal trusted contracts, such that the contract can perform any admin activities? This would likely mean the introduction of a LedgerEntry and an operation on the Classic end. However, the issuer account needs to say SOMETHING about who can issue assets of behalf of them on the Soroban side, and it appears that either that stance needs to be recorded on chain or the Soroban contract needs to have the ability to issue it's own Stellar Classic tokens.

[patent gyro]

I'm not sure if we need a contract to be account. Another similar approach to your point would be that a contract could be an issuer. If a contract could be an issuer, then this would be resolved without contracts having to be accounts.

[deft forum]

Yeah, the minimum is that they can be issuers. It might get weird when you consider if they are able to take any actions on Classic, since without an account that would not be possible. (Would a "contract issuer" need to do this if they can pull levers on the smart side, and if not, why does the token need to be on classic anyway?)

[patent gyro]

I don't think any actions would be required on the classic side, hence they only need to be issuers, not accounts.

[deft forum]

I agree, just feels like the token won't benefit from existing on classic to justify the complexity. Although, I don't have a good sense of the legwork required to get "contracts as issuers" to be functional. Currently, if I try and create a trustline to some random asset code and a fresh public key (no account), it fails with op_no_issuer.

[granite adder]

Could you please describe any scenario which requires issuing Stellar Classic token on Soroban side?

[elder cove]

How would you know a contract call points to the SAC if you don't store the contract ID somewhere?

[deft forum]

A basic use case is a DAO which is controlled by a smart contract, but the token is actively traded so it was first issued on Classic to be tradable on the DEX. By being issuable on Soroban, new tokens can be introduced via governance proposal (say, the DAO wants to send X tokens to Y for Z).

[granite adder]

How about allowing standard asset descriptors to be used instead of contract ids for Classic assets?
{issuer}{code} - that's a handle up to 44 bytes length (32 bytes of address plus up to 12 bytes of asset code)

So asset issued on Soroban (let's call them contract tokens for convenience), will be identified by 32-byte handle, while Classic assets will be identified directly by the asset issuer+code descriptor.

That's much more efficient than a contract lookup. Especially if the contract is need only for mapping 32-byte has -> code+issuer combination. Usage of the issuer+code descriptor saves a roundtrip to the database (or cache lookup in the best case scenario).

The notion that assets in the smart contract environment should be minted only by smart contract and identified by the contract id came from Ethereum and other EVM-like chains. We can choose another way to implement this. Particularly because we have to build on top of existing blockchain (which by the way in many aspects is better than EVM).

[granite adder]

Ok, I see where you are coming from.
First, let's define how we can issue Classic asset tokens on the Soroban side. On Stellar Classic it's a simple payment to any account other than the issuer account itself, so I don't see why we should invent something different. If the issuer account makes a transfer to another account or smart contract address inside the Soroban environment, new tokens are minted and transferred. The same goes for burning tokens.

Now, back to the DAO case. If the DAO contract has a full control over the issuer account, it should be able to mint and distribute any amount of tokens without any problem. If the asset issuer entity (company or a person who own an issuer account) doesn't want to provide direct access to the issuer account to the DAO contract for some reason, this can addressed by minting some huge amount of tokens in advance and depositing them to the DAO address.

[deft forum]

I'm like 90% sure we are on the same page - but I want to clarify one thing:

If the DAO contract has a full control over the issuer account, it should be able to mint and distribute any amount of tokens without any problem.
By this you mean the DAO contract can enact a mint of the Classic <-> Soroban token within Soroban, right?

[granite adder]

Yep

If we manage to get rid of the concept of the issuer contract and adopt the SAC principle (at least how I understand it), the boundary between Classic and Soroban becomes much thinner. The minting process of the Classic tokens will be unified across both execution environments. No need to have separate balances for Soroban and Classic, and consequently we eliminate the wrap/unwrap token process and all related problems.

[elder cove]

But now the interface to interact with tokens is different between SAC and custom tokens. Contracts will have to be aware of which type of token they're using.

[granite adder]

Why different? The only difference is the byte length of the asset handle. Right now it is defined as ContractId, but we can introduce another built-in type (let's name it AssetId), which can be either a ContractId (in case of contract tokens) or {issuer}{code} descriptor (for Classic assets). The only difference from the smart contract developers perspective is that they will have to use AssetId everywhere instead of ContractId

[patent gyro]

Having a different ID breaks the assets are contracts experience though.

[granite adder]

Yes, definitely. I wrote about this above. But is this actually a problem? Coding on Soroban is already quite different from Solidity.

[granite anchor]

Not sure if this question belongs in this thread (or is premature to address):
When an asset is issued on Classic and interops on Soroban, that asset is presumably
available for trading on the classic stellar DEX and AMM venues, and also in Soroban DApps (AMM, DEFI trading protocols etc) venues, are there issues on how this would actually work in practice in terms of resolving price, balance, trades that might contend across multiple concurrent venues? (eg: are there design principles we should consider in the SAC or built-in token contract to constrain scope, reduce exploit surfaces, provide incentives (ie higher vs lower fees) to use the “right” interface?). I'm assuming assets "at work" in say a particular defi contract are not available for the Stellar DEX/AMM?

[royal frost]

that's some good questions, you're correct that assets that are on a contract would not be available on the dex/amm because they couldn't be on the dex or amm without being exported from the contract back to classic first; however it would be possible that a token could be both part of the supply in the contract and part of the supply on classic; in which case i would have to assume that the price discrepencies would be resolved in the same way that current price discrepencies are resolved between the sdex and amm... arbitrage traders

I'd like to see others answers to your questions as well, i think there's more to consider than the few things i mentioned above

[elder cove]

I’m not sure if the added complexity of special casing contractID’s for the SAC is worth the benefits -

1. The amount of state used to deploy the SAC is minimal. The contract is native, so no code is stored on the ledger.

2. Deploying the token contract and initializing it with the asset code and the issuer is done in a single step.

3. All contract data is tied to a contractID. With this change, we’d have to introduce this AssetId throughout our system. This is an implementation detail though so not a big deal.

My opinion is “assets are contracts” makes for a good experience from the users perspective, and we’d have to have a good reason to move away from this.

[granite adder]

Currently, I think we have a consensus that the behavior for SAC assets should be different from Contract assets (precision limitation, max i63 trustline balance, trustline requirements). So does it mean that when I write a general-purpose contract that operates with any asset, I will have to write code that invokes asset's parent contract to understand whether it's a SAC or Soroban asset? There's no way to tell the difference from the ContractId itself.

The “assets are contracts” is a legacy principle that came from Ethereum simply because Ethereum was designed with maximum possible simplicity and the absence of the token concept in the EVM is rather a problem than a "feature".
Stellar is much cooler than EVM-like chains because it has all basic things like assets and multisig already built-in. You built a new execution runtime, new Rust-based smart contracts language, with its own features and limitations. So do we really need to hold on to the “assets are contracts” assumption for all costs?

[elder cove]

The SAC still conforms to the token interface. It’s true that functions like xfer can fail due to trustline requirements or i64 overflow, but other token implementations can fail for any reason as well. The interface makes no guarantees about when any given function should succeed or fail.

[elder cove]

We don’t need to hold onto this “assets are contracts” concept, but to me, it feels like it leads to a positive user experience. The idea of being able to identify entries that belong to the SAC and first classing the SAC has come up multiple times though so maybe it is worth considering a flexible ContractID.