XION: The Generalized Abstraction Layer

Burnt Research
Draft-Release, December 7, 2023

Abstract
We propose XION, the Generalized Abstraction layer that enshrines user experience (UX) at the protocol
level. This enables secure, intuitive, and seamless user experiences through protocol-level implementations
related to abstracted accounts, signatures, fees, interoperability, and more. Combining the modular design
of XION’s meta accounts, their signature agnostic implementation, and XION’s parameterized fee layer
offers a composable, future-proof infrastructure layer. XION simplifies the developer experience and
enables a user-centric environment that retains the decentralized ethos of blockchain technology, while
significantly lowering the entry threshold for mainstream users. Through abstracted interoperability, we
additionally propose a solution to extend the seamless user experience of XION to all connected chains,
and explore several novel use-cases it enables.

1 Introduction tion is built upon the seamless integration of complex

blockchain functionalities – such as accounts, sig-
natures, fee management, and interoperability –
Technical challenges impede the widespread adop- directly at the protocol level. XION eliminates
tion of blockchain technology. New users encounter significant barriers to entry for new users, while
confusing complexity involving wallet setup, manage- circumventing fragmentation challenges for develop-
ment, cross-device usage, purchases, gas fees, multi- ers. Its signature-agnostic infrastructure supports
chain interactions, and more. While blockchains a wide array of existing cryptographic curves and
hold immense potential, their widespread adoption is readily adaptable to future developments, which
is precluded by these complexities. Such intricacies not only broadens its market reach but also assures
contribute to high user drop-off rates and low user long-term viability and interoperability across dif-
interest, suggesting the need for a user-friendly ferent blockchain protocols. Through abstracted
blockchain infrastructure. Proposed solutions, such interoperability, XION is able to offer a seamless
as the introduction of account abstraction1 , have experience not only for native applications, but also
attempted to alleviate these issues. However, im- those built on connected chains.
plementations which avoid consensus-layer changes
have resulted in fragmentation issues23 , significant
The remainder of the paper follows this structure:
deployment and execution costs, centralization Section 2 presents a background of the technical con-
risk, miner-extractable-value (MEV) capture4 , andcepts XION relies on; Section 3 presents Generalized
censorship1 . There currently doesn’t exist a holistic
Abstraction which includes meta accounts, signature
solution to bridge the gap between the industry’s abstraction, device abstraction, a parameterized fee
technical complexities and mainstream appeal. layer, and enhanced token minting dynamics; Sec-
tion 4 presents abstracted interoperability; Section
This paper explores the novel architecture of 5 presents novel use-case examples; and Section 6
XION. The Generalized Abstraction layer’s founda- concludes.

1
2 Background by a predefined set of rules at the state machine level,
account abstraction delegates this task to SCAs.
SCAs can then implement customized authentica-
2.1 Externally Owned Accounts
tion logic as needed, such as accommodating key
In general, blockchains have two types of accounts: rotation, performing autonomous tasks, integrating
1) externally owned accounts, and 2) smart con- multiple-factor authentication, and much more.
tract accounts5 . Traditionally users interact with
blockchains through externally owned accounts
(EOAs) which involve the use of asymmetric cryp- 2.3 Signatures
tography. These accounts have a public/private Cryptographic signatures are created using a digital
key pair, whereby the public key is stored on the signature algorithm, which involves a set of mathe-
blockchain, and the private key is stored off-chain by matical operations. The most commonly used sig-
the user. The private key, known only to the user, nature schemes in Web3 are Elliptic Curve Digital
is used to sign transactions, while the public key is Signature Algorithm (ECDSA)6 and Edwards-curve
used to verify the signature’s authenticity. Digital Signature Algorithm (EdDSA)7 . Ethereum
and Bitcoin use ECDSA, specifically leveraging the
EOAs, however, have many drawbacks: they Secp256k1 curve58 , while Solana uses EdDSA, specif-
lack the ability to implement additional authen- ically leveraging the Ed25519 curve9 . Another widely
tication mechanisms, they aren’t able to perform accepted cryptographic curve, Secp256r, is used by
autonomous operations or smart contract executions, most popular consumer devices such as Apple’s Se-
and a private/public keypair can not be changed. cure Enclave10 and Android devices11 .
As a result, EOAs are a central point of failure for
users. If a user loses access to their private key, they
lose access to their account entirely. Similarly, if a 2.4 Transactions
user’s private key is compromised, their account is
irreversibly compromised. Within the standard Cosmos SDK12 , each transac-
tion is composed of messages. Once a transaction
is set to be included in a block, it goes through a
2.2 Smart Contract Accounts unique component called the AnteHandler. The An-
The second type of account, smart contract accounts teHandler is responsible for executing specific checks
(SCAs), are governed by code on the blockchain. and operations through a series of functions, known
Their creation involves being deployed to the as decorators, which are executed prior to each trans-
blockchain through a transaction initiated by an action. These ensure the validity of the transaction,
EOA. Once deployed, these smart contracts reside at signatures, fees, nonce verification, and more prior to
a specific address on the blockchain and their code the transaction execution. Once the messages have
dictates the rules and conditions under which they been executed, a PostHandler is invoked with its own
operate. These rules are executed autonomously set of decorators. These decorators are designed to
when certain conditions are met or when they are execute logic such as events, logs, post-transaction
triggered by transactions or other smart contracts. logic, and more after a transaction has been processed
Traditionally, they are unable to initiate transactions and prior to committing it to the block.
due to an absence of private keys.
2.5 Transaction Fees
As a solution to EOA drawbacks mentioned
above, account abstraction has been proposed as a Transactions fees, often referred to as ”gas”, are used
way to enable SCAs to initiate transactions1 . Rather to measure the amount of computational work re-
than having transaction authentication determined quired to execute a transaction. Traditionally, each

