The Illusion of Permissionless DeFi

By philpher0x

We checked 64 official DeFi interfaces: 92 countries and regions are blocked by at least one, 120 are named in the Terms. The kinds of blocking, where the checks run, and what it takes to get around them.

Tags: DeFi, Permissionless, Geo-blocking, Sanctions, Compliance, Smart Contracts, RWA, Research

  

Imagine a pond where you can fish, swim and do whatever you like. There is one problem: almost the entire shore is private property, fenced off, and you cannot get through.

You can introduce yourself as a neighbour and ask to be let in, but there are no guarantees. More often than not you end up walking around the fence, looking for a gap and pushing through the bushes.

That is roughly what access to DeFi looks like today. The blockchain is the pond, where banning anything is quite hard. The interfaces around the blockchain and its products are the private lots, and they decide whether you get to use the blockchain and the products at all.

Blockchain was built as infrastructure you do not need to ask permission to use. But governments are not going to give up regulating finance, and the companies that build the interfaces do not want to risk their licences, their money or the freedom of their employees. The result is a paradox: a protocol can be open to everyone, yet far from everyone can use it through the official interface.

As a result, web3 developers and companies, trying not to step on legal and financial rakes that pop up in the most unexpected places, are forced to build restrictions into their own products.

A world without borders, with 92 exceptions

If you think the only ones getting blocked are rogue countries and regions, dangerous hackers or wallets suspected of money laundering, think again.

We collected blocking data across 64 interfaces, and it turned out that 92 countries and regions appear in at least one block. In other words, almost half of the countries in the world are blocked in one way or another. That does not mean everyone is blocked equally. It means there is at least one block in at least one of the products we studied.

92 is what we confirmed in practice: in site code, in API responses and with probes through proxies. The number of countries declared in terms of service is even higher: 120 countries and regions, more than half of the world. 32 of the 64 interfaces publish such lists.

This no longer looks like the targeted isolation of North Korea or Iran. It is a much bigger phenomenon.

There are several reasons for the blocks:

  1. Sanctions or financial regulation in a country where the web3 product does not want, or is unable, to get a licence.
  2. Legal uncertainty: there is no direct ban, but there is a risk that the activity will be challenged and the product will be fined.
  3. A self-imposed ban: the product itself decides which regions it does not want to deal with. North Korea, for example, because its hackers could launder money through the product.

Which countries get blocked the most?

Describing the country blocks is not hard. The list of the unwanted almost coincides with economic sanctions. On top of that come the countries that projects fear or do not understand. It is hard to predict what to expect from the US or the UK, so better not to end up in a situation where you could get sued by them.

The chart shows the 20 countries blocked by the largest number of the 64 interfaces. The blue part is "the site does not open at all", the orange part is "the site opens, but some pages, assets or trading are closed". The top is as expected: Iran 27, Cuba 26, Syria 23, Belarus and Russia 20 each. But the United States sits at the same level, and unlike its neighbours on the list it has more partial blocks than full ones: 9 interfaces close the site, 11 hide specific assets from Americans, mostly tokenized stocks and RWA. Canada shows the same picture (5 and 7). The United Kingdom is 19th with 9.

What kinds of blocking are there?

