Pectra is the first major upgrade of Ethereum after Dencun, covering the Prague execution layer hard fork and the Electra consensus layer update, integrating the 11 EIPs in history, significantly improving the flexibility of validators, network scalability and execution efficiency. With the Ethereum mainnet Pectra hard fork expected to be officially activated on May 7, 2025, the "ultimate form" of Account Abstraction, EIP-7702, has also officially entered the public eye!

If there are any EVM-based Web3 wallets that do not support EIP-7702, then there is no doubt that they have given up the entire Ethereum ecosystem and users. This is the determination of Vitalik and EF, and it is also the prelude to the opening of Pandora's Box! At present, in order to support the Ethereum ecosystem, OKX Wallet has taken the lead in supporting Ethereum's latest account abstraction standard EIP-7702, and has opened an official entrance for users who are willing to try it out. You can upgrade through [OKX Wallet Home Function Area-More-7702 Upgrade] to experience the safe and professional EIP-7702. Warm reminder: You can choose to upgrade and experience as needed. Not upgrading will not affect the normal use of the existing ecosystem and applications. To ensure the safety of assets, be sure to operate through official channels, beware of phishing links and malicious websites, and avoid risks to assets.

Please follow this article to fully understand the evolution of account abstraction, the user value and market changes brought about by EIP-7702, and the hidden dangers.

Overview

The code involved in this article is located in okx/js-wallet-sdk. The EIP-7702 SDK implementation used by OKX Wallet is open source to community partners.

EIP-7702 adds a new transaction type that allows ordinary EOAs to set a contract address as their logical proxy contract.

EIP-7702 will fully inherit and surpass the ecosystem built by ERC-4337 over the years due to its “cost advantage” and “flexibility”.

EIP-7702 is also an invisible risk for ordinary users. Even if users do not upgrade, it may cause transaction failures or security asset loss risks in certain scenarios.

· EIP-7702 will bring a new user experience. When the user body undergoes contractual migration, market applications will also evolve accordingly. The long-awaited smooth experience of gas abstraction, family tiered accounts, etc. will lead one billion people to enter the Web3 world at a low cost.

For trading platforms and DApps, applying the features of EIP-7702 will bring more than 50% cost reduction, allowing them to fully embrace the era of contract accounts.

Why do accounts need to be abstract?

It’s hard to imagine that the vision of account abstraction even predates Ethereum itself.

At the HK Web3 Carnival, Vitalik repeatedly emphasized that through a series of solutions such as multi-sig, account abstraction, and ZK Email, Ethereum has achieved 50% of its "iPhone moment" goal.

Is it fast or slow, optimistic or limited? Let's go deep into the bottom and see why AA has such an influence! After all, after 10 years of running, Vitalik finally ushered in the end of his dream in the field of AA, adding a strong stroke to the progress bar of the Ethereum roadmap drawn in 23 years.

What is account abstraction for?

In fact, what is essentially solved is the problem of separation of property rights, because the ownership and signing rights of EOA (Externally Owned Account) are actually held by the same individual unit (both rely on private keys to control any instructions). The root of this problem comes from the transaction structure of Ethereum. In fact, there is no From party in Ethereum's standard transactions. During execution, the From address is deconstructed through its VRS parameter (ie user signature).

Moreover, Ethereum is designed as a "world-class state machine" that completely relies on transactions to implement changes in on-chain status. Combined with the inability to specify the From party, the execution authority of the transaction is coupled with the highest ownership.

This is the root of a series of problems that make EOA easy to understand but difficult to use:

Private keys are difficult to protect: If a user loses their private keys (due to loss, hacker attack, or quantum cracking), they will lose all their assets.

There are few signature algorithms, and different signature algorithms bring different performance losses and even the cost of on-chain storage.

· High signing authority, the EOA native private key has all these rights.

· The handling fee for complex transactions is high. The handling fee can only be paid through ETH. Any transaction or single operation requires a basic fee of at least 21,000.

· Transactions are not private. Even though there was a confidential ERC-20 protocol proposed by Circle, it has not become mainstream.

Ultimately, today’s blockchain world is too complicated for users entering and exiting it. Users need to understand concepts such as Gas price, Gas limit, and transaction blocking (Nonce order), and hide complex information from regular users. This is the problem that EIP-7702 ultimately aims to solve.

