As the blockchain ecosystem matures, better and more diversified ways of authenticating for blockchain transactions have emerged. This can be quite overwhelming to newcomers, and so this post aims to put order in the following terms:

• EOA
• MPC
• Account abstraction
• Paymaster
• Relay
• Key abstraction

EOA

EOA stands for Externally Owner Account. This is typically the simplest and original form of authentication: An end user creates a unique, secret, private key which can be held in an app (such as Metamask and Solflare) or better secured on a hardware wallet (such as Ledger). With that private key the user derives or creates an account on the blockchain. All transactions submitted to the that blockchain account, must be signed with the private key.

EOA private keys are often stored as a “seed phrase”: A series of words from which the private key can be derived.

EOA authentication is the only built-in authentication mechanism which most blockchains (including Ethereum) recognize. All the other methods detailed below build on top or around the EOA method in order to provide additional benefits.

‍

MPC

MPC stands for Multi Party Computation. It is a technology that allows a private key to be split up into parts (shards) such that the holders of several shards can together produce a valid signature of the private key, regardless of which shards are being used. For example, a private key could be split into 5 shards such that any 2 shards could sign a transaction. This would be annotated a 2/5 scheme - 2 signers needed out of a total of 5. Any 2 shards could be used to sign a transaction with the private key.

MPC has many uses - in this article we will consider the case that a private key is sharded and used to control an EOA. This can be very useful for a variety of cases:

1. The account is owned by more than one person (e.g. a company) and every transaction needs to be validated by several people
2. A user is worried about losing access to their account; they could store additional shards as backups, such that even if one shard is compromised, it will not risk the account being compromised
3. One or more of the signing shards would be owned by an automated service that would enforce policies on the account. For example, if an account has $1m in assets, the policy could prevent sending all of that amount, instead allowing only $10k to be sent out on any given day

Examples of MPC-based platforms include Fireblocks, a wallet infrastructure service, and Zengo, a non-custodial wallet.

While MPC is very useful for securing accounts, it still requires all related users to hold a shard with a very specific and technically involved signing scheme. For instance, each of these shards would likely require a “seed phrase” to be memorized and input into an app, in order to sign payloads.

Account Abstraction

The best user experience for authentication should resemble the one users are already accustomed to. Users typically use usernames and passwords, sign in with Google/Apple, have 2FA (2-factor authentication) methods set up, and more recently leverage passkeys. Account abstraction aims to allow users to continue using all of these options.

Instead of using an EOA account that must use a specific signature, the user could deploy a smart contract that would serve as their account. The smart contract is set up to validate a given authentication, such as sign-in with Google.

Sign-in with Google (and all the other authentication methods) can be used to sign transactions. The smart contract will accept any transaction, verify its signature, and if valid - will execute it.

This greatly improves authentication experience for end-users. However, blockchains like Ethereum do not have a concept of calling externally into a smart contract. There always needs to be an initial signed transaction from an EOA. That EOA also needs to pay the computation fee (”gas”) of the transaction - so account abstraction transactions cannot be submitted from outside the blockchain.

To solve that, we need some service to submit these transactions on our behalf, which we call a relay.

Relay & Paymaster

A relay accepts a transaction and executes it on behalf of another party. Typically, relays will ask for a small fee for that service. The relay usually also want to claim back gas fees, which can be paid back to them by the user, or the user might have a service they top up with gas to be used by the relay for the execution, called a Paymaster.

Two important notes about the operation of relays:

1. A relay cannot change the user’s transaction. There is very little risk giving the transaction to the relay, since it is signed by the user. Any attempt to change the transaction will invalidate the signature, and the relay is not able to authenticate with the user’s credentials in order to re-sign the transaction. The only risk a relay can pose is by not submitting the transaction (often called censoring the user).
2. A relay can use any EOA to submit this transaction. The EOA itself does not need to be known to the user’s account abstraction contract. That smart contract will accept a call from anyone, as long as a signed payload is provided.

Key abstraction

A lesser-known concept, but important to understand, is key abstraction. It is an alternative to account abstraction.

While account abstraction is an immense improvement in the UX, it is not very efficient because more processing happens onchain, consuming more gas. Furthermore, some on-chain services, especially on Ethereum, do not work well with account abstraction contracts for technical reasons.

It would have been nice if there was a way to use sign-in with Google (or any other auth method) in order to operate an EOA account. Some newer blockchains actually allow that, but even for the existing ones, there is a solution in the form of key abstraction platforms.

A key abstraction platform will securely store an EOA private key, and only allow access to it via another authentication method (such as sign-in with Google). This means the user authenticates the way they want, and under the hood that signature could be replaced with an EOA-compatible signature in order to submit the transaction.

But how can the a platform “securely store” the EOA private key without risking it falling in the wrong hands?

