Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Op code to receive the app call sender #6065

Open
scholtz opened this issue Jul 12, 2024 · 7 comments
Open

Op code to receive the app call sender #6065

scholtz opened this issue Jul 12, 2024 · 7 comments
Labels
new-feature-request Feature request that needs triage

Comments

@scholtz
Copy link
Contributor

scholtz commented Jul 12, 2024

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.

@scholtz scholtz added the new-feature-request Feature request that needs triage label Jul 12, 2024
@emg110
Copy link
Contributor

emg110 commented Jul 12, 2024

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
Copy link
Contributor Author

scholtz commented Jul 12, 2024

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
Copy link
Contributor

emg110 commented Jul 12, 2024

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
Copy link
Contributor Author

scholtz commented Jul 12, 2024

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
Copy link
Contributor

emg110 commented Jul 12, 2024

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
Copy link
Contributor Author

scholtz commented Jul 13, 2024

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
Copy link
Contributor

emg110 commented Jul 14, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
new-feature-request Feature request that needs triage
Projects
None yet
Development

No branches or pull requests

2 participants