Peel is a Bitcoin payment routing SDK for Bitcoin L1 and L2s. It abstracts away address formats, transaction models, bridge protocols, and signing conventions behind a single, clean interface. To put simply, Peel is an attempt at abstracting away the manner we deal with the various wrapped bitcoin flavors hosted on various Bitcoin layer 2's.

Now to double-click into this, let me give you the lay of the land of what we have today: dozens of Bitcoin layer 2 networks with their own wrapped bitcoin flavor that unfortunately don't interop with one another. Stacks' sBTC can't speak with Rootstock's rBTC. Citrea's cBTC doesn't recognize wBTC on BOB. To add onto this, there has also been no attempt at designing a unified interface between them. They're all a bit siloed with barely any attempt of recognition from one another. Everyone is doing their own thing without realizing there could be something bigger. That is, what if we were to treat each wrapped bitcoin flavor as just bitcoin? And what if we harness that idea with a "routing engine" that can intelligently determine which btc flavor gets chosen based on a simple agent prompt of:

> send 10,000 sats to <receipient-address>

That simple prompt is what it is. Your sending x amount of sats to another recipient. With an agent strapped with Peel, what might happen is a transfer of sats, via Rootstock rails in the form of rBTC. Or it might be a peg-in operation from native btc to sBTC because the recipient might already be an active participant on Stacks. Or maybe it was inferred from the user prompt that the recipient wanted to invest in some BTCFi protocol on Citrea. Or maybe it might be a wBTC movement on BOB because the L1 is experiencing network congestion. For the user, all that should matter is that they received sats. Because the ideological approach here is that any wrapped btc flavor should just be treated as btc.

Now Peel is packaged as a monorepo broken up into a few different SDK packages. This leans on the assumption that apps or wallets can plug and play, which is true but in reality its real purpose is to give agents an interface for managing the scattered world of wrapped btc flavors. Agents will lean on the internal routing engine and make its own inference on which btc flavor gets routed. Essentially, Peel obviates the layer 2 rails while the end user doesn't need to know nor care about the routing intent, it just needs to know that it has sats.

Let's take a look at another example prompt one could send to an agent:

❯ send 15,000 sats to 0x388C818CA8B9251b393131C08a736A67ccB19297

[agent response]
Payment of 15,000 sats has been sent to 0x388C818CA8B9251b393131C08a736A67ccB19297.

Now to expand the agent's inference logs and provide more clarity of what's happening:

❯ send 15,000 sats to 0x388C818CA8B9251b393131C08a736A67ccB19297

[agent thinking]
  Using Peel's address format detection (@peelbtc/core)...
    → 0x prefix + 40 hex chars = EVM address
    → probable chain: Rootstock (most common routing)
  
  Checking your sender balance across layers...
    → Bitcoin: 99,792 sats (available)
    → rBTC on Rootstock: 99,946 sats (available) ✓
  
  Using Peel's routing engine to score routes...
    ✓ Direct Rootstock: sender balance 99,946 sats > 15,000 (score: 92/100)
      • No bridge required (fee: ~54 sats)
      • Settlement: ~30 seconds
    ⊘ Bridge from Bitcoin: would require crossing, higher fee
  
  Route selected: Direct Rootstock (optimal)

[agent response]
Payment of 15,000 sats has been sent to 0x388C818CA8B9251b393131C08a736A67ccB19297.

Route: Direct Rootstock transfer — no Flyover bridge
Fee: ~54 sats  |  Settlement: ~30 seconds
Transaction: 0xae10b8b8cf491b4f8d2d7d5ef65e37588b67a8e5cfd376e96854051dcd1b7423

So how did the agent lean on Peel for this transaction? Peel detected the destination as an EVM address (Rootstock), checked that it had enough rBTC there, and routed directly without crossing a bridge. The recipient has an active rBTC balance on that chain, so Peel scored that as the optimal path.

Under the hood, Peel's routing engine evaluates every potential route using a weighted scoring system: sender balance availability (35%), receiver activity and chain preference (25%), transaction fees (25%), and settlement time (15%). Before committing to any route, Peel verifies network liveness and embeds a Peel memo in every transaction for future indexing. It also respects user intent signals. For example, if you mention "cold storage," it re-weights toward Bitcoin L1; if your recipient is active on a particular chain, it prioritizes that. The result is adaptive routing that feels less like instruction and more like intelligent delegation.

With that example hopefully you can comprehend Peel's vision of affirming that Bitcoin is the core, with every L2 being a layer wrapped around it — different address formats, different transaction models, different representations of BTC. The further from Bitcoin you go, the more layers accumulate.

Peel strips those layers away. When you use Peel, you think in sats. The layers are invisible.

Peel should be affixed on top of any agentic wallet harness. MoonPay's OWS was chosen as a first class citizen for Peel but any agentic wallet with basic cryptographic signing schemes should work.

The heart of Peel is with the BRID (Bitcoin Rooted Identity Derivation) standard and routing engine logic. It's leveraging those primitives in formulating the most optimal route based on intent and context.

Peel is there to guide your agent on how it should treat the management and transactional behavior of wrapped btc flavors on various layer 2's. At the moment, only four major layer 2's are supported but future work includes an agnostic manner of supporting any Bitcoin layer 2 without any direct opt-in support.

Now let's talk about what Peel is NOT.

It is not a wallet.
It is not a swap aggregator.
It is not a dex.
It is not another layer 2.
It is not its own chain.
It is not a cross-chain interop.
It is not taking a commission.
It is not a bridge.
It is not a custodian.

To put it in laymen's terms, it's taking other SDKs, that handle specific layer 2 networks, and wrapping it up in an abstraction geared for agents to make inference on what is the best btc layered rail to transfer sats on. Ideologically, it's an attempt at building a unified interface for treating all honest wrapped btc flavors as just btc. It's that simple.

Every Bitcoin layer 2's wrapped bitcoin representation should be respected and considered as just btc. It's the genesis of what spawned these layers and its what gives vibrance to the Bitcoin economy.

One command installs the SDK + skills for all detected coding assistants:

curl -fsSL https://raw.githubusercontent.com/ECBSJ/Peel/main/install.sh | bash

For the open-source repo, click here.