I’ve been in crypto long enough to know how hard it can be to win here.

I’m not a DeFi power girly, I’m not a developer, I’m not “highly technical.” For the last few years I’ve been someone who felt like I wasn’t knowledgeable or skilled enough to manage real money onchain, let alone help others do so.

I saw my peers farming airdrops and trying every new protocol, making gains one day and losing them all the next. It fascinated me, but also intimidated me, and I doubted myself. My inner saboteur would chime in with FUD like “crypto strategies are inherently complex to build and maintain, that's just the nature of the beast.” Or “you can’t do that, you shouldn’t do that, you don’t understand it well enough, it’s too risky.”

So when the founders of Plug asked me to join the team a year ago, I was so thrilled, but I was also nervous. I couldn’t imagine a version of myself that would be able to build and tell stories about sophisticated onchain strategies. How would I even do that?

But they had better foresight than I did. They knew what Plug’s stack would enable. They knew that I could do amazing things onchain when I was given the right tools. Fast forward to today, and I’ve curated over a dozen strategies and constraints that you probably never thought you could have.

The journey to get here wasn’t easy, but me and my team’s trials and errors have unlocked a new paradigm that lets us all win together. And by the time you finish this post, you’ll be ready to build or yoink any expression of onchain logic you desire on Plug.

We hit our alpha milestone for the Plug app and it’s time for me to start dogfooding our tech. Everything is brand new to me. I’m told nothing like this has existed before. We’ve been talking about the vision of our intent-based system and the value programmable Ethereum transactions without smart contracts will unlock for crypto users and teams for months, now it’s finally in my hands.

There’s no polished plug building playbook or examples to follow. Just a blank canvas and a question I have to answer for myself: what can Plug truly do and how do I do it?

After I connect my wallet and start browsing all the available actions, my inner saboteur shows back up immediately. “I'm the one who's supposed to curate compelling strategies and explain them to our network, what happens if I can't figure it out myself?”

One of our founders senses my hesitation and redirects me immediately. He explains that a plug is simply an intent: something that lets me express my desires and constraints onchain. And once I know what outcome I want, I can use our natural language sentences to make it happen. I just need to express my logic in whatever order my strategy requires and fill in the blanks on the sentences to get the inputs and outputs I need at each step.

As I start playing around with more actions, I realize that each one uses the same standard sentence structure: Aave, booleans, control flow, comparisons, math, time. Everything is generalized for the EVM. I don’t need to worry about the unique nuances of each protocol or action type, I only have to get comfortable with Plug’s foolproof language interface.

And the best part? Thanks to Plug's coil system, I can wire compatible outputs from one step directly into the inputs of a later step at buildtime, and Plug resolves the real values from live onchain state at runtime. I never have to guess about correct amounts or addresses ahead of time or settle for static inputs. All the complexity I was afraid of isn't mine to carry. I just have to know what outcome I want.

At this point I’ve been learning all the ins and outs of leverage looping on Aave V3 and realize we have every action I need to build a self-maintaining loop there, so I started building my first plug: Loop against while maintaining a target health factor.

I know what outcome I want, so I start expressing my desired logic step by step and my logic blocks become:

1. Supply as collateral to Aave’s Ethereum Core market if I haven’t already. Specifically, read my live balance, and if it’s equal to 0 at runtime, supply 5 . If it’s not, skip ahead to the next block.

2. Calculate my target debt based on my target health factor so I can rebalance my position to maintain that target. Then, unwind (withdraw collateral to repay debt) if my total debt is greater than my target debt. And wind (supply collateral to borrow more ) if it’s not.

I work through each block step by step, one sentence at a time, ensuring I have all the onchain reads I need to be able to expose the coils I want. If I don’t see the reusable output I’m looking for, I know I missed a step. By the end, almost every step in my plug uses those beautiful orange pills, and the power of coils is clear as day.

All my logic is defined and compiling properly, and I know Plug will do all the math and heavy lifting to get the outcome I want when it executes. I’m so proud of my work, but there is one problem that’s impossible to ignore: the plug is barely legible.

The logic works, but I can’t read or understand it at a glance because all my coils use our system’s default names. I see multiple instances of “calculation” and don’t even remember what each represents. I share the plug with my team and they unsurprisingly share the same concern.

We have to make plugs legible, otherwise how will anyone know what they do and decide whether or not they want to fork and run them? I push for the ability to rename outputs via a Rename action, and lucky for me, this action already exists. It was just named something else (Set variable, I think?) and I overlooked it. Now I can give each output a proper, unique name that’s easy to follow and it immediately lands for them. Problem solved.

