Ethereum

Open methods -> called externally (not all external functions are Open). Owner methods -> called by the deployer. System methods -> called by other functions within the system.

Account methods -> called by the owner of each Account

Only the main functions are included in these docs.

Factory setup

A Proxy Factory sits behind (as the implementation), of an Open Zeppelin's ERC1967 proxy. It creates the proxies that each user would use as the "Account", where they'd receive the ETH transfers that would later be converted, in L2, to their chosen stablecoin.

The proxy of the Factory (ozERC1967Proxy) gets upgraded with the UUPSUpgradable mechanism.

Beacon and shared storage (aka Storage Beacon)

The system of multiple proxy accounts being redirected to a single implementation is developed through Open Zeppelin's UpgradableBeacon contract, with a custom-made upgradable storage strategy that allows to add more Storage contracts that can be shared between implementations and proxies by their version numbers, in case new implementations with new storage are needed.

A diagram of this design can be seen here.

Forwarding of data

ozPayMe forwards data to two different networks (using the Emitter contract): Arbitrum (L2) using their canonical bridge, and to Akash (from Cosmos) for a manual review of each transaction in order to check that it was successfully redeemed in L2.

The role of the Gelato network

In order to allow users receive ETH with the conditions of a standard ETH transfer (gasLimit of 21k), the Gelato network is used. So when a new transfer is received in an Account (aka ozAccountProxy), the execution stops, a Gelato contract queries the balance of the Account, and if there are funds, it starts a new execution/transaction which would bridge the ETH and continue the protocol flow.