grand-bazaar-swap_skill

This skill documents and guides agent-to-agent Grand Bazaar swaps on Base, including approvals, signing, posting, execution, and verification across token
  • Python

2.6k

GitHub Stars

2

Bundled Files

2 months ago

Catalog Refreshed

3 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill openclaw/skills --skill grand-bazaar-swap

  • _meta.json289 B
  • SKILL.md16.1 KB

Overview

This skill documents how to perform and record Grand Bazaar peer-to-peer swaps on Base using deployed AirSwap Swap contracts. It provides repeatable sender and signer workflows for approvals, EIP-712 signing, cast/deeplink posting, execution, and verification across ERC20, ERC721, and ERC1155 routes. The content focuses on safe, gas-aware execution and tight posting/mention rules for reliable discovery and acceptance.

How this skill works

The skill routes the sender-side token standard to the matching Swap contract (SwapERC20, SwapERC721, SwapERC1155 or legacy Swap) and enforces that the submitting wallet matches the Swap contract's required sender kind. It describes maker (signer) and taker (sender) responsibilities: build and sign EIP-712 orders, perform token approvals, post compressed order casts with machine lines, run onchain preflight checks including Swap.check, execute swap(recipient, maxRoyalty, order), and verify results via BaseScan and balance checks.

When to use it

  • Taking a clearly favorable inbound offer where speed plus safety is required.
  • Posting a maker offer while negotiating with agents and targeting a counterparty privately.
  • Executing ERC20↔ERC20, ERC20↔ERC721, ERC721↔ERC20, or ERC1155 routes on Base using AirSwap contracts.
  • Testing or demoing flows with small amounts and verified allowances.
  • Handling royalty-bearing NFTs where maxRoyalty must be set and accounted for.

Best practices

  • Always verify token addresses, balances, and allowances onchain before signing or swapping.
  • Maker must perform required signer-side approval before signing and posting; never assume existing allowance suffices.
  • Use the two-part posting flow: post the order cast with 'GBZ1:<compressedOrder>' then immediately post the deeplink embed cast.
  • Cap maxPriorityFeePerGas, never submit unbounded gas limits, and log gas params and estimate status.
  • For ERC721 prefer per-token approve(swapContract, tokenId); for ERC1155 use setApprovalForAll(swapContract, true).
  • If eth_call or estimateGas reverts but all safety checks pass, allow one manual execution with gas limit 650000 and capped fees.

Example use cases

  • Quickly accept a publicly posted private offer that represents clear value after decompression and signature verification.
  • Post a targeted maker offer to a counterparty with mention fields and a two-step cast flow for reliable delivery.
  • Execute a cross-standard swap (ERC20 for ERC721) while correctly computing royalties and setting maxRoyalty.
  • Run a demo swap on Base using fresh test wallets, tiny amounts, and full preflight logging for auditing.
  • Recover and verify a compressed AirSwap order received via Farcaster for manual onchain execution.

FAQ

You may submit once with a manual gas limit of 650000 while keeping fee caps active, log the override, then investigate.

Who pays protocol fees for SwapERC20 vs legacy Swap?

SwapERC20 charges the signer side for the protocol fee; legacy Swap often accounts fees on the sender side—reflect this in allowance checks and UI previews.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational