# Architecture AllSet is a universal liquidity and settlement layer which allows users to deposit assets from one chain into another without using traditional bridges. Being built on top of [Fast](broken://pages/J26hp8766EpgiVNGw7bO), it connects fragmented liquidity across blockchains into a single verifiable layer, ensuring value can move freely while keeping the same security guarantees of traditional bridges: transaction integrity and immutability, decentralization, and robust validation. Read this section to learn about the inner-workings of AllSet and how we achieve the same guarantees *sans* bridges. If you're more interested in a dynamic interaction with AllSet, head to the [AllSet Portal](https://omniset.fastset.xyz/). ## AllSet protocol AllSet allows you to send assets across chains by depositing them on Fast and withdrawing them at a later time. When transferring assets between chains with AllSet, the workflow is straightforward. The sender connects their wallet to AllSet, selects the desired asset from their source chain, and specifies the token amount to send. AllSet and Fast interact to perform this operation securely, while settling any resulting transactions on Fast as well. Finally, the recipient receives an identical quantity of the same asset on their own target chain. The diagram in Figure 1 below depicts this flow.

Figure 1: AllSet high-level architecture.

Note that sending assets across chains with AllSet requires two flows **deposit** and **withdraw**. Deposit because the assets[^1] are going to be minted on Fast, and withdraw as the assets[^2] will be withdrawn from Fast to the target chain. We will discuss each flow separately. ### Deposit

Figure 2: AllSet deposit workflow.

{% stepper %} {% step %} **Send «Deposit transaction»** At the start of the asset movement, a **deposit** flow is initiated by the sender by issuing a deposit transaction. For example, `deposit(xAsset, amt, sender)`, which means sending to the sender's Fast account `amt` xAsset tokens, where xAsset is the representation of Asset on chain X. {% endstep %} {% step %} **Monitor «Deposit event»** AllSet Claim-Proof Generator, which constantly monitors Fast Contract X, detects the deposit event. Fast Contract X is a Fast contract responsible for receiving the deposit transactions from chain X to AllSet. {% endstep %} {% step %} **Send claim & proof «Deposit event»** Upon detecting the deposit, AllSet's Claim-Proof Generator creates two claims for the deposit: **i.** The deposit event is logged in some block hash. **ii.** The block hash resides on the canonical chain X. and a proof for each of them and sends all to a pool of AllSet verifiers. {% endstep %} {% step %} **Send signed mintClaim** Upon successful verification of the claims, the AllSet verifiers send to the Fast network a mint claim and a quorum of signatures for it. The mint claim specifies that an equivalent amount `amt` of the Asset's AllSet's wrapped version (omniAsset) should be minted to the sender's Fast account. The deposit flow ends with Fast settling the claim and updating the balance of the sender with `amt` omniAsset. {% endstep %} {% endstepper %} ### Withdraw

Figure 3: AllSet withdraw workflow.

{% stepper %} {% step %} **Send transferClaim and withdrawIntentClaim** Once the mint claim is settled on Fast and the sender chooses to withdraw, two claims are sent from the AllSet front-end to the Fast network: **i.** A transferClaim specifying that `amt` yAsset tokens have to be transferred from the sender's account to the target chain account (Chain Y Bridge Account). **ii.** A withdrawIntentClaim specifying the withdraw intent of the same amount `amt` yAsset tokens. And this begins the **withdraw** workflow. {% endstep %} {% step %} **Receive transferClaim and withdrawIntentClaim** AllSet, through its Relayer component, gets notified about the two claims: transferClaim and withdrawIntentClaim. {% endstep %} {% step %} **Relay «Withdraw intent»** Next, AllSet Relayer forwards the withdraw intent to Fast Contract Y, a contract responsible for the withdrawal transaction to the receiver's wallet. {% endstep %} {% step %} **Send «Withdraw transaction»** Once the intent is verified, Fast Contract Y releases the corresponding yAsset to the recipient’s wallet. The withdraw flow of amount `amt` of yAsset tokens to address `receiver` on chain Y is performed. Similarly to xAsset, yAsset denotes the representation of Asset on chain Y. {% endstep %} {% step %} **Monitor «Withdraw event»** As soon as the yAsset tokens are released to the recipient's wallet, AllSet's Proof-Claim Generator, constantly monitoring Fast Contract Y, detects the withdraw event. {% endstep %} {% step %} **Send claim & proof «Burn event»** The AllSet Proof-Claim Generator will then submit to the pool of AllSet verifiers two claims: **i.** The withdraw event is logged in some block hash. **ii.** The block hash is in the canonical chain Y. and a proof for each of them and sends all to a pool of AllSet verifiers. {% endstep %} {% step %} **Send signed burnClaim** Upon successful verification of the claims, the AllSet verifiers send to the Fast network a burn claim and a quorum of signatures for it. The burn claim specifies that an equivalent amount `amt` of the Asset's AllSet's wrapped version (omniAsset) should be burned from the Chain Y Bridge Account. {% endstep %} {% endstepper %} ## Revoke Typically, AllSet operates through two core workflows—deposit and withdraw—we have seen above. However, there are cases when you may want to cancel a *withdraw* that hasn't been fully processed. These situations are handled through the **revoke** workflow.

Figure 4: AllSet revoke workflow.

{% stepper %} {% step %} **Send revokeClaim** Once the sender chooses to revoke a withdraw, a claim is sent from the AllSet front-end to the Fast network: a revokeClaim to cancel a previously initiated withdraw. {% endstep %} {% step %} **Receive revokeClaim** AllSet, through its Relayer component, gets notified about the revokeClaim. {% endstep %} {% step %} **Relay «Revoke intent»** Next, AllSet Relayer forwards the revoke intent, together with the previous transferClaim (received at Step W2 during withdrawal) to Fast Contract Y. {% endstep %} {% step %} **Send «Revoke transaction»** Fast Contract Y verifies whether the transferClaim has been used before or not for withdrawal. If not, then it revokes it. {% endstep %} {% step %} **Monitor «Revoke event»** As soon as the revoke transaction has been sent, AllSet's Proof-Claim Generator, constantly monitoring Fast Contract Y, detects the revoke event. {% endstep %} {% step %} **Submit claim & proof «Revoke event»** The AllSet Proof-Claim Generator will then submit to the pool of AllSet verifiers two claims: **i.** The revoke event is logged in some block hash. **ii.** The block hash is in the canonical chain Y. and a proof for each of them and sends all to a pool of AllSet verifiers. {% endstep %} {% step %} **Send signed transferClaim** Upon successful verification of the claims, the AllSet verifiers send to the Fast network a transfer claim and a quorum of signatures for it. Finally, the asset transfer from the Chain Y Bridge Account to the sender's account is performed. {% endstep %} {% endstepper %} ## Conclusion The AllSet workflow ensures that every deposit and withdrawal is fully backed and that total liquidity across all connected chains remains balanced. Each cross-chain action happens through verifiable claims and proofs instead of traditional cross-chain consensus. In this setup, AllSet verifiers and relayer play a key role by monitoring deposits and withdrawals, verifying proofs, and confirming that every transaction is backed by real assets. By separating deposit, revoke, and withdrawal into independent, verifiable actions, AllSet provides a robust structure for liquidity flow while maintaining full transparency through Fast's claim-proof system. [^1]: Actually, an AllSet representation of the asset is going to be minted. [^2]: Actually, an AllSet representation of the asset is going to be burn. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.fast.xyz/allset-archived/architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.