What are the core differences between ERC-4337 and EIP-7702?

There are actually more than ten different proposals around AA, which I have explored before. In fact, after sorting out the overall situation, there are essentially two routes:

Route 1: Let the EOA address drive the CA address

ERC-4337 is a typical example in this regard. It can be summarized in one sentence: a new transaction object UserOperation is proposed, and the user sends this object to the memory pool, batches instructions in the form of bundlers, and executes transactions one by one through delivery contracts. In essence, it pulls the underlying transactions and account operations to the contract level for execution.

The execution principle is as follows:

Through the role of bundler, it can be said that this solution can solve problems such as batch transactions, gas-free, fewer signature algorithms, etc. However, it cannot solve the complexity and user transaction costs, as well as the single point failure risk of bundler and EntryPoint.

Because once the user migrates to ERC-4337, even if the demand of user2 in the above figure is just to make a Transfer transaction, the user transaction fee will double compared to EOA.

From the latest user data of CA and EOA, we can see that even if some users are high-end players, they are very dependent on various operations based on the on-chain CA, such as batch calls, etc. But if this is the case, why not just use ordinary CA?

The design of bundler allows it to avoid hard fork-level upgrades and be launched directly on the application layer, but ERC-4337 also brings double the cost of single point failure risk, and users also lose the original flexibility of EOA. Therefore, in the face of diverse user needs, it is obvious that users in the current market are not so fond of the ERC-4337 solution. The overall trend has dropped significantly in the past two years, even the peak number of users is far from the number of independent addresses of Ethereum 300M.

Of course, we are not criticizing the shortcomings of ERC-4337. Rather, the roles and concepts such as Paymaster and Gas abstraction developed on it along with its development are actually being applied again in EIP-7702.

The author believes that the development of any industry will not happen overnight. What is important is to discover patterns and summarize experiences from past ups and downs.

Route 2: Change the EOA address to a CA address

In fact, as early as November 2015, Vitalik proposed EIP-101, using contracts as a new structure for accounts. The address was changed to only have code and storage space, the handling fee was changed to support payment by ERC20, and the native token was changed to ERC20-like to store the balance through pre-compiled contracts (with functions such as deduction authorization). In January 2018, there was another EIP-859 plan. The core function was to use the code parameter attached to the transaction to execute the contract wallet deployment if the transaction party contract was not deployed. Finally, EIP-7702, which was further deduced from the EIP-3074 plan, was finally included in the Ethereum mainnet!

The concept and effect of EIP-7702 are actually very simple. It completes the initialization through a new transaction type. Later, users can allow EOA to temporarily and optionally have the function of a smart contract in a single transaction, thereby supporting batch transactions, gas-free transactions, and custom permission management in business. The most critical capability is to allow users to have temporary and optional space.

Moreover, multiple people can share the same logic contract, thereby greatly reducing the cost of user migration. To complete the setting of EIP-7702, users only need 8W Gas, which is about 0.06 US dollars, and to set up a new contract again or cancel the setting of the logic contract, only 4W Gas is required.

After completing the settings, it can significantly bring users a significant gas optimization during batch transactions. See the table below:

Of course, you may think, is it necessary to do two or even six token transfers?

Conventional users are used to doing one thing at a time, so it seems that there are not many scenarios. However, in diversified application scenarios such as Web3 Game and Web3 Pay, it actually happens very often, such as using copper coins (currency generated in the game) and silver coins (user recharge currency) together for consumption. Or participating in an event and consuming NFT tickets and entrance fees at the same time.

Even if we don’t imagine complicated scenarios and return to the most mainstream Swap demand on the chain today, there is also a demand for approval and transfer batches. Even now, we can make a small tool to simply help users quickly delete their useless approval authorizations. The effect is easy to compare, and obviously, the cost can be directly reduced by about 40%.

The core principle of EIP-7702

To explore why this effect occurs, we need to return to its principle. In fact, its core is two logics, which are divided into user settings and daily use.

Setting up the logical contract

The core process is as follows:

Step 1: Signature authorization. Use the private key of the original EOA to sign a special hash string. The content is composed of encoded chain_id, address, and nonce. Here, Address is the address of the logical contract to be set in the end, and Nonce is a strategy to ensure that the transaction is not replayed.

