enable contract deposit box usage via destination address

[veloboot]

SKALE IMA currently supports interchain token transfers from external accounts only e.g. users with private keys and not smart contracts.

This pull request includes modifications that enable smart contracts to perform transfers among all chains.

The various DepositBox*.deposit* functions are not designed to be called from a contract since they rely on the destination address being the same as msg.sender. This modification is backward compatible, keeping the previous interface intact and extending with transfer* functions that explicitly pass the SChain destination address.

This modification will require existing interface definitions e.g.e. IDepositBoxEth, IDepositBoxERC20, ..., ITokenManagerEth, ITokenManagerERC20, ... to be extended with the additional overridden function signatures. These are defined in a different repository @skalenetwork/ima-interfaces.

[payvint]

So we removed receiver field in RR 859, because it opens a security vulnerability of draining CommunityPool wallets. Address "A" on a SKALE Chain "B" can send 1 wei to everyone who recharged a CommunityPool wallet for a SKALE Chain "B".
So we recommend to write a contract for your purposes and connect it as a custom contract to your SKALE chain.
Also there is a way to change a reimbursement way - sender would pay for tx instead of receiver. But this solution would increase a size of message, which means the gas cost of transferring message would be increased.

I think to have a receiver field only in deposits would solve your issue. You can deposit by contracts, but for withdrawing back you need to have a custom contract or do it by addresses. Would it solve your issue?

[veloboot]

For our first SKALE deliverable, yes I think an explicit receiver address for deposits would work well. I’d been contemplating some kind of whitelist or a permit signed by external receiver account to handle opposite direction but I think for now we have two use cases: 1) regular user bridging from L1 to and exiting from L2. 2) L1 contract bridging and transferring to various L2 accounts, some are external, some are contracts.

…

On Jan 13, 2022, at 10:52 AM, Artem Payvin ***@***.***> wrote: So we removed receiver field in RR 859 <#859>, because it opens a security vulnerability of draining CommunityPool wallets. Address "A" on a SKALE Chain "B" can send 1 wei to everyone who recharged a CommunityPool wallet for a SKALE Chain "B". So we recommend to write a contract for your purposes and connect it as a custom contract to your SKALE chain. Also there is a way to change a reimbursement way - sender would pay for tx instead of receiver. But this solution would increase a size of message, which means the gas cost of transferring message would be increased. I think to have a receiver field only in deposits would solve your issue. You can deposit by contracts, but for withdrawing back you need to have a custom contract or do it by addresses. Would it solve your issue? — Reply to this email directly, view it on GitHub <#945 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AVLVSLOLPR33NEN2WH7ZY73UV37NRANCNFSM5LZ5VCTA>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you authored the thread.