> For the complete documentation index, see [llms.txt](https://docs.fwastr.fun/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.fwastr.fun/delivery.md).

# Delivery

{% hint style="warning" %}
FWA isn't a normal token when it moves.
{% endhint %}

Its transfer rules are enforced by a Uniswap v4 hook. During an authorized swap, that hook grants permission for exactly the token movement the swap needs to settle. The permission lives inside the transaction and vanishes when it ends.

Which creates a strange situation:

**A contract can buy FWA. It cannot hand it to anyone afterward.**

The buy authorizes itself. But a later transfer to a user has no live hook permission behind it, so it's rejected outright.

That's why no strategy token existed for FWA. Acquisition was never the blocker. Delivery was.

***

**Why holding a claim isn't enough**

FWASTR stores each unsold bag as an **ERC-6909 claim** inside Uniswap's PoolManager internal accounting that says PoolManager owes a specific amount of FWA.

Moving a claim never touches FWA's transfer rules. But converting one into real tokens does:

```
poolManager.burn()  ──►  ✓  settles the internal balance
poolManager.take()  ──►  ✗  InvalidTransfer()
```

The burn works. The take fails, because it performs an actual FWA transfer with no hook permission behind it.

Putting both in the same transaction doesn't help. **The condition isn't the transaction. It's a real swap that invokes the hook.**

***

**The way through**

If permission only exists during a swap, then perform one at the moment of delivery.

When you buy a bag, FWASTR does this in a single atomic transaction:

```
STORED CLAIM
      │
      │ sell FWA
      ▼
   NET ETH
      │
      │ buy FWA  ──► hook grants transfer permission
      ▼
PHYSICAL FWA ──────────────────────► YOUR WALLET
```

1. Sell the claim for ETH
2. Use that exact ETH to buy FWA back
3. The buy invokes the hook, creating permission for exactly that output
4. Burn the stored claim to settle the sale
5. Send the newly bought FWA straight to you

The ETH never leaves the transaction both legs cancel internally. FWASTR never takes custody of the FWA at any point. It goes directly from PoolManager to you.

**This isn't a workaround. It's a use of the hook exactly as designed.** The buy is real, the fee is paid, and the permission created is the same permission any ordinary buyer's swap creates.

***

**What you actually receive**

The round trip crosses the hook twice and takes price impact on both legs, so the FWA you receive is slightly less than the claim's face amount.

In testing, output came to roughly **98% of the original claim**. That figure depends on pool depth and fees at the moment of purchase and isn't fixed.

Every purchase carries a minimum output you set. If the route can't meet it, the purchase takes the second path.

***

**The second delivery path**

The route depends on things outside FWASTR's control: pool liquidity, price, hook state. So the design doesn't assume it completes.

If anything fails, the entire round trip rolls back and **you receive the original ERC-6909 claim instead.**

```
BUY BAG
   │
   ├── route succeeds ──► physical FWA
   │
   └── route fails ─────► original claim
```

The outcome is binary and automatic. You get FWA, or you get the claim. If neither can complete, the purchase reverts entirely and your ETH comes back.

A claim is worth more FWA than the physical route would have delivered, since it skips the round-trip cost. It sells back to ETH through the app in a single action, no physical FWA transfer involved, so the transfer lock can't block the exit.

**Worth understanding:** the claim preserves the asset, not the price you paid. Converting it back to ETH means selling into the same pool and paying the same fee. It isn't a refund.