Step 2: Signature transaction. With the authorization information from the first step, anyone can construct a transaction of type 4, which can contain multiple authorization information and perform authorization settings for multiple addresses at one time.

Step 3: Broadcast on the chain. Then when the transaction completes the internal authorization, the logical contract will be effective.

There are more technical details here, you can refer to: OKX open source JS SDK implementation to see the underlying data encoding process. Of course, this solution actually also hides some security risks and complexities, which we will describe in detail below.

Execution of logical contract

Once you have completed the settings, when any transaction To address points to you, it will be the same as calling a smart contract. The system will "load" the code of the logic contract you originally set into the state of your current EOA to execute its logic.

We also use 2 scenarios to view:

The first one is that you call yourself

If you set up a highly secure and customizable smart contract like the OKX 7702 Smart Contract, you can specify the pre-written calldata to allow your current operation to complete multiple instructions at once. For example, you can complete Approve+Transfer or Approve+Swap at the same time.

Don’t underestimate it. Among the total 2.7 billion Ethereum transactions, there are about 75M Approve transactions. Based on 8W Gas per transaction, 46W ETH are consumed. Based on the ETH market price of US$1,700, it is close to US$800 million.

The second is when someone calls you.

In the past, Ethereum did not have the situation where someone else called the EOA address, but now you are a universal contract that can be fully customized. You can open sub-accounts and assign permissions, or you can set up a whitelist for a few Paymasters and allow designated accounts of DApp to initiate some transactions on your behalf, thus completely eliminating the dilemma of repeatedly popping up signatures in traditional blockchain applications.

What a powerful capability! This is why almost all mainstream wallets: OKX Wallet, Metamask, WalletConnect, Biconomy, BaseWallet, Rhinestone, ZeroDev, TrustWallet, Safe and other related teams are responding quickly to support.

Is EIP-7702 the end of account abstraction?

Yes, because this time users will choose him!

It’s not that EOA is not good enough. Objectively speaking, EOA is concise, simple and safe. But in this Prague upgrade, EOA will be better after the introduction of EIP-7702. Because of the cost and the experience. When Jobs took out the iPhone from his jeans pocket, those experiences were things that users didn’t expect at first, that they could play like this.

Account abstraction is actually an area that many chains are exploring and actively trying. For example:

Starknet, as a ZK-Rollup (Layer 2), has contract accounts as its default accounts and no EOA.

In zkSync Era, using AA accounts is the default method, and there is no need for the complicated steps of Bundler.

Nervos CKB is similar to the UTXO model, but it also allows all accounts to customize the validators used, stripping away the ownership and control rights.

Aptos/Sui, as an important role in Layer 1 of the Move system, although it is not an AA in the EVM mode, it also has the ability to customize accounts, allow modular signatures, multi-factor authentication, etc.

The EVM's Linea / Base / Mantle / Polygon / Arbitrum / Optimism, these related ecosystems, have not only completed AA support through ERC4337, but will also follow up on the EIP-7702 upgrade like the Ethereum mainnet. The infrastructure in the wallet and AA-related fields is paving the way for EIP-7702 in a more comprehensive way.

It optimizes the core experience of EIP-7702: batch transactions, Gas abstraction (i.e. Gasless and other gas-free solutions), and account custody. Service providers such as Coinbase, Metamask, Biconomy, Zerodev, Rhinestone, Ithaca, etc. fully support these.

These are all further adaptations from the ERC-4337 era, which is also a major advantage of EIP-7702. The final account entity is a form that belongs to both EOA and CA, so a large amount of infrastructure that once revolved around AA can be migrated and adapted.

Now let’s use a table to reflect the differences in the final effect layer between EOA, ERC-4337, and EIP-7702.

Objectively speaking, the Ethereum system has a much heavier historical burden than other chains. This is the reason why the community recently opposed Vitalik's changes to the EVM virtual machine, and it was also the reason why ERC-4337 had to be chosen in the early days. However, once there is a better choice (EIP-7702) that can achieve compatibility with historical burdens and excellent cost optimization, users will usher in the "iPhone moment".

With the transformation of the underlying form, the derived forms can be further imagined, such as

· Users can use Passkey or Google Account to control their wallets, and implement experience features such as conditional visa exemption.

· Users can implement recovery capabilities and retrieve private keys by setting up ZKEmail and other methods.

