few small fixes pt 2

Author: anihamde

pages/express-relay/how-express-relay-works/_meta.json

@@ -1,6 +1,5 @@
 {
   "auction": "Auction",
   "opportunities": "Opportunities",
-  "permissioning": "Permissioning",
-  "relayer": "Relayer"
+  "permissioning": "Permissioning"
 }

pages/express-relay/how-express-relay-works/auction.mdx

@@ -2,7 +2,7 @@
 
 The auction in Express Relay is held off-chain at the auction server. 
 Bids arrive at the auction server and compete against other bids, vying for the same [permission key](./permissioning.mdx). 
-A [relayer](./relayer.mdx) selected by governance serves as the auctioneer and determines the auction in line with the criterion of maximizing the revenue shared back to the protocol that generated this opportunity. That means the auctioneer is expected to forward on-chain the subset of bids that maximizes the revenue back to the protocol.
+A relayer selected by governance serves as the auctioneer and determines the auction in line with the criterion of maximizing the revenue shared back to the protocol that generated this opportunity. That means the auctioneer is expected to forward on-chain the subset of bids that maximizes the revenue back to the protocol.
 
 Thus, the Express Relay auction is analogous to a sealed-bid auction, i.e., participants in the auction will not have the contents of their bid disclosed publicly unless they win the auction and are forwarded on-chain.
 

pages/express-relay/how-express-relay-works/opportunities.mdx

@@ -1,14 +1,14 @@
 # Opportunities
 
-In the context of Express Relay, an opportunity refers to a potential transaction that a searcher can execute on a protocol. Typically, the term "opportunity" is used for such transactions that are lucrative and therefore hotly contested by many searchers. 
+In the context of Express Relay, an opportunity refers to a potential transaction that a searcher can execute on a protocol. Typically, the term "opportunity" is used for such transactions that are lucrative and therefore competed for by many searchers. 
 
-In the pre-Express Relay world, opportunities therefore correspond to MEV: a protocol generates MEV when an opportunity appears on that protocol and searchers bid up the right to execute the opportunity at the validator level.
+In the pre-Express Relay world, opportunities therefore corresponded to MEV: a protocol generated MEV when an opportunity appeared on that protocol and searchers bid up the right to execute the opportunity at the validator level.
 
-In the context of Express Relay, the value deriving from an opportunity no longer flows to the validator but instead is recaptured by the system and shared back with the protocol. In Express Relay, protocols expose opportunities to the network of integrated searchers, and the searchers then bid on priority to execute those opportunities. Critically, the auction has moved from being determined by validators to a lower level at the protocol level.
+In the context of Express Relay, the value deriving from an opportunity no longer flows to the validator but instead is recaptured by the system and shared back with the protocol. In Express Relay, protocols expose opportunities to the network of integrated searchers, and the searchers then bid on priority to execute those opportunities. Critically, the auction has moved from being determined by validators to a lower level of the stack (the protocol level).
 
 ## Oracle-agnostic
 
-Critically, opportunities do not refer to only transactions that use an oracle. In truth, any transaction that is lucrative but limited (available to only the first user(s) who executes it) generates MEV. As a result, Express Relay and the opportunity schema have been designed to be oracle-agnostic.
+Opportunities do not refer to only transactions that use an oracle. In truth, any transaction that is lucrative but limited (available to only the first user(s) who executes it) generates MEV. As a result, Express Relay and the opportunity schema have been designed to be oracle-agnostic.
 
 Examples of opportunities include:
 - liquidations
