# Wrapped Native Integrator

> Generate Solidity contracts and scripts that integrate with Wrapped Native (WNATIVE)

- Skill: `api-evangelist/wrapped-native-integrator` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add api-evangelist/wrapped-native-integrator`
- Raw SKILL.md: https://api.skillmd.com/api/skills/api-evangelist/wrapped-native-integrator/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: api-evangelist (https://skillmd.com/u/api-evangelist)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/api-evangelist/wrapped-native-integrator

---


# Wrapped Native Integration Generator

Generate Solidity contracts that interact with the Wrapped Native (WNATIVE) contract at `0x6000030000842044000077551D00cfc6b4005900`.

## Project Setup

Before generating code, check the user's project is configured:
1. **Foundry**: `foundry.toml` must exist. If not: `forge init`
2. **Wrapped Native**: `lib/wrapped-native/` must exist. If not: `forge install limitbreakinc/wrapped-native`
3. **Remappings**: `remappings.txt` needs `@limitbreak/wrapped-native/=lib/wrapped-native/`. Append if missing -- do not overwrite existing entries.
4. **Local testing**: For local development, use `apptoken-dev` to bootstrap an Anvil node with all Apptoken protocols at their deterministic addresses -- see `apptoken-general/references/project-setup.md`.

## Instructions

1. **Parse integration requirements** from `$ARGUMENTS`

2. **Resolve ambiguities before generating** -- if $ARGUMENTS doesn't make the integration pattern clear (basic wrapping vs permits vs gas sponsorship), or references external addresses (fee recipients, operators) without specifying them, ask in a single message. If clear, proceed.

3. **Determine the integration pattern** based on what the user needs:
   - **Basic wrapping/unwrapping**: Deposit, withdraw, depositTo, withdrawSplit
   - **Payable ERC-20 operations**: Combined deposit+approve, deposit+transfer
   - **Permit-based gasless transfers**: EIP-712 signatures for `permitTransfer`
   - **Gas sponsorship / permitted withdrawals**: `doPermittedWithdraw` with convenience fees
   - **Protocol integration**: Using WNATIVE as a payment or reserve token

4. **Generate the integration contract** with:
   - Correct interface import (`IWrappedNative` for basic, `IWrappedNativeExtended` for permits/enhanced features)
   - Proper use of `payable` functions when combining deposit + action
   - Native token handling (`receive()` if the contract needs to accept unwrapped native)
   - EIP-712 signature construction if using permits

5. **Handle key integration details:**
   - WNATIVE address is deterministic: `0x6000030000842044000077551D00cfc6b4005900`
   - When calling payable `transferFrom` with `msg.value`, deposits credit the `from` address, NOT `msg.sender`
   - Same for `permitTransfer` -- deposits credit `from`
   - Contracts receiving native tokens from `withdraw`/`withdrawToAccount` must have a `receive()` or `fallback()` function
   - `withdrawSplit` arrays must be equal length

6. **Generate a Foundry test** if the integration involves non-trivial logic (permits, fee calculations, multi-step flows).

## Reference Files

- `references/integration-patterns.md` -- Common integration patterns with annotated Solidity examples
- Protocol knowledge: `wrapped-native-protocol`

## Common Mistakes

- Forgetting that payable `transferFrom` and `permitTransfer` credit deposits to `from`, not `msg.sender` -- operator contracts will not receive the deposited funds
- Not implementing `receive()` on contracts that call `withdraw` or `withdrawToAccount` to themselves -- the native transfer will revert
- Using WETH9's `deposit()` pattern (call + value) when `depositTo` would be more gas-efficient for crediting another address
- Signing permits with the wrong domain separator -- must use name `"Wrapped Native"`, version `"1"`, and the deterministic contract address
- Not checking `isNonceUsed` before submitting a permit transaction -- the nonce may have been revoked or already consumed

## When to Use This vs Other Skills

- **This skill (wrapped-native-integrator)**: Generate contracts that wrap, unwrap, transfer, or permit WNATIVE tokens. Use when the core task is interacting with the Wrapped Native contract.
- **lbamm-integrator**: Use when building swap/liquidity integrations with LBAMM. If the pool uses WNATIVE, the LBAMM integrator handles the wrapping internally.
- **tokenmaster-integrator**: Use when building buy/sell/spend flows against TokenMaster. If the reserve asset is WNATIVE, the TokenMaster integrator handles it.
- **payment-processor-exchange**: Use when building NFT marketplace integrations. Payment Processor accepts WNATIVE directly.

## Related Skills

- **wrapped-native-protocol** -- Deep protocol knowledge, full API reference, permit system details
- **lbamm-integrator** -- DEX integration (LBAMM pools may use WNATIVE)
- **tokenmaster-integrator** -- Token economy integration (pools may use WNATIVE as reserve)