There are only three: by geo (the user's location, the most popular one), by the user's blockchain address off-chain (screening), and by address inside a smart contract.

Of the 64 interfaces, 39 have a geo block, 26 screen the wallet address, 5 block in a smart contract. The categories are often combined: 19 have geo and screening together, 18 have geo only, 6 have screening only. Another 10 have the ban written only in their Terms, and for 6 we found nothing.

On the technical side, the blocks fall into these groups:

  • Hosting: the user cannot open the site, the CDN or the hosting returns an error before the app even loads, and the location is determined by IP on their side
  • Browser: the list of countries or addresses sits in the site's code, and the location is determined in the browser, through a third-party IP service or even the time zone
  • API: the user can open the site but cannot actually use it; the location check or the wallet screening happens on the backend

Smart contract: the user's address is blocked at the contract level

Of the 80 checks across the 64 interfaces, 49 run on the backend, 12 in the browser, 9 at the hosting, 5 in a smart contract, and another 5 are known only from the press or documentation. So "the location is determined in the browser" is the rare case; mostly the backend decides.

From the user's side the blocks look like this:

  • Site: the user cannot open the site at all: an error, a redirect or a "not available in your region" stub. 25 interfaces
  • Specific pages and tools: the user can open the site, but the functionality is limited: a section is closed, or assets such as RWA and tokenized stocks (this can happen at the browser level as well as at the API level). 19 interfaces
  • API: the user can open the site and browse it, but a quote or an order does not go through because of the country. 6 interfaces
  • Address screening: there is no geo check, or it is complemented by screening the address. If the address has been seen interacting with protocols like Tornado Cash, the product may block the action. 26 interfaces
  • Smart contract: the user gets as far as sending the transaction to the blockchain, but it is rejected by a block in the contract. It can be a blocklist (1 case) or the user being absent from a whitelist after KYC (4 cases, all RWA and stablecoins)

One interface can sit on several levels at once, so the chart shows the first barrier the user hits: for 25 it is a closed site, for 9 a page or an asset, for 5 an API refusal, for 6 screening only, for 3 a smart contract only. For the remaining 16 the ban is either only in the Terms or not found at all.

Can a user get around the blocks?

In most cases, yes.

As the charts show, only 5 of the 80 checks we found (6%) live in the smart contracts themselves. That is 5 of the 64 interfaces, and all of them are about RWA and stablecoins. But the trend is that more and more projects will turn to this kind of blocking.

To block a user in a smart contract you need a blocklist or a whitelist and a status check of the address at the moment of the transaction. That costs extra gas, so the transaction gets more expensive.

When transactions were much more expensive, a web3 project could not afford to keep extra data on-chain. Today the extra cost can be almost invisible to the user, which makes it possible to implement blocks and checks of almost any complexity on-chain.

Still, with a blocklist the user can switch to another address and avoid the block at the contract level. With a whitelist that does not work: a new address will not get onto it without KYC. In our sample there is one contract blocklist (frxUSD by Frax) and four whitelists: Ondo, Centrifuge, Superstate and the USDe mint at Ethena.

As for the other kinds of blocking, they are tied to the interfaces used to reach the smart contracts. Geo is bypassed with a VPN or a proxy in another country. But 26 of the 64 interfaces also screen the address, and there a VPN does not help: you need another, clean wallet.

Breaking down all 64 interfaces: for 18 a VPN is enough, for 25 you need a VPN and another wallet, for 1 another wallet saves you from a contract blocklist, for 4 a KYC whitelist cannot be bypassed, and for 16 there is nothing to bypass.

Checks on sites often include VPN and Tor traffic detection as well, which makes the bypass harder but not impossible. We found such detection in 6 interfaces: three block on it (Spark, EigenLayer, Extended), three only flag it. Sky makes you sign the terms before every transaction, Lido puts Tor users into a limited mode, Euler writes it to a log.

Besides, cp0x has its own permissionless interfaces (https://pi.cp0x.com), with no restrictions, which you are welcome to use.

Who suffers from the blocks the most?

As you can see, the fight against the blocks is in full swing. We want web3 and a permissionless blockchain. Code should be law, and freedom should be free.

An advanced user or a seasoned crypto native can figure the blocks out. Or do everything directly on-chain, without interfaces.

Web3 projects, in turn, are often unfriendly to newcomers, from the complexity of the concept itself to the way you interact with them. The situation is changing, everything has become far more accessible, but for the industry to really grow it needs the mass user.

For new users and for those who are not particularly technical, a good interface is vital. And it is just as vital for the whole crypto industry if it wants to attract those users.

Seeing a blocked page, a user will simply walk past, deciding that this particular project is not available to them. And if every third DeFi protocol blocks you, and in some countries every second one, wouldn't it be better not to get into this at all?

Let us hope the situation changes sooner or later. New permissionless interfaces will appear. Or, thanks to the AI boom and vibe coding, users will find new ways to interact with the blockchain, and no blocks will stand in their way.

Sources