A lot of how to do all the fancy CP reduction for

**2GR **(2-gen redux) is still in the works, but just to give a bit of an update on the stuff I'm working on, here's what I'm thinking about right now. The inspection is very difficult at the moment as everything is still a work in progress, and the rest of the solve is straightforward.

**In inspection:**
1) Solve DLB with a rotation

2) find key swap

3) determine how to solve EOPair (explained below)

4) find key swap after moves needed to solve EOPair

**The substeps in order:**
*EOPair *(8 moves, mostly <R,r,U,u,F,f> to make CP tracking ez, but not a hard rule): orient the edges w.r.t the proper centers (so if your DLB piece is white-blue-orange, then you want to orient w.r.t red/orange front, white top), then solve a 2x1x1 by placing the LD edge.

*2GLine *(3 moves): while preserving EO, expand the 2x1x1 into a 3x1x1 and reduce corners to <R,U> and the entire cube to <R,r2,U,u2>.

*Block *(8 moves, mostly <R,r2,U,u2>): while preserving EO, expand the 3x1x1 into a 3x2x2.

*F2L *(13 moves, all <R,U>): solve the rest of the F2L. (keep in mind you'll sometimes get lucky pairs for an F2L-on-left. Definitely make use of them.)

*2GLL *(15 moves, mostly <R,U>): 1LLL w/ 84 algs.

**Wholesolve**: 47 moves, 28 of which are <R,U> (~60% of the solve). (For comparison, ZZ-b gets 47, ZZ-CT gets 52, Felik's ao100 got 61, and the avg movecount of a bunch of Lau's solves on cubesolv.es is 49)

There are of course a couple of "plugin" methods you can add as well on top of your 1LLL: if you have an awkward pair, you could use TSLE/TTLL or CLS/L5E, or insert the pair and learn more 2GLL-like algsets that solve LL + fix a twisted corner; you can make NM blocks if they look really nice, etc.

I know I'm not giving much practical stuff here as inspection thingies still need to be worked out (which is basically just me practicing EOPair over and over to see how feasible/ergonomic it really is), but: here are

9 example solves to feast your eyes on

Average movecount is 45.2 (σ = 6.18).

If EOPair turns out to be too awkward of a step, then my backup idea is a much improved Noah's CP Blocks 2.0:

**CPLine **(3 moves): 3x1x1 + CP.

**FB **(8 moves): Expand to 3x2x1.

**EOLine **(9 moves): <R,r,U,M> to solve EO + DFDB. mdipalma and I did some playing around with HARCS today and got avg movecount for this at 8.6 moves (n = 10).

**F2L, 2GLL **(28 moves): as before.

**Wholesolve**: 48 moves.

Issues here: CPLine will require a good amount of color neutrality to make use of any free pairs (p = 0.64, n = 69) or pairs 1 move away from being formed (p = 1, n = 40). You'll also need fast EO recognition methods and a good way to solve EO + Line pieces efficiently (personally this seems hard but the old CP Blocks thread has Kirjava saying this step is actually very straightforward. If someone can show this to be super easy I might look into it more).

I like the first idea more if EOPair turns out to be really nice and plannable in the same time that top ZZ solvers plan their EOLines (~3-4 seconds)--I think it's certainly possible to determine key swap in ~2 seconds, and that leaves at least 8 seconds to track the key swap in order to predict what it'll be after EOPair.