[meta] scheduler design draft1

[extraymond]

Info

description:
Laguna chain are destined to have the ability to allow contract utilize runtime scheduler for their app usage, at start we will try passive mode which restrict usage to prevent catastrophe events occurring, it will get lifted during later refinement. This will be the first meta on scheduler design

The design should consider having three of the components:

• call-type definition
• utilized operations
• cleanup procedure and exit strategy

required features:

• having a on-chain scheduler(upstream or fork) in the runtime
• having a callable extension for contract to register actions directly in contract
• predefined types of calls that are accepted inside the scheduler
• manage allowed list of accounts and address allowed to apply for using scheduler
• economic measure for application, define locked funds and application fee needed
• define event and modes during a recurring scheduling, on-start/on-progress/on-finished/on-failure
• define global exit strategy if recurring call success or failed
• define manual implementation from the contract writer to supplement when one of the event described above happened
• consider create special carrier for monetary actions, e.g, future fund sending will be controlled by on-chain pocket before being actioned

One of the example can happen is that if future calls are not actionable, what should happen?
Restrict concurrency bugs by allowing writer to either:

• froze action on failure
• power through with sane default

target use case: having a contract to utilized the scheduler to dispatch farming rewards automatically

[extraymond]

on hold before plan with parachain integration are finalized