feat: add cron module

[ZuluSpl0it]

## Summary of changes

Added the Terra `x/cron` module and wired it into the app so governance can schedule recurring CosmWasm contract executions at begin-block or end-block.

Included:
- new `x/cron` module implementation
- cron protobuf definitions under `proto/terra/cron/v1`
- app keeper and module registration
- governance-managed cron params stored in cron keeper state
- schedule execution state for last run, last successful execution, and last execution error
- per-schedule gas limiting via `max_execution_gas`
- atomic schedule execution: all contract messages in a schedule succeed together or the schedule records failure
- panic / out-of-gas recovery so cron execution does not panic through BeginBlock or EndBlock
- cron keeper, module, and app integration tests
- cron smoke-test and auth-gate scripts
- cron spec docs under `x/cron/spec`

## Review feedback addressed

- Removed unused cron params key-table registration from the legacy params keeper.
- Kept cron params owned by the cron keeper store, matching the modern SDK module pattern.
- Added `max_execution_gas` to bound schedule execution gas.
- Changed schedule tracking so `last_run_height` records attempts and `last_execute_height` only records fully successful atomic executions.
- Added queryable `last_execution_error`, including the failing contract and error.
- Added tests confirming failed execution does not advance `last_execute_height`.
- Recovered cron execution panics and out-of-gas errors so BeginBlock / EndBlock do not panic from scheduled contract execution.

## Report of required housekeeping

- [x] Github issue OR spec proposal link
  - Spec: [x/cron/spec/README.md](x/cron/spec/README.md)
- [x] Wrote tests
  - `go test ./x/cron/...`
  - `go test ./app -run 'TestCron'`
  - `go test ./...`
- [ ] Updated API documentation (client/lcd/swagger-ui/swagger.yaml)
- [ ] Added a relevant changelog entry: `clog add [section] [stanza] [message]`

----

## (FOR ADMIN) Before merging

- [ ] Added appropriate labels to PR
- [ ] Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)
- [x] Confirm added tests are consistent with the intended behavior of changes
- [x] Ensure all tests pass

[fragwuerdig]

Overall looks good to me and follows upstream SDK principles. See my comments for details. The bullets that might have the best impact on the could would be:

• make sure contract executions cannot run over a given gas limit
• make error logging for failed contract executions more transparent and queryable
• clarify the behavior of LastExecutedHeight

[StrathCole]

Can you explain what the actual benefit of this module would be as it could only be executed by governance?

[lbunproject]

Can you explain what the actual benefit of this module would be as it could only be executed by governance?

Sure thing:
The main benefit is not that governance executes the contract logic every time. Governance would only be used to approve adding a contract/message to the cron schedule. Once approved, the module can execute that scheduled message automatically at defined block intervals without relying on off-chain bots or centralized actors.

That could be useful for things like automated reward compounding, periodic liquidity management, TWAP/oracle updates, vesting or recurring payments, batch auctions/order matching, or other maintenance tasks that need reliable on-chain execution. So the value is decentralized, protocol-level automation while still keeping schedule creation gated by governance to prevent spam or abuse.

[StrathCole]

Can you explain what the actual benefit of this module would be as it could only be executed by governance?

Sure thing: The main benefit is not that governance executes the contract logic every time. Governance would only be used to approve adding a contract/message to the cron schedule. Once approved, the module can execute that scheduled message automatically at defined block intervals without relying on off-chain bots or centralized actors.

That could be useful for things like automated reward compounding, periodic liquidity management, TWAP/oracle updates, vesting or recurring payments, batch auctions/order matching, or other maintenance tasks that need reliable on-chain execution. So the value is decentralized, protocol-level automation while still keeping schedule creation gated by governance to prevent spam or abuse.

Tbh I don't think that it would be used on this chain. I would greatly prefer a solution like @fragwuerdig had drafted which would be a more generic scheduler that could also be used by non-governance as long as fee is paid for.

[lbunproject]

Tbh I don't think that it would be used on this chain. I would greatly prefer a solution like @fragwuerdig had drafted which would be a more generic scheduler that could also be used by non-governance as long as fee is paid for.

I don’t necessarily think a generic fee-based scheduler is automatically better. I think it solves a different problem.

I understand the recurring fee model is likely meant to prevent spam, but that is a hard balance to get right. Fees need to be high enough to discourage low-value scheduled tasks, but low enough that legitimate projects can actually afford to use it.

Projects would also still have to decide whether the scheduler adds enough value over simply submitting recurring transactions and paying normal gas fees. In some cases it may, but I don’t think it is automatically the better model.

The governance-gated approach is more conservative, but that is also the point. It is better suited for protocol-level projects and teams that want to automate recurring tasks important to their service. Governance decides what is worth scheduling, and then the module handles execution automatically at the configured interval.

Fees could still be part of the process if needed. For example, a fee could be paid up front before governance approves adding the task to the scheduler.

I also know of at least one project that already has ideas for how they could use something like this. I won’t mention what they are working on, but real use cases are out there.

[StrathCole]

Tbh I don't think that it would be used on this chain. I would greatly prefer a solution like @fragwuerdig had drafted which would be a more generic scheduler that could also be used by non-governance as long as fee is paid for.

I don’t necessarily think a generic fee-based scheduler is automatically better. I think it solves a different problem.

I understand the recurring fee model is likely meant to prevent spam, but that is a hard balance to get right. Fees need to be high enough to discourage low-value scheduled tasks, but low enough that legitimate projects can actually afford to use it.

Projects would also still have to decide whether the scheduler adds enough value over simply submitting recurring transactions and paying normal gas fees. In some cases it may, but I don’t think it is automatically the better model.

The governance-gated approach is more conservative, but that is also the point. It is better suited for protocol-level projects and teams that want to automate recurring tasks important to their service. Governance decides what is worth scheduling, and then the module handles execution automatically at the configured interval.

Fees could still be part of the process if needed. For example, a fee could be paid up front before governance approves adding the task to the scheduler.

I also know of at least one project that already has ideas for how they could use something like this. I won’t mention what they are working on, but real use cases are out there.

I think frags approach would cover the mentioned use case and many more.

A governance controlled scheduler would need any project to either fully renounce their contracts or the "chain" to trust that those contracts won't ever be altered to do something else than what was initially in there. Also who executes scheduled tasks should at least pay the gas required.