2
transaction consumes a certain amount of gas de- login systems. Users interact with their accounts in
pending on its complexity and the computational re- familiar ways such as through email or biometric
sources it requires. Validators, who are responsible authentication methods, eliminating the need for
for confirming transactions and adding them to the direct private key management, while still remaining
blockchain, set a minimum gas price. Users who want fully non-custodial.
their transactions processed must pay at least this
minimum gas price. The total fee a user pays for a XION’s modular meta accounts framework in-
transaction is calculated by multiplying the amount troduces a highly adaptable and secure permission
of gas used by the gas price. Users include the gas fee management system, with the ability to support
in their transactions and it is paid in the native token advanced features such as key weights, key rotation,
of the blockchain they are using. When a transaction rule sets, and a variety of authentication meth-
is included in a block, the gas fee is deducted from ods. This system offers significant versatility and
the user’s account and awarded to the validator who enhanced security for account management:
included the transaction in the block. As covered in
Section 3.4, XION’s parameterized fee layer imple- • Key Rotation: A parameter integral to main-
ments significant changes in order to abstract away taining security by proactively reducing the risks
complexities for end-users, provide frictionless gasless associated with potential key compromise by en-
experiences, and enable token agnostic payments & abling the changing of account keys, thus limit-
denominations. ing the duration of their exposure.

• Rule Sets: A parameter enabling account holders

3 Generalized Abstraction to set any number of custom rules that govern
the account, ranging from transaction limits to
Generalized Abstraction is a unique and all- recurring payments.
encompassing infrastructure solution aimed at re-
moving inherent crypto complexities for all users. • Key Weights: A parameter enabling different
The crux of this innovation is XION’s implemen- levels of importance or authority to each key,
tation directly at the protocol level, which seam- allowing for a nuanced access control system
lessly abstracts accounts, signatures, gas, interoper- within the account, where certain actions require
ability, pricing, devices, payments, and more. In do- keys with higher weights.
ing so, through a holistic approach, XION lays a ro-
bust foundation for the next-generation of projects to • Diverse Authentication Methods: By support-
bring the promises of Web3 to mainstream audiences ing a range of authentication methods, meta ac-
worldwide. The sections below detail the different counts achieve both interoperability across dif-
facets of Generalized Abstraction. ferent devices & platforms, resilience against
evolving cryptographic threats, seamless support
3.1 Protocol-Level Account for cryptographic innovations, and ensures ro-
bust protection for user accounts.
Abstraction: Meta Accounts
XION introduces meta accounts, through a protocol- • Multi-Factor Authentication Framework: A
level implementation involving smart contract multi-factor authentication framework enables
accounts (SCAs) and state machine changes13 . a flexible and robust security structure, ensur-
These meta accounts streamline user interactions ing that access and control within the account
by decoupling the conventional private-public key adhere to specific, customizable parameters de-
model and enabling the creation of more intuitive fined by the user or organization when executing
user interfaces that align with traditional Web2 transactions.

