updated diagram, added it to readme

README.md

@@ -5,6 +5,12 @@
 
 Atlas is a system that combines a highly advanced smart contract with a frontend API to allow DeFi protocols to control how and where to allocate the MEV generated by their users' transactions. One of the key roles of a DeFi frontend is to build a transaction's "calldata" that defines what the User's transaction will do. Atlas works by injecting the calldata for Searchers' meta transactions at the end of the User's calldata; this occurs *before* the User signs the transaction. By including the User's calldata and the Searchers' calldata inside of a singular transaction that's governed by the logic of the Atlas smart contract, Protocol Governance is guaranteed that downstream actors such as wallets, RPCs, relays, builders, and validators will not be able to redirect the MEV to suit their own purposes. 
 
+### Network Overview
+![Overview](./AtlasOverview.png)
+
+### Atlas Metacall Structure
+![AtlasTransaction](./AtlasTransaction.png)
+
 ### Advantages:
 
 - No dependencies on centralized infrastructure or need for any trusted wallet, RPC, relay, builder, or validator.
@@ -37,4 +43,4 @@ Atlas is a system that combines a highly advanced smart contract with a frontend
 
 Note that there is significant complexity in the lock system.  This was designed to handle ALL cases, rather than having to deploy multiple contracts to handle SOME cases, so as to avoid the fragmentation (capital inefficiency and upkeep effort) of the searcher's escrowed gas values.  Other factory contracts may be launched with less complexity - such as one that has no delegatecall and therefore no need to create a new contract each time - but the Escrow contract must be designed to handle the *most* complex of those designs or searchers' gas values will be fragmented.
 
-Note that the backend will probably need to use a reputation system for searcher bids that aren't in the top three in order to not take up too much space in the block.  The further down the the searcherCalls[], the higher the reputation requirement for inclusion by the backend. This isnt necessarily required - it's not an economic issue. It's more-so about just being a good member of the ecosystem and not wasting too much precious blockspace. With probabalistic searcher txs that have low success rate but high return-to-cost rate. 
+Note that the backend will probably need to use a reputation system for searcher bids that aren't in the top three in order to not take up too much space in the block.  The further down the the searcherCalls[], the higher the reputation requirement for inclusion by the backend. This isnt necessarily required - it's not an economic issue - it's just that it's important to be a good member of the ecosystem and not waste too much precious blockspace by filling it with probabalistic searcher txs that have low success rate but high return-to-cost rate.