Documentation Index Fetch the complete documentation index at: https://mintlify.com/snapshot-labs/sx-monorepo/llms.txt
Use this file to discover all available pages before exploring further.
Spaces are the core organizational unit in Snapshot X, representing governance DAOs with their own voting configurations and execution strategies. Each space defines how proposals are created, how voting power is calculated, and how approved proposals are executed.
What are Spaces?
A space is a governance DAO that manages proposals, votes, and executions. Every space has:
Controller : The address that owns and manages the space
Authenticators : Methods for verifying user actions (signatures or transactions)
Voting strategies : Rules for calculating voting power
Execution strategies : How passed proposals are executed onchain
Timing parameters : Voting delay, minimum and maximum voting duration
Metadata : Space name, description, and other settings
Types of Spaces
Snapshot X supports different types of governance spaces:
Onchain Spaces
Onchain spaces are deployed as smart contracts and indexed by the Snapshot X API. There are three protocols:
Snapshot X Native Snapshot X spaces with full flexibility for strategies and executors
Compound Governor Spaces using Compound’s Governor Bravo protocol
OpenZeppelin Governor Spaces using OpenZeppelin’s Governor contracts
Offchain Spaces
Offchain spaces use Snapshot’s gasless voting system. These spaces:
Store votes and proposals in snapshot-hub
Accept signed messages via snapshot-sequencer
Don’t require gas fees for voting
Can optionally execute proposals onchain after voting
Space Configuration
When deploying a Snapshot X space, you configure these parameters:
type SpaceParams = {
controller : string ; // Space owner address
votingDelay : number ; // Delay before voting starts (seconds)
minVotingDuration : number ; // Minimum voting period
maxVotingDuration : number ; // Maximum voting period
proposalValidationStrategy : AddressConfig ; // Who can create proposals
proposalValidationStrategyMetadataUri : string ;
daoUri : string ; // DAO metadata URI
metadataUri : string ; // Space metadata URI
authenticators : string []; // Enabled authenticators
votingStrategies : AddressConfig []; // Voting power strategies
votingStrategiesMetadata : string []; // Strategy metadata URIs
};
The AddressConfig type contains both an address and encoded parameters: type AddressConfig = {
addr : string ; // Contract address
params : string ; // ABI-encoded parameters
};
Creating a Space
Spaces are deployed using the EthereumTx client from sx.js:
import { clients } from '@snapshot-labs/sx' ;
const client = new clients . evm . EthereumTx ({
networkConfig ,
provider ,
whitelistServerUrl
});
const { address , txId } = await client . deploySpace ({
signer ,
params: {
controller: '0x...' ,
votingDelay: 0 ,
minVotingDuration: 86400 , // 1 day
maxVotingDuration: 604800 , // 7 days
proposalValidationStrategy: {
addr: '0x...' ,
params: '0x00'
},
proposalValidationStrategyMetadataUri: '' ,
daoUri: 'ipfs://...' ,
metadataUri: 'ipfs://...' ,
authenticators: [
'0x...' // ethSig authenticator
],
votingStrategies: [
{
addr: '0x...' , // Token voting strategy
params: tokenAddress
}
],
votingStrategiesMetadata: [ '' ]
},
saltNonce: '0x...'
});
The space address is deterministic based on the saltNonce, allowing you to predict the address before deployment:
const predictedAddress = await client . predictSpaceAddress ({
signer ,
saltNonce
});
Managing Spaces
Space controllers can update settings after deployment:
Update Settings
await client . updateSettings ({
signer ,
space: '0x...' ,
settings: {
minVotingDuration: 172800 , // 2 days
maxVotingDuration: 1209600 , // 14 days
votingDelay: 3600 , // 1 hour
metadataUri: 'ipfs://...' ,
daoUri: 'ipfs://...' ,
authenticatorsToAdd: [ '0x...' ],
authenticatorsToRemove: [ '0x...' ],
votingStrategiesToAdd: [{
addr: '0x...' ,
params: '0x...'
}],
votingStrategiesToRemove: [ 0 ], // Remove strategy at index 0
votingStrategyMetadataUrisToAdd: [ '' ]
}
});
Transfer Ownership
await client . transferOwnership ({
signer ,
space: '0x...' ,
owner: '0x...' // New controller address
});
Space Lifecycle
The typical flow for a governance space:
Deploy Space
Deploy the space contract with initial configuration
Create Proposals
Users create proposals using configured authenticators and validation strategies
Vote on Proposals
Users vote using their voting power calculated by voting strategies
Execute Proposals
Passed proposals are executed according to the execution strategy
Update Configuration
Space controller can modify settings as needed
Network Configuration
Each network has a configuration defining available strategies, authenticators, and factory contracts:
type NetworkConfig = {
eip712ChainId : string ;
spaceFactory : string ;
masterSpace : string ;
starknetCommit : string ;
starknetCore : string ;
herodotusAccumulatesChainId : number ;
authenticators : {
[ address : string ] : AuthenticatorConfig ;
};
strategies : {
[ address : string ] : StrategyConfig ;
};
};
For EVM networks, additional configuration includes:
type EvmNetworkConfig = {
eip712ChainId : number ;
blockTime : number ;
proxyFactory : string ;
executionStrategiesImplementations : {
SimpleQuorumVanilla ?: string ;
SimpleQuorumAvatar ?: string ;
SimpleQuorumTimelock ?: string ;
EthRelayer ?: string ;
Axiom ?: string ;
Isokratia ?: string ;
};
};
Data Flow
Spaces interact with multiple components:
Authenticators Learn how users authenticate their actions
Strategies Understand voting power calculation
Executors Explore execution patterns
Creating Proposals Start creating proposals