3
 Figure 1: SCA Signature Verification Decorator

3.1.1 Smart Contract Account over existing SCA solutions. Up to 256 different au-
Implementation thenticators can be added to a user’s meta account.
When a user creates an account or logs in within the
In order to enable smart contract accounts to sign,
decentralized application, rather than being hard
the responsibility of transaction authentication must
coded into the protocol, signature verification is
shift from the state machine to the smart contract ac-
implemented through a dynamic request transmitted
counts (SCAs). This is achieved by integrating two
to a user’s account. This enables transaction veri-
critical methods into SCAs: before tx and after tx.
fication with arbitrary logic and state, establishing
Prior to a transaction’s execution, the state machine
XION as a future-proof, curve-agnostic protocol. By
calls the before tx method, which provides the SCA
utilizing arbitrary logic for transaction verification,
with detailed transaction information and its sign-
XION is not limited to any specific verification
ing credentials, allowing for signature verification and
schema. As a result, XION seamlessly supports var-
other programmed actions. Following the transac-
ious cryptographic curves without requiring specific
tion’s execution, provided the before tx method and
adaptation or modification. This stems from XION’s
all transaction messages have been successfully exe-
unique approach to abstraction, which separates
cuted, the after tx method is activated, enabling the
the underlying cryptographic mechanisms from the
SCA to perform additional programmed actions.
user-facing interfaces, thereby enabling the system’s
seamless adoption of different cryptographic curves.
3.1.2 State Machine Implementation
The state machine updates involve two decorator XION’s Generalized Abstraction layer supports
changes in order to trigger the SCA’s before tx and af- a wide spectrum of curves, including well-established
ter tx. The SigVerificationDecorator is updated with ones like Ethereum’s Secp256K1 and Solana’s
a new decorator which triggers the before tx method Ed25519, alongside such widely adopted standards
when SCAs sign, or simply proceeds with the default as Secp256R1 and RS256 used by JSON Web Tokens
SigVerificationDecorator logic. This is demonstrated (JWTs). In addition, it is able to support any
in Figure 1. An additional decorator is then added new future cryptographic curves as well, ensuring
to the PostHandler to trigger the after tx method. it can adapt to emerging trends and developments.
Developers building on XION can trust that their
smart contract accounts will remain compatible
3.2 Signature Abstraction and adaptable as cryptography continues to evolve
XION’s curve-agnostic implementation extends its quickly.
SCA capabilities, offering significant advantages

4
3.3 Device Abstraction the fee collector, swapping these non-native tokens
for the native XION token, and distributing the
Combining the implementations above, XION abol- resulting native tokens back to the fee collector. As
ishes the need for a user to store and manage private covered in the subsequent Section 3.5, the resulting
keys. This approach eliminates the safety risk, native tokens in the fee collector are then utilized to
complexity, and friction traditionally present when determine the chain’s inflation.
users attempt to use their accounts across multiple
devices. Consequently, XION’s unique approach There are a variety of ways for the collected
renders it device-agnostic as users can interact with fees to be swapped for the native XION token,
their accounts seamlessly across various devices, opening up interesting fee market possibilities. One
including computers, smartphones, or tablets. This implementation is such that the exchange rate is
universally accessible architecture significantly determined by using a time-weighted average price
streamlines the user experience, fostering widespread (TWAP) by periodically retrieving data from the
adoption by reducing entry barriers and enhancing desired decentralized exchange (DEX). In Figure 2, it
ease-of-use of all applications accessible from XION. is demonstrated using the Asynchronous Interchain
Query Module (Async-ICQ)14 .
When interacting with apps through XION, a
user is presented with multiple login methods
including email, social accounts, FaceId, or for
advanced users the option to log in with Web3 cre-
dentials such as Keplr or MetaMask wallets. XION
is therefore able to cater to all audiences, while
retaining seamless user experiences for non-crypto
native users. In addition, its meta accounts enable
additional security, flexibility, and ease-of-use such
as multiple-factor authentication, session keys, key
rotation, and more. In short, XION’s protocol level
account abstraction combined with its signature
Figure 2: Fee Abstraction
agnostic implementation enables users to seamlessly
access their accounts across multiple devices in a
safe and frictionless manner.
3.4.2 PlatformSend & FeeGrant