For large operators on the chain, multiple transactions can be integrated into one transaction, which can significantly reduce the block waiting time, make the on-chain swap faster, and reduce the risk of transaction failure through continuous transactions. Time has a huge impact on the user experience. As ETH ranks second in the consensus system in the entire blockchain world (second only to BTC), it cannot arbitrarily reduce the block time from 3s to 1.5s like BSC to improve the user experience. Therefore, the wallet tool based on EIP-7702 is the most important bridge for user experience.

Therefore, combined with our previous discussion on its underlying layer, it can be said that EIP-7702 is the ultimate form of account abstraction!

However, it is unlikely that all users will use it in the future, because its application needs to be cautious. After integrating complex intelligence, it actually brings a lot of security risks, and some attack methods are even very obscure. Therefore, after the activation of the Ethereum Prague upgrade on May 7, 2025, what users need most is a truly secure wallet, with technical expertise to protect it.

Is the Endgame over?

No.

Indeed, Pectra is the most ambitious upgrade of Ethereum so far, covering 11 EIPs, the largest number in history! And we have seen the many benefits of EIP-7702, and have made judgments based on the principles and data above. However, it is also after users participate in the selection that the market will usher in a chaotic battle.

The AA ecosystem has gradually shown a fragmented trend in its continuous development. Among them, the EIP that defines account abstraction from the framework has interface standards such as ERC-4337, ERC-6900, and ERC-7579, but there are obvious differences in user experience, interface specifications, and behavioral expectations between different implementations. Different wallet implementations focus on similar application scenarios and limited core functions, but each adopts incompatible design assumptions and implementation logic.

One of the most typical hidden problems is storage disorder. After the launch of EIP-7702, the storage space under the EOA account can be used by contracts, and the storage space is not exclusive to a single contract, but may be used by multiple smart account providers.

When a user initiates a "re-delegation" operation, the original account contract will be replaced by a new contract. However, the status data written by the old contract will not be cleared and will remain in the storage of the EOA. This means that the new proxy contract can access or even modify the storage data written by the old contract, which introduces the risk of "storage pollution" and may interfere with or even destroy the execution logic of the current contract.

Although there are many solutions in the community, such as isolating storage through namespace (ERC-7201) to reduce the impact of storage chaos, no matter which solution is adopted, there is still a lack of mandatory unified standards in the current ecosystem to ensure the uniqueness and security of nonce.

Another typical problem is the disorder of implementation standards. As revealed in this article: From fragmentation to unification: the necessity of smart account standardization

Today: Safe, Biconomy and ZeroDev have all implemented their own versions of the batch call function, but the function naming, interface parameters and result processing methods of the three are different. Among them, ZeroDev considers the situation where the batch call fails, while Safe and Biconomy do not handle such scenarios.

The industry's "separate approach" of standards will inevitably lead to a chaotic war. Users, dApps, and developers are all victims. Therefore, the launch of EIP-7702 is not only a technological innovation, but also an opportunity to establish a universal infrastructure for smart accounts. It provides us with a window period for "reconstructing consensus" and promoting the entire Web3 wallet ecosystem from functional diversity to structural unification, and achieving true sustainable development.

After EIP-7702 is activated, three essential security understandings

Now, let us switch to different perspectives and look at this system from the perspectives of users, DApps, trading platforms, and other organizations to see how it affects us. It will bring opportunities as well as risks. Only by understanding the risks can we enjoy the benefits of this system more perfectly.

Eip-7702 is very complicated. Is it okay if I don’t upgrade?

Of course, you can choose not to upgrade proactively, but there is a risk you need to be aware of. After the Prague upgrade, one of your message signatures may inadvertently put you in danger.

It is true that EIP-7702 has a strong phishing risk because its Authorization parameters are composed of: address, nonce, and chainid. If the chanid is 0, the signature authorization can take effect on any chain as long as the nonce is met.

From the specific implementation of the 7702 process in the OKX open-source signature SDK, we can see that in order to comply with the standard, the user ultimately signs a hash value: 0xabc, which is calculated as follows:

Keccak is the mainstream hash algorithm on Ethereum, which has the characteristic that any length of data can be calculated to a fixed length of 32 bytes. RLP is a set of information encoding methods, and Magic is a fixed value.

