Op code to receive the app call sender

[scholtz]

Problem

We want to check the legitimity of address who calls the application. We can do outer information check up to level 1 at the moment (to receive the txn.Sender) . However we want our smart contracts to be composible, so that people can call it within the inner tx groups. There is no way to receive the information about the real signer in the smart contract now. Please enable it.

Our business use case:

We have created Biatec concentrated liquidity AMM and we need to check the KYC verification level of real sender, and we want to incentivize users to use our product so that they receive higher engagement level and they will have lower swapping fees. Inability to check the real sender breaks the composibility in the dex aggregators.

https://github.com/scholtz/BiatecCLAMM/blob/9906610e25108cb79e63e8e788c64177f016819f/contracts/BiatecClammPool.algo.ts#L888

Solution

Please create opcode to receive the real app call sender.
Please allow usage of it in the python/tealscript

for example as txn.globalSender or globals.sender

Dependencies

no

Urgency

We want to launch the Biatec concentrated liquidity with this feature, so it is super high urgent.

[emg110]

You can do it now (without the need for any change in Algorand source code or new opcodes) :
In smart contract which originates the inner TXN, add txn sender to accounts array or ARGs of your inner transaction and within the destination smart contract read it while handling method call. You can use this in all subsequent nested inner txn calls as well and keep real transaction sender record during call chain.

[scholtz]

You can do it now (without the need for any change in Algorand source code or new opcodes) : In smart contract which originates the inner TXN, add txn sender to accounts array or ARGs of your inner transaction and within the destination smart contract read it while handling method call. You can use this in all subsequent nested inner txn calls as well and keep real transaction sender record during call chain.

But if i have it as the argument i cannot verify if the sender is really the address specified. This way anybody could send there some best trader address, and they would receive the lowest trading fees..

I have no control over the smart contracts which call my contract.. as i said we need this composable.. the same way as dex aggregators can call pact and tinyman, but we want to have the information of the sender because of the verification level check and the level of fees user has to pay so that we motivate engagement to use our services

[emg110]

The smart contract conventions are author's to determine, if you set it at an account array index and receive it from that in destination contract, no one can change it or take advantage of it because it is an end to end internal op for SC domain.

[scholtz]

I have no control over the smart contracts which call my contract.. as i said we need this composable.. the same way as dex aggregators can call pact and tinyman, but we want to have the information of the sender because of the verification level check and the level of fees user has to pay so that we motivate engagement to use our services

I have no control over the smart contracts which call my contract.. as i said we need this composable.. the same way as dex aggregators can call pact and tinyman, but we want to have the information of the sender because of the verification level check and the level of fees user has to pay so that we motivate engagement to use our services

[emg110]

Oh having no control is another context you just updated and added to this subject. yes in that case this solution I mentioned is of no use.

[scholtz]

Oh having no control is another context you just updated and added to this subject. yes in that case this solution I mentioned is of no use.

So I assume you agree to create opcode to allow smart contracts be able to use the real sender? I believe it opens a lot of use cases which are not possible at the moment.

[emg110]

Yes, I agree it can be very useful to get not only the original sender but also all of the original TXN information during ITXN handling in destination SC.