3.4 Parameterized Fee Layer Transactions on the network can be grouped into
two major categories, 1) value is exchanged, 2)
To enable many of the functionalities necessary to no value is exchanged. PlatformSend is enacted
create a seamless user experience, XION takes a new when transactions from the first category occur
approach to the handling of fees on the network which on the network. Since value is exchanged between
includes 1) implementing global fee abstraction, 2) participants, a portion of that value is taken as a fee
instituting PlatformSend, a new type of fee, and 3) to support the network and prevent sybil attacks.
combining them with the use of FeeGrant. Synonymous to the way gas fees mitigate network
attacks, the PlatformSend fee is a cost barrier that
3.4.1 Fee Abstraction requires an attacker to pay proportionally to the
value exchanged. This elegant design, demonstrated
XION allows the use of any token for transaction fees in Figure 3 allows users to transact directly in any
through its global fee abstraction. This is achieved currency of choice, without requiring gas tokens.
by accumulating the transaction fees paid by users in Then, utilizing the global fee abstraction outlined in

5
Section 3.4.1, the fees collected are swapped with the blockchain able to use USDC, a fully-reserved digital
native token in order to determine network inflation dollar, as its primary transaction currency15 . Fig-
and compensate network participants. ure 5 shows the dynamics of USDC fees in the fee
collector being auto-swapped to the native token, en-
abling all products built on XION to be denominated
and paid for by users simply using USDC. This elim-
inates the traditional friction of acquiring gas tokens
and allows users to seamlessly onboard with famil-
iar pricing, while simultaneously reducing unwanted
volatility and speculation. In addition, through its
parameterized fee layer, XION is natively interoper-
able with every connected ecosystem, as users have
the ability to pay in any token of choice. Combined
Figure 3: PlatformSend with the end-users’ gasless experiences, XION’s Gen-
eralized Abstraction stands out in its ability to reduce
friction and drive mainstream adoption of Web3.
When transactions occur from the second cate-
gory, regular gas fees are charged in order to prevent
network spam, and for these types of transactions
XION implements the FeeGrant. As demonstrated
in Figure 4, this allows developers to seamlessly
sponsor transactions on behalf of users and provide
a gasless experience. In addition, sponsoring can
be done in a variety of ways such as utilizing
staking rewards, employing a minimum transaction
threshold, or other configurable parameters. Figure 5: USDC Fee Swap

3.5 Token Minting Dynamics

The macroeconomic dynamics of a network are
shaped by the nuances of its token minting, and
these minting parameters are of utmost importance
for the long term viability of the system. Closely
tied to Generalized Abstraction’s parameterized fee
layer, XION’s design takes a first-principles approach
to token minting dynamics in order to balance net-
work participant incentives and long term sustain-
Figure 4: Fee Sponsoring ability. XION makes two substantial changes to the
Mint Module:

3.4.3 Result: Pricing & Payment • Accumulated fees are used to offset inflation,
Abstraction when possible.

Through Generalized Abstraction’s parameterized • Token inflation is calculated against staked to-
fee layer mentioned above, XION is the first kens only.

6
3.5.1 Mint Module Overview is represented as

The mint module’s goal is to maintain the pre- Tnet = Tminted + Fcollected
determined ratio of staked vs liquid tokens in an
ecosystem. This is achieved by setting three values: where Tminted is Ttotal × IR, and Ttotal is the current
the upper bound for inflation, the lower bound for total supply of tokens.
inflation, and the target staking ratio. Once the
inflation rate is determined, the module will then The first change XION has implemented is to
calculate how many tokens need to be generated in use the fees that have been collected in a block,
a block in order to meet the inflation percentage. It and offset how many tokens need to be minted
is an important balance to strike between market in the block by these accumulated fees. This is
liquidity and staked supply, as it impacts the long- demonstrated as
term security and growth of the network, and the
Tnet = Tminted − Fcollected
formulas below demonstrate this balance.
If Fcollected is significant enough, it can reduce Tnet ,
If Pbonded < Pgoal : IR = min(IR + ∆IR, IRmax ) thus effectively decreasing the inflationary impact
In this scenario, ∆IR is the rate at which the by using the fees collected to offset the newly minted
inflation increases when Pbonded is below Pgoal . tokens.

