fix: last tweaks

README.md

@@ -19,6 +19,8 @@ We think there is an opportunity for something in the middle. Not everyone who h
 
 While there are already other pool based bridges available (Stargate, Across, etc), the idea is that none of these fully optimize for a world dominated by sophisticated solvers and long tail chains, so there is a big gap in the market.
 
+# Implementation
+
 The rough idea is that Relay pools are used to “accelerate” any existing bridge:
 
 - users send money over a bridge, but via a proxy contract
@@ -30,15 +32,15 @@ The rough idea is that Relay pools are used to “accelerate” any existing bri
 
 What’s interesting about this pool design is that effectively 100% of volume is getting rebalanced over a bridge. At first glance, this might seem inefficient, because it’s not able to do “netting” of bi-directional flow, as seen in most pool-based bridges. But this is deliberate. The assumption is that if there’s any netting available, solvers will take it. And the only volume that will come to the pool is the “toxic” orderflow, i.e. the one-directional excess. This design embraces that reality and optimizes for it:
 
-- one-sided pools
+- <b>one-sided pools</b>
   - rather than trying to manage connected pools on two or more chains, and rebalance between them, you can have simple one-sided pools
   - there’s no need to manage how liquidity is allocated between pools on different chains, because each pool is isolated, and 100% of volume replenished back to the pool
   - LPs choose exactly where to allocate liquidity, and get a simple deposit/withdraw UX
   - you can still achieve multi-directional flow by deploying multiple (unrelated) pools on different chains, and composing them at the application layer
-- permissionless deployment
+- <b>permissionless deployment</b>
   - because pools are isolated, it’s much easier to let anyone deploy them
   - this allows faster expansion to new chains
-- yield maximization
+- <b>yield maximization</b>
   - toxic orderflow tends to come in bursts, when solvers receive more demand than anticipated
   - this means that liquidity is often idle, and can be deployed into other protocols to earn a “base yield” when it’s not in use
   - this also pairs nicely with permissionless deployment, because you can have different pools with different risk / yield profiles