Refresh SAC CAP #1370
Refresh SAC CAP #1370
Conversation
core/cap-0046-06.md
Outdated
| #### Clawback | ||
| Account balances can only be clawed back if the trustline has | ||
| `TRUSTLINE_CLAWBACK_ENABLED_FLAG` set. When a contract balance is created, it | ||
| will it will be clawbak enabled if the issuer account has |
core/cap-0046-06.md
Outdated
| Account balances can only be clawed back if the trustline has | ||
| `TRUSTLINE_CLAWBACK_ENABLED_FLAG` set. When a contract balance is created, it | ||
| will it will be clawbak enabled if the issuer account has | ||
| `AUTH_CLAWBACK_ENABLED_FLAG` set. Not that the clawback enabled flag for |
core/cap-0046-06.md
Outdated
| functionality to an administrator. The administrator can be a contract, a simple | ||
| Ed25519 key, or an existing Stellar account. | ||
| functionality to an administrator. The administrator can be a contract or an | ||
| existing Stellar account. | ||
|
|
||
| This design decision does not break compatibility with Stellar assets. If an | ||
| existing holder does not want to accept the new terms, they simply elect not to |
There was a problem hiding this comment.
If an existing holder does not want to accept the new terms, they simply elect not to wrap their asset. - I don't this statement is true. Anyone can wrap any asset. I assume what this actually should mean is that the issuer may choose not to change the token admin and retain authority over minting/clawbacking the token.
There was a problem hiding this comment.
Yeah this is out of date, but what it's trying to say is that a user that owns a token in classic does not have to use their token in soroban if they don't want to.
There was a problem hiding this comment.
Hmm, but this is in the admin section, so I thought it concerns issuers... Users actually don't have a choice - if issuer creates a SAC and changes the admin, then the new admin will be able to e.g. clawback the token. I don't think that's an issue, but this paragraph doesn't make much sense to me.
There was a problem hiding this comment.
I think this section should be removed. It was written at a time where we didn't have compliance controls in the token contract. Now we have controls that mimic classic.
There was a problem hiding this comment.
The original concern was that Soroban gave the admin even more control, but as a token holder, you didn't have to care if you didn't use Soroban.
There was a problem hiding this comment.
Ok, then I think we also should remove 'If an existing holder does not want to accept the new terms...' sentence as there aren't really new terms (the admin might change, but holder can't do anything about that).
There was a problem hiding this comment.
I updated this section
core/cap-0046-06.md
Outdated
| have a wrapper interface because those administered by contracts would lose | ||
| control over the wrapped assets. Smart asset issuers can always deploy their own | ||
| wrapper interface should they need it. | ||
|
|
||
| ### No Total Supply | ||
|
|
||
| Total supply is confusing for classic assets because they can exist in wrapped |
There was a problem hiding this comment.
Total supply is confusing for classic assets because they can exist in wrapped and unwrapped form. - this is no longer correct - there are no 'wrapped' balances (maybe need to make a pass through the whole doc and clean this up). The real reason is that classic assets don't support total supply, so SAC doesn't support them as well.
There was a problem hiding this comment.
Good point. I removed all references to "wrapped"
core/cap-0046-06.md
Outdated
| `AUTH_CLAWBACK_ENABLED_FLAG` set. Not that the clawback enabled flag for | ||
| contract balances cannot be modified, which is a little different from | ||
| trustlines where the issuer can choose to disable it. | ||
| will be clawbak enabled if the issuer account has `AUTH_CLAWBACK_ENABLED_FLAG` |
core/cap-0046-06.md
Outdated
| functionality to an administrator. The administrator can be a contract, a simple | ||
| Ed25519 key, or an existing Stellar account. | ||
| functionality to an administrator. The administrator can be a contract or an | ||
| existing Stellar account. | ||
|
|
||
| This design decision does not break compatibility with Stellar assets. If an | ||
| existing holder does not want to accept the new terms, they simply elect not to |
There was a problem hiding this comment.
Ok, then I think we also should remove 'If an existing holder does not want to accept the new terms...' sentence as there aren't really new terms (the admin might change, but holder can't do anything about that).
core/cap-0046-06.md
Outdated
| burning. Tokens that need to track total supply can do so by having the | ||
| administrator contract update it when calling `mint` and `clawback`. | ||
| Total supply is not available because it isn't supported in Stellar Classic, so | ||
| there's no way to reasonable track the supply between trustlines and contract |
No description provided.