CCA Deployment

Deploy Continuous Clearing Auction (CCA) smart contracts using the ContinuousClearingAuctionFactory with CREATE2 for consistent addresses across chains.

Runtime Compatibility: This skill uses AskUserQuestion for interactive prompts. If AskUserQuestion is not available in your runtime, collect the same parameters through natural language conversation instead.

Instructions for Claude Code

When the user invokes this skill, guide them through the CCA deployment process with appropriate safety warnings and validation.

Pre-Deployment Requirements

Before proceeding with deployment, you MUST:

1. Show educational disclaimer and get user acknowledgment
2. Validate configuration file if provided
3. Verify factory address for the target network
4. Confirm deployment parameters with user

Deployment Workflow

1. Show Educational Disclaimer (REQUIRED)
2. Load or Request Configuration
3. Validate Configuration
4. Display Deployment Plan
5. Get User Confirmation
6. Provide Deployment Commands
7. Post-Deployment Steps

---

⚠️ Educational Use Disclaimer

IMPORTANT: Before proceeding with deployment, you must acknowledge:

This tool and all deployment instructions are provided for educational purposes only. AI-generated deployment commands may contain errors or security vulnerabilities.

You must:

1. ✅ Review all configurations carefully before deploying
2. ✅ Verify all parameters (addresses, pricing, schedules) are correct
3. ✅ Test on testnets first before deploying to mainnet
4. ✅ Audit your contracts before deploying with real funds

Use AskUserQuestion to confirm the user acknowledges these warnings before proceeding with deployment steps.

Input Validation Rules

Before interpolating ANY user-provided value into forge/cast commands or deployment scripts:

