Prerequisites
- Understanding of Neutron governance processes
- Familiarity with CosmWasm contract development
- Access to governance proposal submission (for schedule creation)
Understanding Cron Module Access
The Cron module is governance-gated, meaning:- Only governance can create or remove schedules
- Individual users and contracts cannot directly interact with this module
- Schedule management requires proposals to either:
- Main DAO: Can create and remove any schedule
- Security SubDAO: Can remove schedules (emergency situations)
No Individual Access: Unlike other modules, the Cron module does not accept direct user transactions. All schedule management must go through governance proposals.
Neutron uses a modular governance system with specialized subDAOs that handle different aspects of network management. The Security SubDAO can remove schedules in emergency situations, providing a safety mechanism for the network.
Creating Schedules Through Governance
Step 1: Prepare Your Governance Proposal
To create a schedule, you need to submit a governance proposal using the DAO contract format. Here’s the structure for adding a schedule:Step 2: Understanding the Message Structure
TheMsgAddSchedule
message contains:
authority
: Address of the governance authorityname
: Unique identifier for the scheduleperiod
: Number of blocks between executionsmsgs
: Array of contract messages to executecontract
: Address of the contract to callmsg
: JSON string of the message to send
execution_stage
: When to execute (EXECUTION_STAGE_BEGIN_BLOCKER
orEXECUTION_STAGE_END_BLOCKER
)
Step 3: Submit the Governance Proposal
Standard Governance Proposal
Submit the proposal using the standard governance module:Step 4: Governance Voting Process
Once submitted, the proposal goes through the standard governance process:- Proposal Period: Community can review the proposal
- Voting Period: NTRN token holders vote on the proposal
- Execution: If passed, the schedule is automatically created
Preparing Your Contract for Scheduled Execution
Handle Scheduled Messages
Your contract must be prepared to receive messages from the Cron module account:Design Considerations
When designing your contract for scheduled execution:Common Use Cases and Examples
Protocol Maintenance
For regular protocol maintenance tasks:Reward Distribution
For periodic reward distribution:Multi-Message Schedule
For complex operations requiring multiple contract calls:Removing Schedules
Standard Removal (Main DAO)
To remove a schedule through Main DAO governance:Emergency Removal (Security SubDAO)
The Security SubDAO can also submitremove_schedule
proposals for emergency situations:
Best Practices
Governance Proposal Strategy
- Clear Documentation: Include detailed rationale for the schedule
- Community Engagement: Discuss the proposal with the community first
- Testing: Test your contract’s scheduled execution on testnet
- Monitoring: Plan for monitoring and maintenance of the schedule
Contract Design
- Idempotent Operations: Design scheduled tasks to be safely re-runnable
- Error Handling: Implement robust error handling for scheduled executions
- State Validation: Add checks to prevent unexpected state changes
- Logging: Include comprehensive logging with meaningful attributes
- Sender Verification: Optionally verify the sender is the Cron module account
Schedule Parameters
- Appropriate Periods: Choose block intervals that match your use case
- Daily: ~7200 blocks (assuming 12-second blocks)
- Weekly: ~50400 blocks
- Monthly: ~216000 blocks
- Execution Stage: Choose BEGIN_BLOCKER or END_BLOCKER based on dependencies
- Message Format: Ensure messages are valid JSON strings for contract execution
- Atomicity: Group related operations in a single schedule for atomic execution
- Descriptive Names: Use clear, descriptive names that indicate the schedule’s purpose
Monitoring and Troubleshooting
Querying Schedules
To check existing schedules:Common Issues and Solutions
Issue | Possible Cause | Solution |
---|---|---|
Proposal rejected | Insufficient community support | Engage with community, revise proposal |
Schedule not executing | Execution failures or limit reached | Check contract logic, monitor events |
Execution failures | Invalid message format or contract errors | Test messages manually, check contract state |
Schedule not found | Governance proposal failed | Verify proposal passed and was executed |
Debugging Steps
- Verify Governance: Check if the governance proposal passed and was executed
- Query Schedule: Confirm the schedule exists with correct parameters
- Monitor Logs: Check validator logs for schedule execution information
- Test Manually: Execute the scheduled message manually to verify contract logic
- Check Limits: Ensure the schedule isn’t being skipped due to block limits
Event Monitoring
The Cron module does not emit blockchain events. Schedule execution and management operations are logged internally but do not generate events that can be monitored externally. Use the query commands to check schedule status and execution history.Security Considerations
Governance Security
- Proposal Review: Thoroughly review all governance proposals
- Community Oversight: Ensure adequate community review period
- Emergency Procedures: Understand Security SubDAO removal capabilities
- Testing: Always test on testnet before mainnet proposals
Contract Security
- Access Control: Consider implementing additional access controls in your contracts
- Input Validation: Validate all inputs in scheduled message handlers
- State Protection: Protect critical state from unauthorized modifications
- Failure Handling: Handle execution failures gracefully without breaking contract state