ARC-84: ASA-Compatible Smart Contract Tokens #341
Conversation
joe-p
changed the title
| manager: Address; | ||
| /** The address of the app that implements the transfer hook. If this is not set, transfers are always approved */ | ||
| transferHookApp: AppID; | ||
| }; |
There was a problem hiding this comment.
You're missing the url field from the asset params.
There was a problem hiding this comment.
I originally intentionally omitted it because I thought it could just be a metadata field, but since it's such an essential param for clients probably worth it to add to the params
There was a problem hiding this comment.
You can't say it's an ASA upgrade/replacement and remove the literal one field many need for token and nft images (and that want it to be mutable). 😀
There was a problem hiding this comment.
(and because you position these as equivalent to the existing Asset Params)
There was a problem hiding this comment.
Yeah that's fair. I was originally thinking we could just define a standard for how the URL is specified in the metadata, but adding it to params just makes way more sense for ASA compatibility.
|
|
||
| arc84_metadata(key: MetadataKey): Metadata | ||
|
|
||
| arc84_balanceOf(id: TokenId, account: Address): uint64 |
There was a problem hiding this comment.
I'd also recommend an arc84_numHoldersOf(id: TokenId).
Determining the number of holders for a token is a common need, and with a global data registry, fetching literally all boxes (or even prefix-match fetch of all) will be painful, yet updating a counter on transitions from/to 0 balance will be easy to handle.
There was a problem hiding this comment.
Yeah I like that idea. This would allow us to be even more granular because we can specify the actual holders (balance > 0), not just people who have opted in.
|
|
||
| ##### Subscriptions | ||
|
|
||
| Someone that holds a token such as USDC might want to pay a monthly fee to some on-chain application. Subscriptions are a very common payment model and it would be nice to replicate it on-chain. | ||
|
|
||
| ##### Asset Offers & Listings | ||
|
|
||
| One might want to list an NFT for sale but not remove it from their own address. Similarity, they might want to make an offer on an NFT without that assets they are offering to leave their address until the sale is made atomically. |
There was a problem hiding this comment.
These and other allowance related features seem like something that should be a feature of wallets rather than assets. It's hard to see why this functionality should be implemented per asset or managed at the asset level.
Yes we currently don't have a good delegation system but there is no reason why we couldn't have smart account/wallet applications with this functionality builtin and available for all ASAs (or other token standards)
There was a problem hiding this comment.
Yeah this is one of the goals of ARC58: #269
We might end up in a world where we have ARC84 delegations done through the ARC84 contracts and ASA approvals done through an ARC58 abstracted account. That seems ok to me. Delegation at the account level MUST be done in individual apps because there is no way to generalize the behavior and validation of ASAs and smart contract tokens in a single ARC like ARC58. Because of this, whether that delegation happens in a ARC58 plugin or a ARC84 contract seems irrelevant to the end user.
Also, I think we are pretty far from ecosystem adoption of abstracted accounts and getting there requires a lot more effort than the ideal adoption laid out in this ARC.
|
|
||
| ### Allowances With Expiration & Cooldown: Safely Enable Delegation Features | ||
|
|
||
| Approvals are a key feature of other smart contract tokens, such as ERC20 and ARC-200, but they have serious security implications. For example, a large amount of EVM exploits occur due to users giving protocols token approvals and that same protocol being exploited years later after they no longer us the protocol. This is the driving rationale for having an expiration time for allowances in ARC-84. By setting an expiration time, users can be sure a protocol will not have access to their tokens when they are done using the app without having to take any explicit action. Similarly, the cooldown mechanism enables a highly-requested feature, subscriptions, in a secure manner. By being supported directly in ARC-84, there is no implementation ambiguity and all apps in the ecosystem can clearly display allowance information to users. |
There was a problem hiding this comment.
AFAIU allowances and approvals exist in ERC20 mostly to work around the fact that there are no transaction groups in the EVM. It is not possible for example to do a swap by doing a transfer of USDC + swap call in one transaction. Instead the swap contract is given approval to spend USDC, followed separately by a contract call to swap usdc to something.
As I mentioned above, subscriptions and other allowance based features seem more appropriate for a wallet app standard than an asset standard.
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| ### Contract Logic: Bridging ASAs |
There was a problem hiding this comment.
Can you explain this bridging in a bit more detail? How does bridging to ASAs work if the asset contract uses hooks to enforce royalties/taxes/etc?
There was a problem hiding this comment.
Since there will be one canonical bridge, the transfer hook app that checks/automates royalties would need to add an exception when sending form the bridge. They could be taxed going in, but not going out. Anything that doesn't account for this won't be able to be bridged out back to an ARC84. We could actually solve this by allowing the person bridging to ARC84 specify extra txns that need to take place.
This ARC proposes a new smart contract token standard that aims to have ecosystem comparability and trusted accounting logic
For those unfamiliar with GitHub, you can view an easily readable version of the proposal here: https://github.com/joe-p/ARCs/blob/arc84/ARCs/arc-0084.md
TODO:
data/notefield toTransferdata structure for attaching arbitrary data