Deployer
Deploy CCA (Continuous Clearing Auction) smart contracts using the Factory pattern. Use when user says "deploy auction", "deploy cca", "factory deployment", or wants to deploy a configured auction.
- Skill ID
- uniswap/uniswap-ai/deployer
- Publisher
- uniswap
- Repository
- uniswap-ai
- Installs
- 0
- Files
- 1
- License
- MIT
- Synced
- Sep 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
uniswap/uniswap-ai/deployerInstalls these files- SKILL.md
What this skill tells the agent
CCA Deployment
Deploy Continuous Clearing Auction (CCA) smart contracts using the ContinuousClearingAuctionFactory with CREATE2 for consistent addresses across chains.
Runtime Compatibility: This skill usesAskUserQuestionfor interactive prompts. IfAskUserQuestionis 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:
- Show educational disclaimer and get user acknowledgment
- Validate configuration file if provided
- Verify factory address for the target network
- Confirm deployment parameters with user
Deployment Workflow
- Show Educational Disclaimer (REQUIRED)
- Load or Request Configuration
- Validate Configuration
- Display Deployment Plan
- Get User Confirmation
- Provide Deployment Commands
- 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:
- ✅ Review all configurations carefully before deploying
- ✅ Verify all parameters (addresses, pricing, schedules) are correct
- ✅ Test on testnets first before deploying to mainnet
- ✅ 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, 1301, 8453, 42161, 11155111)
- Numeric values (supply, prices, blocks, chain IDs): MUST be non-negative and match
^[0-9]+\.?[0-9]*$ - RPC endpoint URL (
$RPC_URL): MUST behttps://-scheme and MUST NOT contain any metacharacter or whitespace from the rule below. This value does not come from the configuration file, the user supplies it during the walkthrough, and it reaches--rpc-urlon everyforge script,cast send, andforge verify-contractcommand below. "It came from the user, not the config" is not an exemption. Validate it the first time it is supplied, assign it to$RPC_URL, and reference only that variable afterwards; never re-read a raw URL into a later command. An endpoint whose URL needs a query string (a provider API key, for example) is exported into the environment out of band and referenced as$RPC_URL, never pasted into command text. - REJECT any input containing shell metacharacters or whitespace:
;,|,&,$, ``,(,),>,<,\,',", spaces, tabs, newlines.$(...)and backticks execute even inside double quotes, and a space splits one value into extraforge/cast` flags, so neither is ever safe to interpolate. Abort and report which value and which character failed rather than stripping the offending characters and continuing. - Never pass raw user input directly to shell commands without validation
- Always double-quote every interpolation in a generated command (write
--rpc-url "$RPC_URL", never the bare unquoted form). Quoting is the second layer, not the first: validate the value before it reaches the command, then quote it as well.
⚠️ 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-keyflag (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 \
--ledgerOption 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
.envfile (never committed to git) - Loaded via
source .envordotenv - 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 installThis 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 saltMore from uniswap
Use this skill in a project
Open any RiverX project, search the Skills panel for uniswap/uniswap-ai/deployer, and install it in one click.