@@ -19,23 +19,23 @@ Examples of opportunities include:
 ## Opportunity Adapter
 
 The Opportunity Adapter contract enables searchers to engage with opportunities from different protocols without needing to do any bespoke integration work per protocol. Instead of exposing lower-level fields determined by protocols (e.g. `amountCollateral`, `addressBorrower`), the Opportunity Adapter abstracts away the semantics of the opportunity and instead [exposes the fundamental traits](https://github.com/pyth-network/per/blob/30c3fc695034f518225f8255ebe8423604e8aca3/contracts/src/opportunity-adapter/Structs.sol#L20-L23) of any opportunity:
-- the tokens sold
-- the tokens bought
-- the identity of the user executing this opportunity
+- the tokens sold by the searcher
+- the tokens bought by the searcher
+- the identity of the searcher executing this opportunity
 - the contract to call and the calldata and value to call with
 - the user's bid
 
 Thus, the Opportunity Adapter unifies the disparate interfaces of different protocols with respect to their different opportunities. This unification in a single interface is what makes Express Relay an opportunity hub connecting protocols and searchers.
 
-To use the Opportunity Adapter workflow, a searcher submits a bid with the target contract set to the `OpportunityAdapterFactory` contract. Each searcher has their own `OpportunityAdapter` contract per chain that is created when they first interact with `OpportunityAdapterFactory`. The factory contract then routes the transaction of a searcher to its corresponding `OpportunityAdapter` contract.
+To use the Opportunity Adapter workflow, a searcher submits a bid with the target contract set to the `OpportunityAdapterFactory` contract. The factory contract then routes the searcher's transaction to their respective `OpportunityAdapter` contract. Each searcher has their own `OpportunityAdapter` contract per chain that is automatically created for them when they first interact with `OpportunityAdapterFactory`.
 
 ### Permit2
 
 The `OpportunityAdapter` contract uses the [Permit2](https://github.com/Uniswap/permit2) token approval system, which handles the validation of a searcher's signature. Permit2 enables users to authorize token approvals for specific transaction data. In combination with Permit2, `OpportunityAdapter` allows a searcher to authorize use of their tokens only with a call to a particular contract with specified calldata and conditional on receipt of a set of specified `buyTokens`.
 
 ## Opportunity Server
 
-Once on-chain opportunities arise, searchers can be notified of their existence via the opportunity server. Like the auction server, this is an off-chain piece of the Express Relay stack that is run by an infrastructure partner designated by the DAO. The opportunity server presents opportunities to searchers in a way that abstracts away bespoke integration work for the searcher: instead of worrying about crafting calldata specific to every new liquidation interface, searchers now view liquidation opportunities in terms of tokens they need to sell (debt they repay) in exchange for tokens they buy (collateral they liquidate). This simplified interface unifies different liquidation schemas and allows searchers to easily plug into more protocols, improving the access between protocols and searchers.
+Once on-chain opportunities arise, searchers can be notified of their existence via the opportunity server. Like the auction server, this is an off-chain piece of the Express Relay stack that is run by an infrastructure partner designated by the DAO. The opportunity server presents opportunities to searchers in a way that abstracts away bespoke integration work for the searcher: instead of worrying about crafting calldata specific to every new liquidation interface, searchers now view liquidation opportunities in terms of tokens they need to sell (debt they repay) in exchange for tokens they buy (collateral they liquidate). This simplified interface unifies different liquidation schemas and allows searchers to easily plug into more protocols.
 
 In addition to learning about present opportunities, searchers can also query the opportunity server for data around historical opportunities.
 
@@ -47,4 +47,4 @@ In addition to learning about present opportunities, searchers can also query th
 
 Many integrated protocols with Express Relay build out an opportunity monitor script to query executable opportunities on their protocol and expose them to searchers. This allows them to tap into all Express Relay-integrated searchers, who do not need to do any additional integration work beyond having access to the relevant tokens to execute opportunities on the protocol.
 
-In terms of existing infrastructure, the opportunity monitor script is most analogous to a protocol's liquidation scripts/bots. Typically, many lending protocols build liquidation bot libraries that they share publicly in hopes of encouraging liquidators. With minor modifications, these scripts can serve as the opportunity monitor that enables all Express Relay-integrated searchers to participate in this protocol's liquidations.
+In terms of existing infrastructure, the opportunity monitor script is most analogous to a protocol's liquidation scripts/bots. Typically, many lending protocols build liquidation bot libraries that they share publicly in hopes of encouraging adoption by liquidators. With minor modifications, these scripts can serve as the opportunity monitor that enables all Express Relay-integrated searchers to participate in this protocol's liquidations.

pages/express-relay/how-express-relay-works/permissioning.mdx

@@ -1,20 +1,19 @@
 # Permissioning
 
-`permissionId` is a `bytes` object that represents the unique identifying information of a position within the protocol. `PermissionId` allows the system to distinguish between bids competing on different opportunities and thereby run more scoped and efficient auctions.
+`permissionId` is a `bytes` object that represents the unique identifying information of a position within the protocol. `permissionId` allows the system to distinguish between bids competing on different opportunities and thereby run more scoped and efficient auctions.
 
 Each borrower has a unique position for some protocols, so the borrower address uniquely identifies a position. 
-Whereas in some protocols, each borrower might have multiple positions, distinguished by the address of the collateral asset or by a `uint256` ID number. 
+In other protocols, each borrower might have multiple positions, distinguished by the address of the collateral asset or by a `uint256` ID number. 
 In those cases, the information set that uniquely identifies a position would include multiple fields.
 
-`permissionId` is the concatenation of all these fields in bytes format. You can call `abi.encode(){:solidity}` to concatenate these fields together. 
+`permissionId` can be the concatenation of all these fields in bytes format. You can call `abi.encode(){:solidity}` to concatenate these fields together. 
 
 For example, if a protocol featured a unique position per borrower, then it could form `permissionId` as
 
 ```solidity
 bytes memory permissionId = abi.encode(borrowerAddress);
 ```
 
-
 On the other hand, if a protocol allowed a borrower to open as many new positions as they wanted, denoted by an identifier `uint256 positionId{:solidity}`, then it could form `permissionId` as
 
 ```solidity