One way to do that is to use TEE (trusted execution environments). These are containers hosted in a very specific way (such as Amazon Nitro containers) that verify that they match exactly some pre-vetted container image and cannot be changed. The user can then push a private key into such a container as well as whichever other authentication methods they wish to use, and the container, if set up correctly, will perform this service for them, without leaking any other data outside.

Such platforms already exist - such as Privy or Turnkey.

Side note: key abstraction is closely related to the terms embedded wallet and wallet as a service. We plan to explore these terms and clarify them in a future post.

Final word

We hope this article helped clarify the different components from which a blockchain account system could be built. Do notice that these are not “either-or” solutions. In some cases different components can be used together in one solution.

For instance, MPC and key abstraction can be combined in different ways to create different types of products. The shards of an MPC can each be stored in a key abstraction platform, so that the result is an MPC account, but the authentication is done in whatever method the users want. This can be desirable when operating a shared wallet, or when operating a single-user wallet but not wanting to trust a single TEE with a full signing key.

This space keeps evolving and blockchains are building better authentication primitives to allow for better solutions. We will continue to follow the trends and update you!

The recent passage of the U.S. GENIUS Act (Guiding and Establishing National Innovation for U.S. Stablecoins) has sent regulatory ripples across the Atlantic. As the U.S. takes a bold step toward stablecoin regulation, European officials are parsing its implications for the EU's digital finance strategy. This post summarizes the reactions from Brussels and other EU institutions, and what they could signal for the future of transatlantic crypto policy.

Brussels Watches Closely: Strategic Opportunity or Regulatory Risk?

Following the enactment of the GENIUS Act, which establishes a comprehensive framework for the issuance and oversight of U.S. dollar-backed stablecoins, EU officials have been quick to respond. While there’s a broad consensus that regulatory clarity is welcome, reactions across European institutions reflect a blend of strategic caution and competitive awareness.

• European Commission (EC) - Cautious Validation: EC officials welcomed the move in principle. A senior official from DG FISMA noted that the U.S. stablecoin law "reflects a long-overdue commitment to serious digital finance regulation," but cautioned that it may accelerate "regulatory arbitrage pressures in Europe."Internal Commission briefings reportedly highlighted that GENIUS "validates the core logic of MiCA" (the EU’s Markets in Crypto-Assets Regulation) by requiring reserve backing, redemption rights, and prudential oversight for stablecoins. However, there is some concern that the U.S. framework offers "greater operational flexibility" for issuers, which could attract new entrants to the American market.

• European Parliament (EP) - Split views : EP members of the Economic and Monetary Affairs (ECON) Committee were split. Some MEPs praised the GENIUS Act as an important move toward global regulatory convergence. Others, particularly from the Greens and center-left S&D groups, expressed fears that the U.S. might become "a permissive haven" for dollar-denominated stablecoins unless supervision is strictly enforced.

The GENIUS Act’s multi-issuance provisions — allowing both bank and non-bank entities to issue stablecoins under specific regulatory conditions — were noted with interest in Brussels. Some policymakers view this as a potential competitive advantage for the U.S. system, given MiCA’s more cautious approach to non-bank issuance.

The ECB Sounds the Alarm: dollarization risk

The most vocal critique came from the European Central Bank. ECB board member Piero Cipollone warned in a recent speech that the GENIUS Act could "turbocharge U.S. stablecoin issuance" and lead to "a gradual dollarization of European digital payments." He called for urgent coordination within the eurozone, saying the ECB must "not be caught off guard by a wave of dollar-linked assets outpacing the digital euro."

President Christine Lagarde echoed these concerns more diplomatically, stating that while the ECB supports responsible innovation, "the risk of monetary fragmentation is real if non-euro stablecoins dominate retail transactions in Europe."This has reignited debate over MiCA’s adequacy in ringfencing the eurozone against foreign digital currency inflows.

The Transatlantic Outlook: Divergence or Dialogue?

The passage of the GENIUS Act is already influencing how EU officials are thinking about future legislation. One tangible impact: renewed calls within the Commission to reassess MiCA’s thresholds on foreign stablecoin issuance. Some voices within the EC are urging a faster rollout of the digital euro to mitigate dependence on dollar-based tokens.

At the same time, there is cautious optimism that GENIUS might revive stalled talks around U.S.-EU cooperation on crypto supervision. European lawmakers have long pressed Washington to deliver a harmonized framework, and now that one exists for stablecoins, there may be momentum to align supervisory practices.

As one senior MEP put it: "MiCA was first. GENIUS is faster. The question now is: can we meet in the middle before market fragmentation gets worse?"

Final Take

The GENIUS Act’s passage marks a pivotal moment in the global race to regulate digital assets. For the EU, it brings both a challenge and an opportunity: to defend the integrity of its digital currency regime while leveraging this moment to deepen international cooperation. Whether the transatlantic stablecoin landscape will converge or diverge may depend as much on political will as on policy architecture.

Stay tuned for more insights in the next edition of Regulatory Radar!

‍