However, since the final result is a hash value whose specific content cannot be understood, if the user signs a message carelessly, and someone else can also carry your authorization to the chain to take effect, then you will be set with a code unconsciously, thus triggering a 0day level attack. And since set code is mandatory, you cannot assume that you have set a secure contract and it will not be replaced.

Therefore, secure wallets will prohibit users from signing an arbitrary hash value, and this has been the case before (because the hash value may also represent an ordinary transaction).

How can I protect myself if I mistakenly upgrade a risky contract?

This risk is also very common. After all, there is no way to ensure that you will not be phished. To protect yourself from this problem, you must first know the technical background that transactions in the Ethereum system must be in the order of nonce. Only if they are continuous can they be recognized on the chain. Therefore, there are two ways of attack.

The first case is that the hacker stole the next nonce value of your current address to sign the Authorization. The handling is also very simple. If you are attacked, please quickly use a customizable Gasfee wallet, such as OKX Wallet or other secure wallets, to quickly transfer ETH (to other secure addresses of yours). This action can transfer funds at the ETH level on the one hand, and replace the valid nonce value on the other hand, thereby invalidating the one in the hands of the hacker.

The second situation is that what the hacker stole may be a subsequent nonce value. In this case, it is possible that your current transfer will make the authorization in the hacker's hands valid. Since you are not sure what the nonce is, no operation can lead to absolute security. You can only transfer assets as soon as possible to protect yourself.

So it seems that EIP-7702 is more dangerous? Actually not!

For a system like blockchain, which truly returns user sovereignty to the user's private key, random signing at any time will lead to financial loss. But the key here is that, apart from the situation where large users are targeted and poisoned, most of the risks arise because users often have to use important private keys.

If you have already realized the combined function of family accounts and personal sub-accounts through AA, and set the available limit for each sub-account, then basically your main account only needs to be awakened when modifying system-level settings, and for regular daily use, only the small account is needed to solve the problem.

Why do some common transactions fail after the upgrade?

This often happens in wallet tools that do not support EIP-7702.

First, let me add a technical background. During the contract call process on Ethereum, the code field of the user's current address will be checked first. If there is content, the default accepted function will be used to execute the corresponding logic. Based on this, for ordinary users, if I have completed the contract settings of EIP-7702, then there will basically be a default acceptance function. Any ordinary ETH Transfer transaction will execute some contract logic, thereby increasing the overall Gas use. If the Gas Limit set for your ordinary transaction is 21000, then it will naturally fail.

Similarly, since many NFT projects will detect whether the recipient address is a black hole address (i.e. an address that cannot transfer assets) and thus prohibit transactions, if your acceptance function is not handled properly, it will also cause ERC20 and ERC721 assets to be unacceptable and lost. In this regard, it is recommended to set it up through a wallet that explicitly supports EIP-7702, or use a logic contract that has been highly audited and recognized by users, such as: https://github.com/okx/wallet-core

What other changes are there to Ethereum mainnet Pectra?

There are many voices in the market that think Ethereum seems to be lost? Why do many upgrades have nothing to do with users? Is this really the case? Let's take a look at other EIPs in this upgrade to find the answer. Chen Ran, EIP-7702 is the biggest upgrade change that users can feel, but there are 10 other EIPs that bring changes to the Ethereum ecosystem in different dimensions.

First of all, in terms of cryptographic support, EIP-2537 introduces the pre-compilation operation of the BLS12-381 elliptic curve, which can optimize complex cryptographic operations such as BLS signature verification, and provide higher security (120+ bit security) and computational efficiency (Gas optimization).

The staking scenario has many optimization points. Objectively speaking, staking does need to be optimized. Ethereum's validator cluster has been growing rapidly, and there are nearly one million validator staking addresses. This is because MAX_EFFECTIVE_BALANCE is limited to 32 ETH, and node operators need to create multiple validator accounts to manage larger staked assets, which leads to the existence of a large number of "redundant validators". Therefore, the maximum limit is increased through EIP-7251. For aggregated staking protocols such as lido, the number of controlled accounts can be reduced and the complexity of the system can be reduced, but this may aggravate the decentralization problem and make the ETH staking market more centralized.