If Pbonded = Pgoal : IR = constant As chain usage increases, this will result in in-
In this scenario, when the bonded percentage is at flation decreasing as the accumulation of fees
the goal, the inflation rate doesn’t change. continue to offset the minting of new tokens. When
fee accrual exceeds the number of tokens per block
If Pbonded > Pgoal : IR = max(IR − ∆IR, IRmin ) necessary to distribute to stakers, then the extra
In this scenario, ∆IR is the rate at which the tokens are burnt and the token supply is thereby
inflation decreases when Pbonded exceeds Pgoal . reduced, naturally becoming deflationary.

Above, IR is the current inflation rate. Pbonded is 3.5.3 Token Inflation on Staked Tokens
the current percentage of staked tokens. Pgoal is
the target percentage for staked tokens. IRmax is Regarding token inflation, the default mint module
the maximum allowable inflation rate. IRmin is the calculates inflation against all existing tokens. This
minimum allowable inflation rate. can be represented as:

These formulas effectively capture the dynamic Tminted = IR × Ttotal

adjustment of the inflation rate based on the rela-
where Tminted is the total tokens to be minted, IR is
tionship between the current percentage of bonded
the inflation rate, and Ttotal is the total token supply.
tokens and the target bonded percentage, along with
the constraints of maximum and minimum inflation
As a result, annual percentage yield (APY) for
rates.
stakers can be represented as

AP Y = IR ÷ Pbonded
3.5.2 Offsetting Inflation With Fees
where AP Y ≥ IR as a function of Pbonded . This often
The default mint module currently takes fees accu- leads to a higher realized staking annual percentage
mulated in a block and passes them to validators, on yield (APY) than the inflation rate, since not all
top of the tokens that get minted every block. This tokens are staked.

7
XION’s mint module implements a significant
change. Instead of calculating against all tokens, it
calculates against staked tokens.

Tmintedx = IR × Tbonded

Since Tbonded is less than Ttotal , the total inflationary

impact Tmintedx will be less than or equal to Tminted
for the same IR.

The result is that inflationary impacts will be

reduced and stakers will always see AP Y = IR.
This change creates a much more stable environment,
ensuring the safety of the network by helping to
attract long-term participants.
Figure 6: Multi-Interaction to Host Chain

4 Abstracted Interoperability methods1718 . It establishes reliable, ordered, and

XION’s abstracted interoperability, a key aspect authenticated communication channels between
of its Generalized Abstraction, enhances the cross- separate blockchains. A package forwarding middle-
chain user experience significantly. This is achieved ware component is then instrumental in providing
through the use of package forwarding middle- practical user account control and management on
ware1618 that enables users to perform actions on different chains through the abstraction of account
any host chain from a controller chain, such as XION. interfaces, enabling seamless interaction with any
By integrating this middleware with the existing chain connected to XION as seen in Figure 7.
Generalized Abstraction framework, a streamlined
protocol-level interface is created. As demonstrated Combined with XION’s Generalized Abstrac-
in Figure 6, it allows users to perform actions on tion layer, abstracted interoperability extends all of
any chain that establishes a channel with XION, its protocol-level abstractions, facilitating new cross-
all while enjoying XION’s seamless user experiences. chain possibilities and seamless user experiences
previously unattainable.
XION’s approach to interoperability addresses
the common issue of account fragmentation in multi-
chain environments. A user can link accounts that
5 Generalized Abstraction
they own across multiple chains to their XION meta Applications
account, offering them a seamless way to manage
XION’s Generalized Abstraction layer enables both
their assets all from one central account. Each
vastly enhanced user experiences for existing appli-
account has a unique identifier, combining the source
cations, as well as enabling a range of novel ones.
chain’s identifier with the original account’s address,
Below, we start by providing a few non-exhaustive
ensuring a distinctive mapping across connected
examples of use-cases made possible by Generalized
chains. Users thereby maintain control over their
Abstraction on XION. We then provide additional
multi-chain accounts via a single XION interface.
examples of applications able to leverage abstracted
XION achieves this by leveraging symmetrical interoperability to enable innovative cross-chain use-
communication through several implementation cases.

8
 needing manual renewals. Creators and their fans
