Architecture
Transfer flow and Conversion flow are for PayMe, and the rest for Özel as a protocol.
System Designs
Here the group that does the L1 actions is separated at the left side and the one that does L2 to the right side, connected through bridging and an EOA transaction (from RedeemedHashes into Arbitrum).
Each form represents a chain which interacts with one another through different methods. It can also be observed the interactions of external networks with the system; external like the Gelato network, and inflows/outflows of tokens, represented in the black squares (except for the OZL token square).
Bridging is removed since it adds too many vulnerabilities. The main economical and logic activities happen in only one chain, where all revenue-driven activities are easily focused towards the heart of the system: ozDiamond.
It is composed by:
Economic sectors which produce revenue to the structure, like PayMe.
Future economic sectors called in this diagram Section #2, #3, all the way to Section #n
Standalone implementations such as for querying system statistics, admin configuration, etc.
The idea is to resemble a brain where the sections are the brain cells, communicating with one another through onchain transactions (dendrites) instead of synapsis.
User starts by creating an Account (
ozAccountProxyfor L1 transfers orozAccountProxyL2for L2 transfers).ETH is sent to the address of this Account.
If it's an L1 transfer, the Gelato network is constantly querying the Account for its ETH balance. If there's any, it starts a new transaction using the balance of the Account for its gas payment. If it's an L2 transfer, skip to step #6.
ozMiddlewareforwards the call fromozPayMeto L2 in order to change themsg.sender(for access control).ETH funds go through the different contracts in L2, the protocol's fee gets charged and invested in DeFi, and the user's funds get swapped to the Account's stablecoin.
User receives their funds, in L2, in the chosen stablecoin.
When ETH is sent to an Account, it goes through a series of conversions which would finalize in the Account's chosen stablecoin.
Depending on which stablecoin the Account has, the amount of conversions performed would vary.
ETH is sent to the Account in L1.
If it's an L2 transfer, start here --> It gets deposited on the WETH contract on L2 (for better management as an ERC20 token).
The WETH gets converted to USDT or WBTC (the system's base tokens). A base token is needed since these two are the connection between different Curve pools that allow other swaps.
If the Account's token is not USDT or WBTC, the base token would be converted to the Account's token.
If the Account's token is USDT or WBTC, this one is sent to the user (aka the Account owner). If it's not, then the result of the conversion on step #4 is sent to the user.
Possible scenarios for reception of funds
Since the swaps from an user's ETH transfer to the stablecoin of the Account can fail due to slippage, it cannot be guaranteed with absolute certainty that the user will always, 100% of the times, receive the Account's stablecoin in L2 in the end of flow.
To fully grasp the different scenarios, it is important to understand the *Conversion Flow* diagram from above. Having this mentioned, these are all the possible schemes that could happen for the reception of funds:
100% Account stablecoin
The user receives the full amount of funds in the Account's stablecoin.
If a decent slippage is chosen and there's enough liquidity in the Curve pool of the swap, in comparison to the amount being swapped (aka the amount of ETH sent to the Account), this scenario will occur almost every single time.
(It's the *Conversion Flow* diagram from above)
50% Account stablecoin - 50% base token
The user receives 50% of the funds in the Account's stablecoin and 50% in the base token.
This scenario occurs when the funds are already in the base token, and the protocol proceeds to swap them for the Account's token.
It happens exactly when a swap fails, the second re-try succeeds, but the third one fails (2nd and 3rd are for the divided swapped amount after the original swap fails).
This re-try method is achieved using a try/catch technique that can be seen in executeFinalTrade() of ozExecutorFacet, for example.
100% base token
The user receives 100% of funds in the base token of the Account's stablecoin. This happens when the original swap and the first re-try (2nd swap) fails, so the second re-try (or 3rd swap) is never executed.
100% Emergency swap token (USDC)
The user receives 100% of the funds in the token from the Emergency swap done in L1, which occurs when, for whatever reason, it's not possible to bridge the ETH to L2 (USDC at the moment).
This is one of two scenarios where the user would receive the final funds in L1.
100% WETH
The user receives funds in WETH when:
It's not possible to bridge the ETH to L2, the Emergency swap runs, but it fails in the end (100% of funds).
This is second of two scenarios where the user would receive the final funds in L1.
It's not possible to swap the ETH/WETH for the base token (100% of funds).
Contracts and Files
Ethereum
Read the details of the connections here.
Akash
event-listener
nodejs
The Graph
while-fork
nodejs
Multi-threading using child_process module
redeem-fork
nodejs
Multi-threading using child_process module
Read the details of the connections here.
Arbitrum
Read the details of the connections here
Last updated