After this upgrade, larger-scale node operators can merge multiple validator accounts, while also bringing more flexibility to small validators, such as increasing income through compound interest accumulation or more flexible staking increments. This is very important. Originally, after 32ETH was reached, if you generated 10 ETH of new income, you would not continue to stake ETH, because you still need to get 32 ​​to open a new account. But after this update, you can directly stake 42 ETH. Then obviously your compound interest income can return to the ETH system, which has the convenience of user experience and a certain foreshadowing of reducing ETH liquidity.

Finally, the L2 ecosystem has been greatly optimized. Ethereum has always been firmly on the road to the L2 ecosystem community. Other SVM and MOVE systems are essentially still developing their own L1s, and even exploring L2 on them has certain contradictions and conflicts. The root cause is that the high performance of these chains is relatively less dependent on L2.

In order to encourage more L2 to interact efficiently with the Ethereum mainnet, EIP-7623 has been used to increase the gas fee of calldata in transactions from 4/16 gas per byte to 10/40 gas. This will force L2 not to use calldata, but to use Blob more.

EIP-7691 is also used to increase the capacity of blobs in blocks to support larger L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs, target and max, which were used to indicate the target number of blobs per block and the maximum number of blobs per block.

In Cancun, the parameters were 3 and 6, and now after Prague, the parameters have become 6 and 9. In short, the capacity has been expanded.

Therefore, Ethereum uses L2's TPS to improve Ethereum itself, although there are many problems, such as dispersed liquidity, cross-chain complexity, emergency escape capacity, etc. Therefore, in the current Pectra upgrade, Ethereum is adding "highways" to L2, but how to solve "traffic management" and "charge standards for different highways" in the future is the most fundamental problem.

A glimpse into the future

This article is nearly 10,000 words long. We start from the development roots of account abstraction, and then go to the two routes and comparisons represented by ERC-4337 and EIP-7702. We then delve into the principles and mechanisms of EIP-7702, and analyze its advantages and disadvantages and adjustment effects on mainstream user scenarios.

I think “Not your keys, Not your money” is a great concept. EIP-7702 is not to subvert it, but to complement and improve it in another dimension, making it both sovereign and easy to use. As Yoav Weiss, a researcher at the Ethereum Foundation, said, “The next billion users will not write 12 words on paper.”

Then through the comparison between the two, it can be said that it has significantly optimized ERC-4337, giving users space and flexibility, so that it is easier to be recognized and used by users in the subsequent market. Once users begin to use CA as the on-chain entity, complex transaction types will emerge in large numbers on the EVM chain.

From this, we can see the shadow of the future. With the enrichment of underlying account entities and transaction types, many application experience problems that were once bottlenecks will also be solved. Users will no longer be forced to understand the logic of Nonce, Gas, etc., but will be simplified by entry service tools such as wallets.

Although facing the diversity of industry levels, which brings a certain degree of disorder in interface standards and storage space, the author is also optimistic that the more valuable the chaos is, the more likely it is to create a unified standard, and decentralized multi-games will eventually promote the development of the industry. It is for this reason that after EIP-7702 goes online, it will not immediately detonate the ecosystem on Ethereum, because it is a spiral technical upgrade. Often, such upgrades will be 2-3 years ahead of market applications, leaving it for the application layer to gradually ferment.

Moreover, starting from this upgrade, user security will be more dependent on the service quality of the entry tool layer. Open source is an important step to give users a sense of security. Therefore, the EIP-7702 underlying SDK implementation integrated by OKX Wallet is also open source, open to the test of the community and the market. There are also many wallets that maintain openness and are going further and further on the road of self-custody, giving users absolute autonomy with the fairness of open source.

Finally, going back to the Pectra upgrade itself, we can once again see Ethereum's thinking and persistence on the future direction. Now that the L2 grand strategy has entered a stable execution period, Ethereum's roadmap has undergone many changes in details in the past decade, but the core goal has always remained unexpectedly consistent: I hope to have a secure and decentralized green (POS) blockchain that is both highly scalable and easy to verify. The introduction of AA proposals such as EIP-7702 that effectively improve user experience from the hard fork represents Ethereum's constant exploration of how to improve the competitiveness of multiple chains while ensuring decentralization (even in the face of competition from new generation public chains such as Solana), and how to become an ideal supercomputer!

Welcome to join the BlockBeats official community:

Telegram subscription group: https://t.me/theblockbeats

Telegram group: https://t.me/BlockBeats_App

Official Twitter account: https://twitter.com/BlockBeatsAsia