refine and clarify some points in the custom SAC admin guide #1245
Conversation
|
Preview is available here: |
|
|
||
| :::warning | ||
|
|
||
| The following "minter" contract calls the `require_auth()` function for itself. This means you would need to include some `__check_auth` logic in the contract, which is demonstrated in the [custom account example contract](../../smart-contracts/example-contracts/custom-account.mdx). We'll omit those details here, for the sake of simplicity and brevity. |
There was a problem hiding this comment.
I think this is way too nuanced and really not related to the topic. This makes the example incomplete without check_auth, and it doesn't really demonstrate something close to reality (I don't expect token contracts to also be custom accounts).
I can think of the following simple example that's not completely permissionless, but also demonstrates something interesting: consider a claim_airdrop function (or something along these lines), that mints some small fixed amount to a given address. It would take the receiver address, call require_auth for it in order to make sure it's a real address, then make sure the address hasn't claimed before (using storage), then mint some amount of token to it. This shouldn't add more than a couple lines of code to the example (there is no need to even use some UDTs for the keys, just add the addresses directly to the storage for brevity).
There was a problem hiding this comment.
this is perfect! i'll use that instead. thanks!
|
Preview is available here: |
Addresses the comments from the initial publishing of this page:
Refs: #1234