Key Takeaways
- Chialisp multisig uses BLS signature aggregation to verify multiple public keys in a single spend bundle
- Threshold signing (m-of-n) allows you to require a specific number of signatures before coins can be spent
- Time-locks add temporal conditions that prevent spending until a specific block height or timestamp
- Security best practices include binding signatures to coin IDs and using announcements to prevent signature reuse
- Advanced patterns combine multisig with singletons, CATs, and offer files for enterprise-grade custody solutions
Article Summary
Chialisp multisig is a puzzle pattern that locks coins until a threshold of valid BLS signatures is provided, enabling secure multi-party custody through m-of-n threshold signing, while time-locks add block height or timestamp restrictions to prevent premature spending.
Understanding Chialisp Multisig Fundamentals
Multisig, short for multi-signature, is one of the most important security patterns in blockchain development. In Chialisp, multisig works differently than in Bitcoin or Ethereum because Chia uses a coin-based model instead of accounts. Each coin has its own puzzle that controls how it can be spent.
Think of a multisig wallet like a bank vault that needs three different keys to open. You might set it up so any two out of three keys can unlock it. This is called a 2-of-3 multisig. The same idea applies to Chialisp, except instead of physical keys, we use cryptographic public keys and digital signatures.
The power of Chialisp multisig comes from BLS signatures, which can be aggregated into a single signature. This makes multisig transactions on Chia much more efficient than on other blockchains. Instead of checking each signature separately, the blockchain verifies one combined signature that proves all required parties have approved the spend.
How BLS Signature Aggregation Works
BLS signatures have a special property: you can combine multiple signatures into one without losing security. When Alice, Bob, and Carol each sign a transaction, their three signatures can merge into a single signature that proves all three approved it. The Chia blockchain checks this one signature instead of three separate ones.
This aggregation happens automatically in every spend bundle. Your multisig puzzle just needs to verify that the right public keys have signed. The actual signature checking happens at the blockchain level, not inside your puzzle code.
Coin-Based vs Account-Based Multisig
In account-based blockchains like Ethereum, multisig is a smart contract that controls an account balance. In Chialisp, multisig is a puzzle that locks individual coins. This means each coin you create can have different multisig rules. You might have some coins requiring 2-of-3 signatures and others requiring 3-of-5.
Building Your First Multisig Puzzle
Let’s build a simple 2-of-3 multisig puzzle step by step. This puzzle will require any two signatures from a set of three authorized public keys. We’ll use the AGG_SIG_ME condition, which tells the blockchain to verify that a specific public key has signed this exact spend.
The Basic Structure
A multisig puzzle needs to check three things: which public keys are authorized, how many signatures are required, and what conditions the spend must meet. Here’s a simplified version of how this works:
(mod (
PUBLIC_KEYS ; list of authorized pubkeys
MIN_SIGS ; minimum required signatures
conditions ; spending conditions to create
)
; Verify enough valid signatures are present
; Return the spending conditions if valid
; Raise error if not enough signatures
)The puzzle receives a list of public keys that are allowed to sign. It checks that at least MIN_SIGS of those keys have signed the spend bundle. If the check passes, it returns the spending conditions. If not, the spend fails.
Using AGG_SIG_ME Conditions
The AGG_SIG_ME condition is your main tool for checking signatures. It takes two parameters: a public key and a message. The blockchain verifies that this public key has signed this specific message. For multisig, the message is usually the spending conditions themselves, which prevents someone from reusing signatures for different transactions.
When implementing secure multisig patterns in Chialisp, it’s critical to bind signatures tightly to the specific coin being spent. The AGG_SIG_ME condition accomplishes this by including both the coin ID and genesis challenge in what gets signed, making signature replay attacks impossible across different coins or networks.
Implementing Threshold Logic
The tricky part of multisig is counting signatures correctly. You need to verify that at least m signatures are present without checking all n keys. One approach is to require signers to provide their signatures in a specific order, then verify that order matches your key list.
A more flexible approach uses a Merkle tree to store your public keys. Signers prove their key is in the tree without revealing other keys. This improves privacy because observers can’t see which keys were used or how many total keys exist.
Adding Time-Locks to Multisig Puzzles
Time-locks add temporal restrictions to your multisig. There are two types: absolute time-locks that prevent spending until a specific block height or timestamp, and relative time-locks that require a certain number of blocks to pass after coin creation.
Time-locks are essential for vesting schedules, escrow agreements, and emergency recovery mechanisms. For example, you might create a multisig that requires 3-of-5 signatures normally, but after 6 months, it only requires 2-of-5. This gives you flexibility if a key is lost.
Absolute Time-Locks with ASSERT_HEIGHT_ABSOLUTE
The ASSERT_HEIGHT_ABSOLUTE condition prevents spending until the blockchain reaches a specific height. If you create a coin at height 1,000,000 and add ASSERT_HEIGHT_ABSOLUTE with value 1,100,000, the coin cannot be spent for approximately 100,000 blocks (about 23 days).
; Multisig that unlocks after block 2000000
(mod (pubkeys conditions)
(list
(list AGG_SIG_ME pubkey1 message)
(list AGG_SIG_ME pubkey2 message)
(list ASSERT_HEIGHT_ABSOLUTE 2000000)
conditions
)
)This pattern is useful for vesting tokens. An employee receives coins that are locked for one year. After that year passes, they can spend the coins using the multisig keys. Until then, even with valid signatures, the spend will fail.
Relative Time-Locks with ASSERT_HEIGHT_RELATIVE
ASSERT_HEIGHT_RELATIVE counts blocks from when the coin was created. This is perfect for escrow services. When two parties enter an escrow agreement, they create a coin that requires both signatures. But if one party disappears, the other can recover funds after a set time period using a different puzzle reveal.
The coin might have two spend paths: one requiring 2-of-2 signatures (both parties agree), and another requiring one signature plus proof that 30 days have passed. The relative time-lock ensures the recovery path can’t be used immediately.
Combining Multiple Time Conditions
You can stack multiple time conditions for complex custody rules. A company treasury might require 3-of-5 signatures normally, but 2-of-5 after 90 days, and only 1-of-5 after 180 days. Each time threshold activates a different puzzle reveal with different requirements.
Security Best Practices for Multisig
Building secure multisig puzzles requires careful attention to several attack vectors. The most dangerous is signature reuse, where an attacker takes signatures from one spend and applies them to a different spend. If your puzzle doesn’t bind signatures to specific coins, this attack succeeds.
Preventing Signature Reuse Attacks
Every AGG_SIG_ME condition should include the coin ID in the message being signed. This creates a unique signature for each coin. Even if Alice signs to spend coin A, that signature won’t work to spend coin B because the messages are different.
The standard pattern is to include the coin ID and the conditions being created in the signature message. This binds the signature to both the specific coin being spent and the exact outputs being created. An attacker can’t modify either without invalidating the signature.
Using Announcements for Extra Security
Announcements are special conditions that declare information without changing state. They’re useful for preventing certain multisig attacks. When creating a multisig spend, you can add an announcement that includes a nonce (random number used once). This ensures each spend is unique, even if spending the same coin multiple times in different scenarios.
For example, if you’re creating a multisig that might be used in an offer file, include an announcement of the offer ID. This prevents someone from taking your signatures and using them in a different offer.
Key Management and Rotation
Unlike account-based multisig, Chialisp can’t update keys in place. To rotate keys, you must spend the old coin and create a new one with the new key set. This has a cost, but it also provides a clear audit trail. Every key change is visible on the blockchain.
Best practice is to plan for key rotation from the start. Use a singleton wrapper around your multisig (covered next) so you can update keys while maintaining the same singleton ID. This gives you a stable identifier even as underlying keys change.
Advanced Patterns: Singleton Multisig
Singletons are special coins that maintain a unique identity across spends. They’re perfect for multisig custody because they give you a stable address that persists even when you rotate keys. The Chia prefarm custody system uses this pattern.
A singleton multisig works by wrapping your multisig puzzle inside a singleton puzzle. The singleton maintains its identity (a unique launcher ID), while the inner puzzle can change. This means you can update your multisig from 2-of-3 to 3-of-5 without changing the singleton ID.
Building a Singleton Multisig Wrapper
The outer singleton puzzle handles identity and state transitions. The inner multisig puzzle handles authorization. When you want to spend the singleton, you must satisfy both: prove you have the right singleton (by referencing its launcher ID) and prove you have enough valid signatures.
This pattern is especially useful for DAOs and treasuries. The DAO has a stable singleton ID that receives funds. The multisig keys can change as members join or leave. But the singleton ID stays the same, so people know where to send funds.
Merkle Tree Key Storage
For large multisigs (like 10-of-20), storing all public keys in the puzzle is inefficient. Instead, store a Merkle root of the keys. When spending, provide Merkle proofs showing which keys signed. This hides the total number of keys and improves privacy.
Chia’s prefarm custody uses this approach. The puzzle stores a Merkle root. Each signer provides their public key and a Merkle proof. The puzzle verifies the proof, checks the signature, and counts how many valid proofs were provided. If the count meets the threshold, the spend succeeds.
Integrating Multisig with CATs and Offers
Chialisp Asset Tokens (CATs) can use multisig for governance. A CAT might require 3-of-5 signatures from the issuer’s board to mint new tokens. This prevents any single board member from inflating the supply.
Multisig CAT Issuance
The CAT issuance puzzle can include multisig logic. When creating new CAT coins, the puzzle checks that enough authorized keys have signed. This is useful for security tokens or governance tokens where issuance must be controlled by multiple parties.
For example, a company could implement equity tokens as CATs with an issuance puzzle requiring 3-of-5 board member signatures. When the board approves a new funding round, three members sign the issuance transaction. The new tokens are minted and distributed to investors.
Multisig in Offer Files
Offer files can include multisig-locked coins. Alice creates an offer where she provides 1000 XCH locked in a 2-of-3 multisig. Bob accepts by providing his side of the trade. The offer completes, and Bob receives a multisig coin. He needs two of the three keys to spend it later.
This pattern enables atomic swaps with built-in custody. A hedge fund might trade millions of dollars of tokens through offers while ensuring the received funds are immediately protected by multisig. The trade and custody setup happen in one atomic transaction.
Cross-Chain Multisig Bridges
Bridge protocols that move assets between Chia and other blockchains often use multisig for security. A set of validators run a multisig wallet on Chia. When someone wants to bridge tokens from Ethereum to Chia, they lock tokens in an Ethereum contract. The validators verify the lock, then sign a Chia transaction to mint wrapped tokens. No single validator can mint tokens alone.
Real-World Case Study: Chia Prefarm Custody
The Chia Network prefarm custody system manages 21 million XCH using a sophisticated singleton multisig architecture. The system, implemented in October 2022 and actively used through 2025, requires multiple signatures from board members and executives for any spend, with Merkle tree key storage for privacy and scalability.
The prefarm is distributed across four wallets (two in North America, two in Europe), with each wallet using a 3-of-5 multisig configuration for cold storage. Hardware Security Modules (HSMs) located in Faraday cages hold the private keys, ensuring offline signing. The cold wallet system includes a 30-day withdrawal initiation timelock and a 90-day clawback period after withdrawal is initiated, providing multiple layers of security against unauthorized access.
Warm wallets, which hold one-eighth of each location’s allocation, use a 2-of-3 multisig configuration with shorter timeframes: a 1-hour withdrawal timelock and 24-hour clawback period. This two-tier approach balances security with operational flexibility for routine transactions.
This custody solution demonstrates how singleton multisig enables key rotation without changing the wallet’s identity. The system can rekey to a new set of public keys while maintaining the same singleton launcher ID, ensuring continuity for external parties sending funds to the prefarm addresses. As of December 2025, the system continues to facilitate operational transfers, including a 1.5 million XCH transfer initiated for the Permuto launch and ongoing development needs.
Conclusion
Chialisp multisig combines threshold signing, BLS signature aggregation, and time-locks to create powerful custody solutions. You’ve learned how to build basic m-of-n multisig puzzles, add temporal restrictions, prevent signature reuse attacks, and integrate multisig with singletons, CATs, and offers. These patterns form the foundation of enterprise-grade security on Chia.
Start by implementing a simple 2-of-3 multisig for your test environment. Experiment with time-locks and singleton wrappers. As you master these patterns, you’ll be ready to build production custody systems that protect significant value. The next lesson will cover puzzle assertions and coin introspection, which unlock even more advanced patterns.
Chialisp Multisig Tutorial FAQs
What is chialisp multisig and how does it differ from Bitcoin multisig?
Chialisp multisig is a puzzle pattern that requires a threshold of valid BLS signatures to spend coins, differing from Bitcoin by using signature aggregation instead of separate signature checks. This makes Chialisp multisig more efficient and privacy-preserving, as all signatures combine into one.
How do I implement a basic 2-of-3 multisig in Chialisp?
A basic 2-of-3 chialisp multisig puzzle checks that at least two AGG_SIG_ME conditions are satisfied from a list of three authorized public keys, binding each signature to the specific coin ID and spending conditions. The puzzle returns the spending conditions only when the threshold is met.
Can I combine chialisp multisig with time-locks for vesting schedules?
Yes, chialisp multisig works perfectly with time-locks by adding ASSERT_HEIGHT_ABSOLUTE or ASSERT_HEIGHT_RELATIVE conditions to your puzzle. This enables vesting schedules where coins unlock at specific block heights or after a certain number of blocks have passed since creation.
What are the main security risks when building multisig puzzles?
The main security risk in chialisp multisig is signature reuse, where attackers replay signatures from one spend to another coin. Prevent this by binding each AGG_SIG_ME to the specific coin ID and including announcements with unique nonces.
How does singleton multisig enable key rotation on Chia?
Singleton multisig maintains a stable identity (launcher ID) while allowing the inner multisig puzzle to change through spends. This enables key rotation by creating a new coin with updated keys while preserving the singleton’s unique identifier for consistent addressing.
Chialisp Multisig Tutorial Citations
- Chia Network. “Signatures – Chia Documentation.” https://docs.chia.net/chialisp-signatures/
- Chia Network. “Custody Tool Description – Chia Documentation.” https://docs.chia.net/guides/custody-tool-description/
- Chialisp. “Conditions Reference.” https://chialisp.com/conditions/
- Chialisp. “Security – Signature Reuse and Subtraction.” https://chialisp.com/docs/security
- Chia Network. “Intro to Chialisp – Chia Documentation.” https://docs.chia.net/guides/crash-course/intro-to-chialisp/
- Chia Network. “Coin Set Intro – Chia Documentation.” https://docs.chia.net/coin-set-intro/
- Boneh, Dan, Lynn, Ben, and Shacham, Hovav. “Short Signatures from the Weil Pairing.” In Advances in Cryptology — ASIACRYPT 2001, Lecture Notes in Computer Science, vol. 2248, pages 514-532. Springer, 2001. Journal version: Journal of Cryptology 17(4):297-319, September 2004. https://www.iacr.org/archive/asiacrypt2001/22480516.pdf
- Chia Network. “Offers – Chia Academy.” https://docs.chia.net/academy-offers/
- Chia Network. “CATs (Chia Asset Tokens) – Chia Academy.” https://docs.chia.net/academy-cat/
