*This article explains Across' architecture succinctly from first principles and then fantasizes about the spaces into which Across will grow* 💫

The Across protocol is defined completely by a [UMIP](https://github.com/UMAprotocol/UMIPs/blob/master/UMIPs/umip-157.md) and it embodies the UMA way of building decentralized software as hybrid on-chain plus off-chain architectures:
- Smart contracts are deployed that are able to receive proposals containing state modifications that can be executed after they undergo a challenge window and are optimistically validated
- Off chain actors interpret an off-chain constitution explaining the rules governing valid proposals. These are UMIPs. These actors compare the proposals against the UMIP to decide whether to challenge a proposal
- When the proposal passes liveness, the state modifications can be executed by the smart contracts

## Across is a fluid protocol
The Across protocol design has a minimal on-chain footprint and the smart contracts are strategically unopinionated. They instead provide space for protocol rules to be defined off-chain, where they can be more rapidly updated. This means that non-engineers can take on the responsibility for upgrading Across' fee model and capital allocation rules without having to push through contract upgrades on-chain.

This means that Across can continue to [upgrade its fee models](https://docs.across.to/how-across-works/fees) and capital efficiency in accordance with the latest research and data.

## Quick Across Refresher
In Across, the smart contracts provide a Hub for liquidity providers to deposit funds into and Spokes for users to submit bridge requests to. Bridge requests are queried as on-chain events by profit maximizing relayers who compete to fill the requests and request a refund plus reward.

Across proposals contain the following instructions
- Which relayers to refund and reward, and where to send the payment
- Where to reallocate liquidity provider capital to fulfill relayer refunds and also fill any bridge requests that weren't filled by a relayer

When the proposal passes the liveness window, the above instructions are executed.

## Modular Components within Across

There are many agents that can be creative with how they fulfill their roles within Across:
- **Custom Relayers**: Relayers are profit maximizing and therefore can tune their relayer code to be faster and more aggressive in exchange for taking in additional risk. We already see this today where very risky relayers are able to fill the majority of deposits consistently in under thirty seconds while larger relayers with more capital take their time. This is why Across' relay time is [so fast compared to its competition](https://twitter.com/AcrossProtocol/status/1674448758656868354?s=20).
- **Pooled Relayers**: Relayers could be smart contract pools that themselves are controlled by shareholders and take in passive capital seeking yield in order to pool together more capital and win larger deposits. Think Lido for Across.
- **Order Flow Auction Front-ends**: An Across front-end has the liberty to set relayer fees how they wish. The simple one built by Risk Labs sets the relayer fee equal to the estimated gas cost plus an opportunity cost of capital. This could be improved by building a front-end that conducts a mini order flow auction whereby other relayers could bid to fill a user's deposit. Then, the user could submit a deposit using the auction-clearing price that only the winning relay could fill. (The `message` field in a deposit could be used to restrict who could fill the deposit.) The dApp itself could charge some sort of fee for conducting and settling the auction, so this seems like another viable business idea. Think, CowSwap for Across.
- **Smart Deposit Wallets**: Depositors can deposit to smart contract wallets on the destination chain and include arbitrary calldata that can be used to execute "bridge and X" instructions. This could be used by a team to offer to users the experience of signing messages from any chain and executing them out of the smart contract wallet on a target chain. *wink*, *wink*: Across can enable cross chain account abstraction.

These open-ended roles offer white space where revenue-generating businesses can be built, which would ultimately add more capital efficiency and competition to the Across system.

In the long term, we'll see that the winning bridges get relegated to the backend and infrastructure level, and the ones that end up dominating the market will be the ones that are the most friendly to third party enterprises.