of all ages are able to frictionlessly create these ac-
counts, and access the content from all their devices.

5.1.4 Enhanced Gaming Experiences

An on-chain game leverages Generalized Abstraction
to enable the seamless use of session keys, batch-
ing of transactions, and gasless transactions to en-
able smooth and secure gameplay without endanger-
ing the user’s assets, all while reducing latency.

5.1.5 User-friendly DAOs

Figure 7: Multi-Chain Interactions from XION An online collaborative platform leverages General-
ized Abstraction to set up decentralized organiza-
tions where members have different permission levels,
5.1 XION Enabled Use-Cases enabling non-technical users to participate in gover-
5.1.1 Digital Banking nance or decision-making processes through intuitive,
familiar Web2 interfaces.
A digital banking application leverages Generalized
Abstraction to allow customers to set temporary ses- 5.1.6 Cloud Storage Services
sion keys for limited-time access, ensuring higher se-
curity for transactions while allowing the users to also A decentralized cloud storage platform leverages
define their own transaction limits and conditions. Generalized Abstraction to enable a family to seam-
These users can also set up multiple authentication lessly access their content across multiple devices.
method requirements for large transactions, as well Through the use of account permissions, family mem-
as the ability to recover account information should bers have different levels of access and editing privi-
they lose access to certain authentication methods. leges.

5.1.2 Global Venmo Messenger 5.2 Abstracted Interoperability

A decentralized messaging service leverages Gener- Extensions
alized Abstraction to enable users to safely access 5.2.1 Globally Connected Applications
their messaging chats seamlessly with the same ac-
count, whether they’re using a smartphone, tablet, orThrough abstracted interoperability, XION is able to
desktop. Users are able to transact globally, sendingtap into all existing Web3 applications. For exam-
assets cross-border through seamless gasless transac-ple, a user holds funds on the Base network from
their usage of the FriendTech app. This user now
tions directly within the messaging app using familiar
fiat denominations. wants to use StepN, a fitness app on Solana, and fund
their purchase of digital shoes using their FriendTech
funds. Using XION, they can seamlessly interact
5.1.3 Creator Economy Applications
and use StepN through their XION meta account
A decentralized content streaming service leverages which controls accounts on both Base and Solana.
Generalized Abstraction to create subscription-based In the background, the user’s Base funds are trans-
accounts, where users are automatically charged ferred, converted, and used to purchase the digital
monthly through smart contract triggers without shoes on a Solana marketplace. For the end user,

9
it’s a straightforward, seamless experience, showcas- 6 Conclusion
ing XION’s ability to make complex cross-chain in-
teractions user-friendly. XION addresses key challenges that have impeded
mainstream adoption through its Generalized Ab-
5.2.2 Global Decentralized Marketplaces straction layer. XION simplifies the user experience,
making blockchain technology more accessible to a
Users can participate in decentralized marketplaces broader audience. It removes the complexities asso-
spanning multiple blockchains, buying and selling ciated with account creation, interaction, transaction
goods or services with various cryptocurrencies, all fees, and interoperability, replacing them with famil-
managed through a single account with unified secu- iar interactions. In addition, it further extends this
rity policies and cross-chain payment capabilities by seamless user experience to encompass cross-chain
leveraging Generalized Abstraction’s abstracted in- interactions. Generalized Abstraction not only en-
teroperability. hances the XION ecosystem’s capabilities but also
contributes to the overall growth of the blockchain
industry by combining seamless connectivity with
5.2.3 Cross-Chain Gaming
widespread adoption. Through a multifaceted Gen-
Through abstracted interoperability, gamers can en- eralized Abstraction layer, XION offers a sustain-
gage in cross-chain gaming experiences where assets able, flexible, and user-centric blockchain infrastruc-
and achievements in one blockchain game can be used ture paradigm, capable of propelling the industry to-
or traded in games on other chains, all under one wards a new era of innovation and widespread accep-
unified gaming account. This gaming account can be tance.
easily accessed from all devices, given different levels
of access controls, and safety measures can be imple-
mented to eliminate the possibility of account loss.

5.3 DAOs
A decentralized autonomous organization (DAO) can
leverage Generalized Abstraction and abstracted in-
teroperability to seamlessly operate across multiple
blockchains. This allows it to effectively tap into dif-
ferent applications, a wider user-base, more flexible
and efficient governance, all made possible through
common Web2 methods for mainstream user engage-
ment.

