BlackRock and the potential for bespoke *user-directed* whitelisting/blacklisting

General
1

So, as many know, Blackrock recently launched its BUIDL fund on Ethereum through Securitize. Almost immediately, crypto twitter began sending all manner of meme coins to it (much to BlackRock and Securitize’s embarrassment). This presents some interesting problems for BlackRock/Securitize now, as these dustings represent taxable income under current IRS rules, but it is income they likely are never going to realize because I doubt they want to be in the habit of selling off sketchy tokens as they come in. As we know, Algorand’s opt-in feature would have prevented this nonsense.

However, an equally if not bigger problem also occurred. Specifically, people started sending tainted ETH to BlackRock via the TornadoCash router. Tornado Cash has been sanctioned by the US Government for facilitating money laundering. Thus, funds routed through it present a serious legal quandary since it is now mixed up with legitimate funds that BlackRock will want to access. Indeed, in this interview at the 21:57 mark, you can see just how uncomfortable this issue made the head of Securitize when asked about it. (https://twitter.com/laurashin/status/1771153870468587979?t=1317)

So, my question is whether there is a technical solution that could be baked into protocol where users can enable a user-directed whitelist and/or blacklist. In other words, a wallet when created is by default how we normally use it. However, the user could decide to enable whitelisting, such that it cannot transact (send or receive) with another wallet unless that wallet is added to the whitelist (basically, an opt-in but at the wallet to wallet level). Alternatively, you could enable a blacklist where the wallet could not transact with a wallet it has marked as on the blacklist.

I think solving this from a technical standpoint could give Algorand a strategic edge in terms of dealing with institutional clients who have to be very cautious of AML laws, other OFAC regulations, and interactions with internationally sanctioned entities.

8 Likes
2

Nice post. It’s really interesting people are routing ETH to the wallet through Tornado Cash. I think there is definitely a solution to this problem technically, as well as legally to resolve the issue. Ultimately, it’s just about allocating the time and resources toward solving the problem.

2 Likes
3

Off the cuff, a few thoughts:

  1. Algorand’s opt in model for ASAs obviously prevents the token dusting attacks
  2. Allow- or block-listing accounts that can send you something is a bit trickier, I think, without changes at the protocol level.
  3. That said, I think the frontier may be assets which have this logic built in. For example, imagine a smart contract-controlled token representing some asset which only allows itself to be transferred to an account that has been approved to hold that asset by some approving authority.
2 Likes
4

The head of Securitize is now advocating for something along these lines.

This seems like a prime opportunity for marketing Algorand to the burgeoning RWA market. I hate tagging JAWs (poor man needs some rest), so I’ll pester @joe-p for his thoughts on the matter.

2 Likes
5

This could be implemented using a smart contract application:

Setup

  • BlackRock generates a key pair.

  • A box is created on BlackRock’s behalf inside the smart contract. The name of the box corresponds to their public key. The contents of the box corresponds to their balance, initialized to 0.

Deposit

To send money to BlackRock, a deposit call is made by Alice, an Algorand address A. The deposit call involves sending the funds to the smart contract and including a message M that has been signed by BlackRock (signature is also included). (Instead of Alice, we could also have a fellow box address held by Bob. The same logic could apply for Bob to fund BlackRock’s box.)

Message M should contain something along the following : “I allow address A to fund me”. The smart contract should verify that it is indeed address A that sent money, to prevent a replay attack by a malicious spammer copy+pasting M and signature. The smart contract also checks the signature against BlackRock’s box name.

If all goes well, the smart contract updates BlackRock’s box contents, incrementing the balance by the funds sent.

If BlackRock wants more control - rather than give Alice blanket-authority to send them funds in perpetuity - they could add more to the message M. For example, the fund amount should be added - maybe BlackRock only accepts funds above a certain amount.

Or a nonce (a random number) could be generated for each transaction and appended to the message M. Then after the deposit has gone through, the smart contract could store the nonce as the name of an empty box. The next time the SC would check and see if there is a box with that name and reject immediately (box names need to be unique). In this way, each transaction needs to be approved; there’s no way to repeat the same nonce twice.

Withdrawal
In order for BlackRock to spend the money it could make a withdrawal call. The withdrawal call would have the SC either send the money to an Algorand address, e.g. Alice, or to another box inside the smart contract (assuming BlackRock provides the necessary proof that they have permission).

Regarding the key pair

The Algorand AVM can “officially” verify the following type of signatures:

Ed25519 is a no-go because it is the same as the Algorand blockchain. A malicious spammer Sam could simply take BlackRock’s public key, transform it into an Algorand address and fund that address. BlackRock would have de-facto control over those funds - having proven knowledge of the secret key controlling the public key - even if they never asked for them.

Secp256k1 is what is used in Ethereum and Bitcoin. An adversary could simply fund them on those networks instead and claim that BlackRock has received the funds. But at least they’re safe in the Algorand world.

Secp256r1, also known as P-256, is actually supported on certain other blockchains like Tezos. (Tezos supports all 3 aforementioned variants.)

You could choose to use RSA here, implementing a custom solution in AVM (TEAL). I don’t think there’s a blockchain out there that relies on RSA lol.

However, interestingly the post-quantum signature scheme Falcon (which is used in state proofs) is available as an opcode in vFuture. I.e., an opcode that can be experimented with in your local sandbox environment, but one that is not yet in Mainnet. Now that would be interesting to see.

Of course you could take this ad-absurdium - what if I specifically created a new blockchain using Falcon as the signature scheme just so I could send funds to an account only BlackRock could in theory spend from?

Okay but what if the PK is longer than allowed box name length?

You can do a SHA512/256 hash of the PK and have that be the name instead. And then each time a signature is to be verified, the PK gets supplied as part of the deposit call and the SC does a hash in ad-hoc to get the box name.

Alternatively, they first X bytes inside the box could be dedicated to holding the public key, and everything after is dedicated to holding the balance. Then the box name could be something completely random and the PK is extracted out of the box ad-hoc to verify the signature.

What if spammer Sam just sends the funds to the smart contract?

Well the SC would hold the funds but BlackRock would have no control over them. Unless the SC’s logic allows for it, they would have as much control over them as they had when the funds were in Sam’s address.

2 Likes
6

Thank you HashMaps. So, if I’m reading this right, the ability to whitelist already exists, it is just that it would require setting up a box/smart contract for each allowed sender. And, further, the funds would not be automatically deposited into the recipient’s account, but rather would require the recipient to call the contract to claim the funds.

Is that right? If so, that’s better than no control, but still has some added friction.

Also, is there a method for employing a blacklist? Eg, a box/smart contract to which anyone (except certain designated accounts) can send funds that can be withdrawn by the recipient?

1 Like
7

Thank you HashMaps. So, if I’m reading this right, the ability to whitelist already exists, it is just that it would require setting up a box/smart contract for each allowed sender. And, further, the funds would not be automatically deposited into the recipient’s account, but rather would require the recipient to call the contract to claim the funds.

Yes. It would be a flavor of account abstraction. I’d visualize it like building a skyscraper in the middle of suburbia. Instead of 1 Address = 1 Entity you have 1 Address = Many Entities. And instead of a delivery person having immediate access to your front porch, they’d need you to buzz them in.

Is that right? If so, that’s better than no control, but still has some added friction.

Indeed. If this is indeed a major concern and barrier to adoption for a large enough number of entities, then it would definitely behoove us to look into a solution on the “L1” ledger.

For example, there could be something similar to an opt-in flag for Algo itself (the ultimate ASA!). Let’s call it an address guard flag. An address could raise it to ensure no one can send it Algo.

Later, whenever the entity wants to make a trade they could construct an atomic group as follows:

  1. BlackRock Lower Guard
  2. BlackRock Send X to Counterparty
  3. Counterparty Send Y to BlackRock
  4. BlackRock Raise Guard

I believe @joe-p is doing something similar called “flash re-keying” in the ARC-0058 proposal Plugin-based Account Abstraction.

Regarding changing the opt-in in general, I have expressed my thoughts on how the opt-in feature could be improved in this post and I would appreciate any feedback.

Also, is there a method for employing a blacklist? Eg, a box/smart contract to which anyone (except certain designated accounts) can send funds that can be withdrawn by the recipient?

The problem with blacklisting a specific address or groups of addresses is that anyone could trivially generate another address, send the money to it and then from it send to BlackRock.

You could devise a queuing system that would allow anyone to send transactions to BlackRock but they are “kept to wait in the lobby”. BlackRock has a certain amount of time to act on those transactions, e.g. explicitly accept or reject them, and after the time ends some default outcome takes place (a passive accept or reject).

So transactions that are clearly strange, e.g. coming from someone who has sent the funds through a mixer, could be rejected, the money either lost forever (burned), claimed by a 3rd party or made available for the original sender to claim themselves.

Incidentally, this is one technique to make legally compliant mixers - have the deposited funds be frozen for a set period of time, during which law enforcement or some other trusted entity are allowed to order them “rejected” (confiscated/burnt/returned).

2 Likes
8

Yes. It would be trivial to evade. I was thinking about it from the perspective of how OFAC normally works, where certain entities get blacklisted. But in crypto it’s easy enough to evade this setup. So I could see whitelisting rather than blacklisting being the preferred solution.

One thing that shocks me is how little consideration the big brains at Blackrock and Securitize seem to have put into this issue. If they had, they wouldn’t have been so shocked when they got flooded with poopoodoginu and tornado bucks. Even if a protocol change isn’t in the works, it seems like a great opening for Tradfi marketing since we already have solutions to both of these problems.

Thanks for taking the time to discuss.

2 Likes