• Ethereum addresses: MUST match ^0x[a-fA-F0-9]{40}$ — reject otherwise
• Chain IDs: MUST be from the supported chains list (1, 130, 143, 1301, 8453, 42161, 11155111)
• Numeric values (supply, prices, blocks, chain IDs): MUST be non-negative and match ^[0-9]+\.?[0-9]*$
• REJECT any input containing shell metacharacters: ;, |, &, $, `, (, ), >, <, \, ', ", newlines
• Never pass raw user input directly to shell commands without validation

⚠️ Permission Safety

Do NOT auto-approve Bash(forge:*) or Bash(cast:*) in your Claude Code settings. Always require per-invocation approval for commands that spend gas or broadcast transactions. The PreToolUse hooks in .claude/hooks/ provide programmatic validation as a safety net, but user approval per command is the primary control.

---

🔐 Private Key Security

CRITICAL: Handling private keys safely is essential for secure deployments.

⚠️ Never Do These

• ❌ Never store private keys in git repositories or config files
• ❌ Never paste private keys directly in command line (visible in shell history)
• ❌ Never share private keys or store them in shared environments
• ❌ Never use mainnet private keys on untrusted computers
• ❌ Never use --private-key flag (blocked by PreToolUse hook)

✅ Recommended Practices

Option 1: Hardware Wallets (Most Secure)

Use Ledger or Trezor hardware wallets with the --ledger flag:

forge script script/Example.s.sol:ExampleScript \
  --rpc-url $RPC_URL \
  --broadcast \
  --ledger

Option 2: Encrypted Keystore

Create an encrypted keystore with cast wallet import:

# Import private key to encrypted keystore (one-time setup)
cast wallet import deployer --interactive

# Use keystore for deployment
forge script script/Example.s.sol:ExampleScript \
  --rpc-url $RPC_URL \
  --broadcast \
  --account deployer \
  --sender $DEPLOYER_ADDRESS

Option 3: Environment Variables (For Testing Only)

If using environment variables, ensure they are:

• Set in a secure .env file (never committed to git)
• Loaded via source .env or dotenv
• Only used on trusted, secure computers
• Use testnet keys for development

Example:

# .env file (add to .gitignore)
PRIVATE_KEY=0x...
RPC_URL=https://...

# Load environment
source .env

# Deploy (use encrypted keystore instead of --private-key)
cast wallet import deployer --interactive
forge script ... --account deployer --sender $DEPLOYER_ADDRESS

Testnet First

Always test on testnets before mainnet:

• Sepolia (testnet): Get free ETH from faucets
• Base Sepolia: Free ETH for testing on Base
• Deploy and verify full workflow on testnet
• Only deploy to mainnet after thorough testing

---

Deployment Guide

Factory Deployment

CCA instances are deployed via the ContinuousClearingAuctionFactory contract, which uses CREATE2 for consistent addresses across chains.

Factory Addresses

Version	Address	Status
v1.1.0	0xCCccCcCAE7503Cac057829BF2811De42E16e0bD5	Recommended

Deploying an Auction Instance

Step 0: Clone the CCA Repository

If you don't already have the CCA contracts locally, clone the repository and install dependencies:

git clone https://github.com/Uniswap/continuous-clearing-auction.git
cd continuous-clearing-auction
forge install

This gives you access to the deployment scripts, contract ABIs, and test helpers referenced in later steps.

Step 1: Prepare Configuration

Ensure you have a valid configuration file (generated via the configurator skill or manually created).

Example configuration file structure:

{
  "1": {
    "token": "0x...",
    "totalSupply": 1e29,
    "currency": "0x0000000000000000000000000000000000000000",
    "tokensRecipient": "0x...",
    "fundsRecipient": "0x...",
    "startBlock": 24321000,
    "endBlock": 24327001,
    "claimBlock": 24327001,
    "tickSpacing": 79228162514264337593543950,
    "validationHook": "0x0000000000000000000000000000000000000000",
    "floorPrice": 7922816251426433759354395000,
    "requiredCurrencyRaised": 0,
    "supplySchedule": [
      { "mps": 1000, "blockDelta": 6000 },
      { "mps": 4000000, "blockDelta": 1 }
    ]
  }
}

Step 2: Validate Configuration

Before deployment, verify the configuration passes all validation rules (see Validation Rules section).

Step 3: Deploy via Factory

The factory has a simple interface:

function initializeDistribution(
    address token,
    uint256 amount,
    bytes calldata configData,
    bytes32 salt
) external returns (IDistributionContract);

Where:

• token: Address of the token to be sold
• amount: Amount of tokens to sell in the auction
• configData: ABI-encoded AuctionParameters struct
• salt: Optional bytes32 value for vanity address mining

Step 3.5: Encode Configuration to configData

The factory's initializeDistribution expects configData as ABI-encoded AuctionParameters. Convert your JSON config to encoded bytes:

Using cast (Foundry CLI):

# Encode the AuctionParameters struct
cast abi-encode "initializeDistribution(address,uint256,bytes,bytes32)" \
  "$TOKEN_ADDRESS" \
  "$TOTAL_SUPPLY" \
  "$(cast abi-encode "(address,address,address,uint64,uint64,uint64,uint256,address,uint256,uint128,bytes)" \
    "$CURRENCY" \
    "$TOKENS_RECIPIENT" \
    "$FUNDS_RECIPIENT" \
    "$START_BLOCK" \
    "$END_BLOCK" \
    "$CLAIM_BLOCK" \
    "$TICK_SPACING" \
    "$VALIDATION_HOOK" \
    "$FLOOR_PRICE" \
    "$REQUIRED_CURRENCY_RAISED" \
    "$ENCODED_SUPPLY_SCHEDULE")" \
  "0x0000000000000000000000000000000000000000000000000000000000000000"

Using a Foundry Script:

// script/DeployAuction.s.sol
pragma solidity ^0.8.24;

import "forge-std/Script.sol";

interface ICCAFactory {
    function initializeDistribution(
        address token,
        uint256 amount,
        bytes calldata configData,
        bytes32 salt
    ) external returns (address);
}

contract DeployAuction is Script {
    function run() external {
        // Load config values
        address token = vm.envAddress("TOKEN");
        uint256 amount = vm.envUint("TOTAL_SUPPLY");

        // Encode AuctionParameters
        bytes memory configData = abi.encode(
            vm.envAddress("CURRENCY"),
            vm.envAddress("TOKENS_RECIPIENT"),
            vm.envAddress("FUNDS_RECIPIENT"),
            uint64(vm.envUint("START_BLOCK")),
            uint64(vm.envUint("END_BLOCK"))
how to use deployer
CursorClaude CodeClineCodexWindsurfGooseGitHub CopilotVS CodeGemini CLIKiloOpencodeKimi CLIRoo ClineAiderContinueZedBolt.newLovablev0Replit AgentSweepSmol DeveloperDevinCavemanAmpAntigravity
How to use deployer on Cursor
AI-first code editor with Composer
1
Prerequisites
Before installing skills in Cursor, ensure your development environment meets these requirements:
›Cursor installed and configured on your development machine
›Node.js version 16.0+ with npm package manager (verify with node --version)
›Active project directory or workspace where you want to add deployer
2
Execute installation command
Execute the skills CLI command in your project's root directory to begin installation:
$npx skills add https://github.com/uniswap/uniswap-ai --skill deployercopy
The skills CLI fetches deployer from GitHub repository uniswap/uniswap-ai and configures it for Cursor.
3
Select Cursor when prompted
The CLI will show a list of available agents. Use arrow keys to navigate and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ── always included ────
│   • Amp
│   • Antigravity
│   • Cline
│   • Codex
│ ●Cursor(selected)
│   • Cursor
│   • Windsurf
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/deployer
Reload or restart Cursor to activate deployer. Access the skill through slash commands (e.g., /deployer) or your agent's skill management interface.
⚠
Security & Verification Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your development environment. Always verify the publisher's identity, review recent commits, and test in isolated environments before production deployment.
Additional Resources
›View source code on GitHub›Skills CLI documentation›Learn more about Cursor›What are agent skills?