I might be missing something so correct me if I’m wrong.
If a dex keeps track of user balances using an internal data structure, there should be no need to contact the ledger to modify the internal state, all funds are kept in a single account owned by the canister, so a transfer would only require modifying the dex’s data structure, funds on the ledger aren’t moved. The same isn’t true if subaccounts are used for user balances.
The only downside is if a bug occurs a user could withdraw funds from other users. Or is there more to it?
The docs state canister with subaccounts can be used to act as joint accounts, but that could be done even without them, or does the subaccount act like a multisig wallet and doesn’t allow the canister to move funds out of a subaccount derived from a user’s principal without his authorization?
There is a lot to discuss here in a small statement! As a canister owner, I’m struggling through this. I want to use sub-accounts so that I reduce my attack surface, but it increases fees and makes transfers an async process. I’d love to talk about best practices here!
I like having a full transaction log on the ledger and generally don’t like wrapping because it reduces the power of a ledger to have smart contract features. Wrapping is also hard to keep from happening though.
Hi Mario
Would it be possible to have an unlock(time: T) function as well, in case someone wants to implement token locking or vesting? Would save a lot of effort for people building their own tokens on IC.
I’m not sure I’m following. The Ledger is always contacted twice, once by the user and once by the DEX. With subaccounts, the user moves funds to a subaccount of the DEX and then the DEX moves the funds from that subaccount to their main account. With approve, the user approves the funds to be taken and then the DEX moves the funds from the user account to their main account.
I cannot stress enough @Zane how subaccount and approve are very similar approaches that in most cases work the same. Same fee costs, same amount of messages.
Joint accounts can be possible only via approve for an infinite amount of tokens. It’s not possible in any other way. With subaccounts there is always only one owner of the tokens. In my opinion approving for an infinite amount of tokens is extremely dangerous as many bad experiences on Ethereum have proven.
It would be possible but I would be against it. We want the ICRC-1 standard to be as slim as possible to reduce overhead for devs and users. It’s fairly easy to build a locking canister which holds tokens of the user for a certain amount of time. The NNS is a good example of such canister.
Mario: if you mean a canister that transfers the tokens as per the vesting schedule every few months, then yes that is certainly possible. But is there really a way to give someone the tokens but keep them locked, without creating such a locking function at the smart contract level itself?