5.4 Global Profiles

A cross-chain identity verification system can be es-
tablished, whereby users are able to interact across
multiple blockchains using the same credentials and
reputations. This enables a myriad of possibilities
as recognizable reputations allow users to access a
wide range of services through one verifiable identity,
bringing all ecosystems closer together.

10
References GitHub repository, [Online]. Available:
https://github.com/cosmos/ibc/tree/main/spec/app/ics-
1. V. Buterin, and Y. Weiss. “ERC-4337: Account Abstrac- 027-interchain-accounts
tion Using Alt Mempool [Draft].” 29 Sept. 2021. [Online]. 17. C. Goes, “The Interblockchain Communication Protocol:
Available: https://eips.ethereum.org/EIPS/eip-4337 An Overview,” Interchain GmbH. [Online]. Available:
https://arxiv.org/pdf/2006.15918.pdf
2. N. Mudge, “EIP-2535: Diamonds, Multi-Facet Proxy.”
18. Abacus Works, “Hyperlane v3 Docs,” Abacus Works, 2023.
Ethereum Improvement Proposals, Ethereum Foundation.
[Online]. Available: https://docs.hyperlane.xyz/
[Online]. Available: https://eips.ethereum.org/EIPS/eip-
2535.
3. F. Giordano, et al., “EIP-1271: Standard Signature Val-
idation Method for Contracts.” Ethereum Improvement
Proposals, Ethereum Foundation. [Online]. Available:
https://eips.ethereum.org/EIPS/eip-1271.
4. P. Daian, S. Goldfeder, et al., ”Flash Boys 2.0: Frontrun-
ning, Transaction Reordering, and Consensus Instability in
Decentralized Exchanges,” in 2020 IEEE Symposium on Se-
curity and Privacy (SP), 2020, pp. 914-931.
5. V. Buterin, “A next-generation smart contract and decen-
tralized application platform,” Whitepaper, 2014. [Online].
Available: https://ethereum.org/en/whitepaper/.
6. D. Johnson, A. Menezes, & S. Vanstone, “The El-
liptic Curve Digital Signature Algorithm (ECDSA).”
IJIS 1, 36–63 (2001). [Online]. Available:
https://doi.org/10.1007/s102070100002
7. I. Liusvaara, and S. Josefsson. “RFC 8032 Edwards-Curve
Digital Signature Algorithm (EdDSA).” Internet Engineer-
ing Task Force, Jan. 2017. [Online]. Available: https://rfc-
editor.org/rfc/rfc8032.
8. S. Nakamoto, “Bitcoin: A Peer-to-Peer Elec-
tronic Cash System.” Bitcoin. [Online]. Available:
https://bitcoin.org/bitcoin.pdf.
9. A. Yakovenko, “Solana: A new architecture for a
high-performance blockchain v0.8.13.” Solana Founda-
tion. [Online]. Available: https://solana.com/solana-
whitepaper.pdf.
10. Apple Inc., “Secure Enclave,” Apple
Support Guide. [Online]. Available:
https://support.apple.com/guide/security/secure-enclave-
sec59b0b31ff/web
11. A. Hamlin, “Secure Multiparty Computation.”
Comp 116, Tufts University. [Online]. Available:
www.cs.tufts.edu/comp/116/archive/ahamlin.pdf.
12. J. Kwon, E. Buchman, “A Network of Dis-
tributed Ledgers.” Tendermint. [Online]. Available:
https://v1.cosmos.network/resources/whitepaper.
13. L. Lyu, “abstract-account,” GitHub repository. [Online].
Available: https://github.com/larry0x/abstract-account
14. A. Raja, E. Saradar, “Asynchronous Interchain Query
Module (Async-ICQ),” GitHub repository, August 30,
2022. [Online]. Available: https://github.com/strangelove-
ventures/async-icq
15. J. Allaire, S. Neville, “Introducing USD Coin
(USDC) a Fully Reserved Stablecoin,” Circle
Blog, Sept. 26, 2018. [Online]. Available:
https://www.circle.com/blog/introducing-usd-coin
16. T. Yun, S. King, J. Lee, “Cosmos/ibc ICS-
027: Interchain Accounts Specification,”

11