Conversation
|
Preview is available here: |
6 similar comments
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
1 similar comment
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
leighmcculloch
left a comment
leighmcculloch
left a comment
There was a problem hiding this comment.
Some thoughts inline, the main one being I think we are introducing the "classic" term here unnecessarily. This change looks like both a refactor and new information about SEP-57.
|
Preview is available here: |
1 similar comment
|
Preview is available here: |
ElliotFriend
left a comment
ElliotFriend
left a comment
There was a problem hiding this comment.
couple tiny nitpicks, and a more significant question about the note at the bottom of the table.
great additions!!
| | **Source Code** | [Built-in Stellar Asset Contract](https://github.com/stellar/rs-soroban-env/tree/main/soroban-env-host/src/builtin_contracts) | [OpenZeppelin Fungible Token reference](https://github.com/OpenZeppelin/stellar-contracts/tree/main/packages/tokens/src/fungible) | [OpenZeppelin T-REX (RWA token) reference](https://github.com/OpenZeppelin/stellar-contracts/tree/main/packages/tokens/src/rwa) | | ||
| | **Relevant SEPs** | [SEP-0001 (Stellar Info File)][sep-1] <br /><br /> [SEP-0014 (Dynamic Asset Metadata)][sep-14] <br /><br />[SEP-41 (Soroban Token Interface)][sep-41] | [SEP-41 (Soroban Token Interface)][sep-41] | [SEP-41 (Soroban Token Interface)][sep-41] <br /><br /> [SEP-0057 (T-REX / Token for Regulated EXchanges)][sep-57] | | ||
|
|
||
| _\* By assigning a smart contract (`C...` address) as the owner of a Stellar Asset Contract, balances and transfer rules can be fully managed within the contract. This removes the need for trustlines, as balances are hold in the contract storage._ |
There was a problem hiding this comment.
I don't think this is true, as written. At least, it the way it reads to me feels inaccurate. This sounds like a G... account holding an asset wouldn't need a trustline if the asset's SAC has a C... address admin.
There was a problem hiding this comment.
This is what @leighmcculloch had suggested
There was a problem hiding this comment.
The admin can manage minting. In protocol 26 G accounts in contract land can also manage their own trust lines.
There was a problem hiding this comment.
@leighmcculloch We probably should clarify this is coming in protocol 26.
There was a problem hiding this comment.
Protocol 26 does not get rid of the trustlines though, and there is still going to be friction in using them. Trustlines also have nothing to do with the admin, do they? I.e. surely a contract can mint token, but that doesn't allow it the requirement for a G-account receiver to have a trustline.
There was a problem hiding this comment.
@dmkozh We have two viable models of managing this asset correct? Using a C… address as the admin over SAC balances, or a G… address to manage classic asset balances through trustlines. Managing with C... address gives you that composability where the admin can be another contract. Anything else I could add?
Co-authored-by: Leigh <351529+leighmcculloch@users.noreply.github.com>
Co-authored-by: Elliot Voris <elliot@stellar.org>
Co-authored-by: Elliot Voris <elliot@stellar.org>
Co-authored-by: Leigh <351529+leighmcculloch@users.noreply.github.com>
Co-authored-by: Leigh <351529+leighmcculloch@users.noreply.github.com>
Co-authored-by: Leigh <351529+leighmcculloch@users.noreply.github.com>
Co-authored-by: Leigh <351529+leighmcculloch@users.noreply.github.com>
Co-authored-by: Leigh <351529+leighmcculloch@users.noreply.github.com>
|
Preview is available here: |
7 similar comments
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
|
Preview is available here: |
Co-authored-by: Leigh <351529+leighmcculloch@users.noreply.github.com>
| | **Source Code** | [Built-in Stellar Asset Contract](https://github.com/stellar/rs-soroban-env/tree/main/soroban-env-host/src/builtin_contracts) | [OpenZeppelin Fungible Token reference](https://github.com/OpenZeppelin/stellar-contracts/tree/main/packages/tokens/src/fungible) | [OpenZeppelin T-REX (RWA token) reference](https://github.com/OpenZeppelin/stellar-contracts/tree/main/packages/tokens/src/rwa) | | ||
| | **Relevant SEPs** | [SEP-0001 (Stellar Info File)][sep-1] <br /><br /> [SEP-0014 (Dynamic Asset Metadata)][sep-14] <br /><br />[SEP-41 (Soroban Token Interface)][sep-41] | [SEP-41 (Soroban Token Interface)][sep-41] | [SEP-41 (Soroban Token Interface)][sep-41] <br /><br /> [SEP-0057 (T-REX / Token for Regulated EXchanges)][sep-57] | | ||
|
|
||
| _\* By assigning a smart contract (`C...` address) as the owner of a Stellar Asset Contract, balances and transfer rules can be fully managed within the contract. This removes the need for trustlines, as balances are hold in the contract storage._ |
There was a problem hiding this comment.
Protocol 26 does not get rid of the trustlines though, and there is still going to be friction in using them. Trustlines also have nothing to do with the admin, do they? I.e. surely a contract can mint token, but that doesn't allow it the requirement for a G-account receiver to have a trustline.
|
|
||
| ## Tokenization Model Comparison | ||
|
|
||
| | Dimension | Stellar Asset (with SAC) | SEP-41 Contract Token | ERC-3643 (T-REX) | |
There was a problem hiding this comment.
General note: I know that we're trying to avoid 'Soroban' in the docs for the most part and use just 'smart contracts'/'Stellar smart contracts' etc. I don't have a strong preference here, but just wanted to bring this up for consideration.
There was a problem hiding this comment.
Good call, okay will globally replace
| ### Tradeoffs | ||
|
|
||
| - Accounts must have an active trustline to receive, hold, and transact. | ||
| - Trustlines cannot be added programmatically through contract invocations, limiting support for assets that rely on bridging or chain abstraction patterns. |
There was a problem hiding this comment.
- until protocol 26
Though the most important thing about trustline is really that they require explicit user authorization.
There was a problem hiding this comment.
@dmkozh do you have a write up on what's coming from protocol 26 that we could catch up on?
There was a problem hiding this comment.
https://github.com/stellar/stellar-protocol/blob/master/core/cap-0073.md is a good reference for now.
| ### Benefits of the SAC | ||
|
|
||
| **Compatibility** | ||
| The SAC preserves full compatibility with the existing Stellar asset model, including trustlines, authorization flags, and the Stellar DEX. |
There was a problem hiding this comment.
The Stellar DEX part is kind of misleading, it might be worth specifying that DEX compatibility does not exist for SAC , but exists for the underlying assets via classic operation. That's pretty important, because e.g. C-accounts holding a SAC balance won't have access to DEX.
There was a problem hiding this comment.
Should we just not mention DEX?
There was a problem hiding this comment.
I think DEX and classic liquidity pools are a valid benefit of classic assets and thus SAC because of liquidity they provide. I just think we could separate these points (i.e. one point is what you have here but without DEX, another point is just additional liquidity thanks to the classic DEX/LPs). But the second point is up to your preference really.
|
Preview is available here: |
10 participants
No description provided.