Now I want to build a version of my plug that has a trailing stop loss, so I fork the plug I just built, tailor it to add that logic, and my plug balloons to 64 steps. Once again, I’m proud of what I built, but now I’m discovering a new problem I can’t ignore.

Having this many logic blocks and steps in a single plug is way too much to reason about and maintain as a builder. It’s also way too much for others to parse and understand. And what if I want to add a liquidity drain guard or borrow rate exit guard to my loop too? Now my plug will be 100+ steps? Not ideal. So me and my team get to brainstorming how to make building and forking logic blocks with single points of concern more feasible.

Perhaps multiple plugs that serve different purposes could link up, share state, and work together. In essence, swarm to achieve my desired outcome as opposed to me stuffing everything I might want into one massive, all-encompassing plug.

We decide to ship Global flag actions that let me store and read shared state across any plug in my account. That's the missing piece. Now I can break up my plugs and build my first swarm.

I use my original looping plug as my base strategy and build a separate plug with all the trailing stop logic that can run in parallel. To make this work, I just need to ensure they both use the same global flag: exited_weth/usdc_loop. That way, the plugs are always in lock step and only run when I intend them to.

The swarm works just as I hoped and having these single points of concern broken out feels much easier to maintain and reason about. So I start adding more plugs to my swarm to give our users more exit hatches to choose from and end up with a compelling set of Aave plugs.

Loop / at Target Health Factor as the base strategy, and isolated logic blocks to optionally run alongside it:

I feel like I’ve won the jackpot. Moving forward, if my strategy has a single point of concern, an all-encompassing plug makes sense. But if my strategy has multiple points of concern, an all-encompassing plug hits a ceiling very quickly, so I should build pointed plugs that swarm together instead. Me and my team celebrate thinking we just solved all our plug legibility and composability problems with minimal effort. Then one of the founders hits me with this:

“So I went to set up a / loop with a take profit, stop loss, and liquidity drain guard. I struggled to find the related plugs in Discovery based on the naming convention alone. One plug with Swarm in the title and five plugs with (WETH/USDC Loop) in the title don't read as a coordinated system. Then I forked the 3 plugs I needed, renamed all the global flags on each, and tailored a bunch of inputs on each step by step to get what I want. That was a lot.”

A lot indeed. I don't even want to do that, so I can’t expect him or anyone else to want to. Relying solely on global flags for our swarming mechanic solved coordination but created a new layer of friction for discovery and reusability.

Then before I could even process any next steps, he ships a new protocol integration, Mirror, the next morning.

With Mirror, he built what the strategy swarms were pointing at all along: the ability to turn a plug into a reusable function that other plugs can use.

In developer land, functions are building blocks. A set of logic with a single point of concern, built once and used wherever you need it.

Mirror brings that same concept to Plug. Build a function once, and any other plug can use it. The logic lives in one place, runs on demand, and never needs to be duplicated.

Function plugs are general. Strategy plugs are for quick configuration. Anyone who finds one of my strategy plugs can see exactly which function plugs it's built from, set the required inputs, and sign it in a few clicks.

Now my strategy plug uses three function plugs: supply collateral, rebalance, and stop loss. The same points of concern as before, just cleaner and more flexible. And notably, none of these functions are specific to this loop. Anyone building a strategy that needs an initial deposit, a rebalance, or an exit can use them too.

The global flag still earns its keep too. My strategy plug opens by reading exited_weth/usdc_swarm and only runs while it's false, so coordination across the swarm stays intact while Mirror handles the composition.

This changes everything about how I build. Instead of forking and tailoring multiple blocks of logic step by step every time I want a new strategy, I can build each one as a standalone function plug and use them as steps inside my strategy plugs.

Now I have a system where I can build each logic block once, compose it into any strategy I want, and hand anyone a single strategy plug to fork instead of the five I served them before.

My older plugs still work and still earn their place. Some strategies belong in one single plug and always will. But when logic is worth reusing, the all-encompassing approach hits a ceiling, and that's exactly what led us to Mirror.

You don't have to be a power user to win on Plug. You can simply find a strategy someone else built, fork it, and set a few inputs. That's the whole point. But if you want to go deeper, the tools are there. Every milestone in this journey came from building something, hitting a ceiling, and figuring out what came next.

But you don't have to take the long road I took. A new standard for what it looks like to build and reuse onchain logic is finally here and waiting for you. Now go ahead and build something, or find something someone else built and make it yours.