Welcome to the OPT-IN Breakout Group Discussion Thread!
This thread is dedicated to discussions related to OPT-IN.
Group Focus
Topic: Improve the Opt-In Mechanism for Algorand Standard Assets (ASA)
Objective: Explore potential enhancements to improve user interaction (on-boarding, airdrop …) without compromising security
Where are we?
This discussion has spanned a broad spectrum since the inception of Algorand, touching on various aspects. These range from developing workarounds to streamline the process for end users to debating the elimination of the Opt-in feature from the core protocol.
Challenges in Removing the Opt-In Feature
In the blockchain sector, making changes is not as straightforward as in other software industries, where updates can be rapidly deployed and adopted. Suggesting an update and expecting immediate adaptation to a new way of using the blockchain is not feasible. Removing the opt-in feature without careful consideration could lead to:
A significant number of existing Smart Contracts/applications breaking.
Spam to end-user addresses.
Available Workarounds:
We have several strategies at our disposal to enhance user experience and maintain system integrity:
ARC-12 offers an on-chain application, called a vault.
ARC-58 provides a core solution that requires an additional “plug-in” for opt-in functionality.
Leveraging smart-contract-based tokens/NFTs, as outlined in ARC-200 and ARC-72, presents another avenue for innovation and improvement.
This thread will serve as the centralized place for all discussions, ideas, and feedback related to the topic. Don’t hesitate to redirect people there.
Yes I feel there is a lot of people who actually like the opt-in it may seem like a pain but at the end of the day it is better then having your wallet hit with many unwanted assets
I think from a user end ARC-12 offers the most universal solution.
The key of course is the UI implementation within wallets to make it clear that a user has an accessible vault - there’s still an element of relearning needed for someone new to the chain, but this is much better than an asset tx failing… especially so for bridges or sending assets like USDC/USDT from an exchange.
ARC-58… I’m not sure I’m maybe reading use-cases wrong but abstracted app accounts feels like a good interim that would have to be built as a first use-case… but not something that would necessarily integrate with every existing app or wallet very well. It almost needs to come with a ‘super app’ that onboards users without them specifically thinking about Algorand or Blockchain.
ARC-200 and ARC-72 I feel should be deployed regardless. Let the market choose if they get adoption - there’s certainly a bunch of benefits and creative ways to use them. Personally I wouldn’t love to see ALL NFTs or Tokens to become smart contract based as I think in general native assets are an amazing feature we should be marketing as a positive more (ADA users often think they’re the only ones with native asset NFTs for example). As a core part of the architecture its a pretty great differentiator to have vs other chains… and algorand may have been better positioned if they pushed them as a key benefit; see how SUI has marketed their object platform for the playbook… much more interesting than tps pissing contests!
I’d like to know more about the ARC-12 vs ARC-58 approach. Aside from lsig vs stateful contract.
ARC-200 is very good for programmable transactions, but to use smart contract based tokens instead of an ASA for a plain token just to drop the opt-in requirement from me isn’t the correct way forward, ASA default security is way more preferable and efficient. Instead apps should be required to better construct atomic groups when interacting with a wallet that isn’t opted into the ASA by adding the optin txn.
We do not want to remove the opt-in feature. It’s in place to protect the account and network from malicious spam. The opt-in feature on Algorand is a strength over other blockchains that do not have opt-in. In addition, backward compatibility must be maintained.
ARC-58 seems to be a more generic and robust solution, but it’s still in DRAFT status.
ARC-12 offers a simple solution targeted specifically for working around opt-ins. In addition, the ARC is in LAST CALL status and close to being finalized. Thus, I would concentrate efforts on moving forward on ARC-12. The key will be getting the wallets on board to integrate ARC-12 with a user-friendly experience.
ARC-12 is more of a register that will track who should own what.
The ASA will then be stored in an application account (vault) linked to your account, and you might decide at any point to accept it to your main account with a classic opt-in.
On the other hand, ARC-58 has account abstraction as a core concept.
You delegate the power of your account through rekeying (You are still in control behind the scenes), and everything you want can be handled for you.
For example, you say that you want to accept every ASA without opt-in from now on, you sign the corresponding contract (We might call it plug-in), and you are good to good until you change your mind.
Atomic groups with opt-in are only half a solution; it’s a pain if you use a hardware wallet to sign a bunch of TXNs.
Also, the goal is to help onboarding new crypto/non-crypto people to our ecosystem. Going to a random place saying, download this wallet, and I will send you some USDC seems easy on paper but is not an easy and smooth task right now
Hi, we have added the support for ARC-200 to AWallet. It is currently under review in the pull request
at
Good side is that the third party can pay 0,0285 algos to opt in any account for the.
Bad side is the vague standard. It does not define how to name the boxes. If one arc200 contract creates one implementation and other arc200 contract other implementation with different box references, this will not work in wallets.
Things to improve may be also some opt out mechanism if user wants to get the box costs back, which is not in the standard now so this 0,0285 algos is basically much higher cost than optin of standard asset 0,001 because standard asset even though it has the 0,1 algo min requirement it can be taken back by opt out. (Much higher in relative means when algo price will be $5 it will cost 14 cents.)
Let me stress here also the security aspect… ARC200s are not to be trusted unless good audit is provided for deployed asset. When people will get use to use arc200s the scammers will pop up doing clawbacks and peoples funds will disapear. On the other side if government really want to do programmable money (CBDCs) where they will tax accounts which do not circulate the fiat, this may be solution for them.
Bad side is the vague standard. It does not define how to name the boxes. If one arc200 contract creates one implementation and other arc200 contract other implementation with different box references, this will not work in wallets.
Can’t this be overcome by using the simulate endpoint with the arc200_balanceOf method?
NFD Vaults have been live since September 2023 and are actively being used. Defly has stated they’re working on adding support and the NFDomains app has full support for sending from any account (or vault) to another account, or vault with optin reqs automatically handled while also providing display of all asset types in any accounts (including vaults).
Even were I not directly involved here, I think we should definitely take into account existing, deployed, and ‘used’ solutions.
The owner can lock the vault, blocking airdrops while still allowing themselves to send to the vault giving users the choice. Multiple community tools exist to send to vaults as well - evil tools, or things like the batch-asset-send tool I wrote:
Vaults have a different approach to ARC-12 - where the sender never gets back their .1.
I felt there should be always be a cost to the sender of the airdrop. If the recipient doesn’t want the asset, then they can burn it, toss it, etc. and keep the remainder of that .1 which went to MBR (now freed). The MBR sent by the sender going back to the sender doesn’t provide enough disincentive to airdrop ‘spammers’ because there’s a reasonable chance they’ll get most of it back from disinterested parties. There’s a cost to handling that potential spam - the recipient should at least get something out of it.
In terms of ARC-12 vs Vaults - one option would be to have an alternative ABI for ‘vaults’ (that a future version of NFDs could adhere to) but allow users to change out which arc-12 compatible contract to use for arc-12 drops. This way users could change out their airdrop destination to a particular nfd vault for eg (w/ a compatible ABI interface). I’d worry about the disconnect though between ‘account’ and vault destination and fact that nfd ownership could change but the arc-12 redirect might still reference a vault no longer owned by that account. Given Vaults are meant to be used as independent accounts that can be transferred, etc. and not just as single-slot dropboxes I think it still might be awkward.
ARC200 type of assets obviously get around all of this. It’s still effectively sender pay and when/if they get MBR back is up to the implementation. There’s a huge uphill battle to adoption across every wallet, and platform (AMMs for eg). ASAs avoid smart-contract risk by themselves but they’re not without their disadvantages.
Ultimately, for ASAs, it’s hard not to think a protocol solution is really needed here if people truly want to get rid of opt-in. It couldn’t be done retroactively, but perhaps accounts created after round X are auto opt-in. Accounts prior can turn it on with a transaction similar to a keyreg. Then an ‘asset transfer’ transaction is either .001 or .101 depending on whether the recipient is opted-in. Sender always pays.
While you can assume every ARC-200 will use boxes, it’s not in the ARC itself. We can imagine a token for a company where only few people my access it and local storage is enough.
Using a custom indexer like the one plan for ARC-72 NFT should solve this, @cswenor is there something like ARC-74 for ARC-200?
Yeah, the idea that ARC200 didn’t specify the structure just the interface would let the developers decide how they wanted to build it.
The indexer that was built for ARC-72 could be modified for ARC-200 as well. We haven’t gone down that path yet because most people don’t want to automatically view every token that was sent to them. This is why you are getting the outcry for the opt-in to stay. By not having an automatic built in indexer adding an app id works in a similar way to how opt-ins work without the poor user experience. I could see a world where wallets automatically add certain Assets, like USDC, but I wouldn’t automatically add all of them.
The indexer itself would add value adding to something like a block explorer though. Just so it would be easy to discover all Assets created. But I think this is something a block explorer would just build in.
I know this doesn’t really add much to the conversation, but I think all of these options should be supported.
ARC12 helps in terms of being able to send assets that currently exist. For example, we wouldn’t have USDC remade into an ARC200 token at this point. What I like about this too is that you can send to a brand new user and they don’t need to do anything other than claim from their mailbox. There are also minimal risks involved.
ARC 58 is pretty cool and probably offers the most flexibility. I can see overtime this abstraction being used in many different ways, helping to ease the burden, but it still requires the end user to learn how to rekey and can’t be applied to a brand new user until done. There are some risks in terms of rekeying as well.
ARC 200 creates new features for tokens, but in an already existing eco with plenty of ASAs, it will be hard imo for this to take market share. It should be included as options are always the best way to promote growth, same with 72. There can be newer use cases, but I think 12 and 58 will help more based on the way Algorand is currently set up.
Can algokit generated client in while composing with atc algo call simulate endpoint and fill in the boxes it will need?
Yes this is actually possible now in the latest version of algokit. algokit.Config.configure({ populateAppCallResources: true }) will mean all resources needed (apps, assets, accounts, and boxes) will automatically be filled in. With this in mind, standardizing box names is not needed
This new implementation still maintains the core principles of ARC12. There is a vault address that holds assets for a user that they can later claim. This new implementation, however, does not require one new app per vault and instead just has one master vault control multiple accounts.
With the new implementation, if I want to send ALICE an asset I do an axfer to the app atomically with a sendAsset(ALICE) call. The app will then figure out if it can send the asset directly to ALICE or if it needs to create and/or opt ALICE’s vault into the asset. There is also a method provided that will tell the caller how many itxns will be sent and how much MBR will be required. This greatly reduces all of the state-dependent complexity that was in the initial implementation of ARC12. Here is the TypeScript function used to send an asset to anyone using this ARC: arc12/__test__/arc12.test.ts at update_with_rekey · joe-p/arc12 · GitHub
The other major benefit of this implemtnation is that it does not care when/how it gets the MBR. This means you could onboard many accounts with just a single MBR payment to the app, rather than requiring one MBR payment per axfer. This is particularly useful for things like airdrops where many accounts might need a vault opt in at once.
The one thing missing from this implementation that was in the original implementation is the initial sender getting the MBR back upon claim. I think this is a useful feature, but wanted to keep this new implementation simple to start.
The point of opt-ins is to serve as an anti spam-ASA feature. However, it is causing significant friction. Since many really feel like it protects them, here’s my suggestion to change it:
Keep the opt-in guard as is for initialized addresses.
For uninitialized addresses, as part of initializing them you can also pass along whatever ASA you want, so long as you also include the MBR for each ASA.
An address that does not (currently) exist in the ledger is considered uninitialized. Such an address needs to be seeded with 0.1 Algo MBR just to be registered. (I’m ommitting tx fees here.)
This suggestion is helpful in the following scenarios:
Giving NFTs to new users at crypto events.
For every person, you have them generate a seed in their wallet and then generate an address. They present that address to the event holder, who sends a group transaction containing 0.2 Algo + 1 NFT ASA. Any additional transfers of NFTs will however need an opt-in, or for them to accept the NFT into a new address.
Sending USDC from Coinbase to your address
For an existing address you’ll need to opt in to USDC, or you could generate a fresh address and receive it there instead.
One time addresses
Some of the payment providers we have been talking to would like one-time addresses as a minor form of privacy mitigation. So you generate a new address for each payment which will include at least 0.2A + ASA. Without addressing the problems of opt-ins one-time addresses will need 3 transactions instead of 1.
ARC-52 will make it easy to generate thousands of new addresses from a single seed.
There is one concern here. It is possible to “close out” an account, i.e. empty it completely of Algo to signal to the ledger that it should forget it. Thus it would become “Uniinitialized” again. But a spammer could still target such an address, thinking it might come back into use one day.
There is one concern here. It is possible to “close out” an account, i.e. empty it completely of Algo to signal to the ledger that it should forget it. Thus it would become “Uniinitialized” again. But a spammer could still target such an address, thinking it might come back into use one day.
After writing this I came to discover that on Ethereum, to avoid replay attacks every address has a counter (called nonce) that gets incremented after every transaction. This means that an attacker can’t copy+paste someone’s signature and send it again, that signature is applicable to that counter. A downside of this is that you can never actually “delete” an address once it has been used. It can be emptied of funds, but the ledger keeps that nonce around just in case the address is funded again in the future.
On Algorand we instead use a validity period, where a transaction you sign is only valid for a certain time. After that it can’t be used again.
So in other words, someone who is afraid of being targeted by a malicious spammer could simply not close out the address and just leave it with 0.1 Algo to keep it forever locked away.
DO NOT REMOVE THE OPT-IN FEATURE. Its the least of our problems and is unnecessary to spend time on it. NFD has already solved this with vaults. Push them in that direction if they want random airdrops. NFD could use the exposure and its an investment from AF so its a win for everyone.
The technical implementation is far beyond me (so I don’t know if it is feasible or how it would work technically), but the best solution in my mind is an “opt in to opt ins”. In other words, uninitialized addresses can receive any asset so long as accompanied by MBR by the sender. Once initialized, they can continue to receive any asset this way unless and until they signal that they require opt ins.