XION
DiscordGithub
  • Welcome to XION
  • XION'S Core
    • Concepts
      • Generalized Chain Abstraction
      • Intro to Account Abstraction
      • XION's Meta Accounts
      • Meta Accounts Design
      • Architecture & Tech Glossary
      • Use Cases
  • developers
    • Xion Quick Start
      • Zero to Dapp in 5 Minutes
        • Launch a User Map Dapp on XION in 5 Minutes
        • React Native Mobile Dapp on XION in 5 Minutes
    • Mobile dapp Development on XION
      • Set up your XION Mobile Development Environment
      • Create Mobile Dapp and Integrate Meta Account Authentication
    • Getting Started (Advanced)
      • Set Up Local Environment
        • Setting up your Local Smart Contract Development Environment for XION
          • Setting up your XION Smart Contract Development Environment on Windows (WSL2 + Ubuntu)
        • Set Up an Integrated Development Environment (IDE)
        • Interacting with Xion Chain using Xion Daemon
      • Your First Contract
        • Deploying Your First Smart Contract on XION
      • Gasless UX & Permission Grants
        • Enabling Gasless Transactions with Treasury Contracts
      • Dapp Development
        • Account Abstraction with Gasless Transactions
        • Interact with XION via your Backend Service
    • Re-using Existing Contracts
      • Deployed Contracts on XION
      • Non-Fungible Tokens (NFTs)
      • Fungible Tokens
      • Marketplace
      • Multisig
      • Proxy Contracts
      • Membership Management
    • Web3 for Web2 Developers
      • Web2 vs Web3 App Architecture: A Comparison
      • Misconceptions and Misapplied Web2 Patterns
      • Recommended Architecture for Dapps on XION
    • Building for Mainnet
      • Xion Testnet: Your Development Playground
      • Building with Audited & Battle-Tested Contracts
      • Community Engagement: Building Support for Your dApp
      • Deploying to Xion Mainnet
        • Smart Contract Audits: Process, Costs & Support
        • Governance Process to Deploying Smart Contracts to Mainnet
    • Learn & Build
      • Token Factory
        • Creating, Minting, and Interacting with a Token Factory Token
        • Building a React dApp to Interact with Token Factory Tokens
        • Integrating a Token Factory Token in a Smart Contract
      • Websockets
        • WebSockets with Xion: Real-Time Communication
      • Mobile Development
        • Building a React Native Mobile App with Abstraxion (Xion.js)
      • Oracles
        • Creating a Smart Contract with Pyth Oracle Integration
      • Indexers: Optimized Data Retrieval
        • SubQuery
      • Use Cases
        • Building a Per-User Data Storage Dapp
    • Reference and Resources
      • Requesting XION Testnet Tokens
      • Public Endpoints & Resources
      • Block Explorers
      • Governance
        • Deploying Smart Contracts to Mainnet
      • Developer Tools: Abstract
      • IBC Denoms on XION Networks
      • Frequently Asked Questions
      • XION Token Contract Addresses on EVM Chains
  • Nodes & Validators
    • Run a Node
      • System Specifications
      • Build the Xion Daemon
      • Download the Xion Daemon
      • Configure the Xion Daemon
        • app.toml
        • client.toml
        • config.toml
      • Join the XION Network
        • xion-testnet-1
      • Confirm node is running
    • Become a Validator
      • Initial Setup
      • Obtain a XION Wallet Address
      • Obtain Funds
        • Testnet
      • Create Validator
    • IBC Relayers and Tokens
  • Others
    • Resources
Powered by GitBook
On this page

Was this helpful?

Edit on GitHub
  1. developers
  2. Re-using Existing Contracts

Proxy Contracts

Proxy contracts act on behalf of one or more users, allowing controlled execution of transactions or actions under specific conditions. Instead of a user calling contracts directly, they can delegate that responsibility to a proxy, which then executes the desired operations, either automatically or with certain restrictions.

In the CosmWasm and XION ecosystem, proxy contracts are commonly used for:

  • Delegating transaction execution

  • Granting limited permissions to third parties or apps

  • Enabling programmable account logic

  • Simulating multisig-like behavior without full governance

Proxy Contracts

The CW1 standard defines a generic proxy interface for executing messages on behalf of others. Two primary CW1-based contracts demonstrate its flexibility.

Contract
Access Control
Allowance Tracking
Use Case

cw1-whitelist

Whitelisted addresses

No

Admin execution, limited delegation

cw1-subkeys

Per-address allowances

Yes

Spend limits, delegated token control

1. cw1-whitelist

A minimal, reference implementation of a CW1 proxy contract where only whitelisted addresses can execute messages through the proxy. Features:

  • Owner controls the list of allowed executors

  • Whitelisted users can call Execute on the proxy, forwarding messages

  • Simple access control pattern for demonstration or lightweight usage

2. cw1-subkeys

A practical CW1 proxy that allows setting spending allowances (especially for native tokens) per address. Features:

  • Assigns per-address allowances for native tokens

  • Tracks balance usage and enforces limits

  • Enables more granular control without modifying the bank module

  • Allows users to delegate spend permissions without sharing private keys

PreviousMultisigNextMembership Management

Last updated 2 days ago

Was this helpful?

Ideal for: Use cases where only trusted addresses (like admins or bots) should trigger transactions on behalf of the contract šŸ“¦ Repo:

Ideal for: Gasless UX, spend limits, delegated spending by apps or services (e.g. subscription models, wallets) šŸ“¦ Repo:

cw1-whitelist
cw1-subkeys