Project Configuration
Every project begins with a configuration file — ludopoly.config.yaml — that captures the settings governing how the production pipeline processes your requests. This file can be created manually, generated interactively through the CLI's init command, or produced by the specification dialogue during natural language interaction.
The configuration file serves as the single source of truth for your project's pipeline behaviour. It determines which chains to target, which platforms to generate SDK bindings for, which security audit depth to apply, and how the cost guardian should manage your budget. When a generation request does not specify a parameter, the pipeline falls back to the value in this file. When the file does not specify a parameter, the platform applies a sensible default.
Chain Configuration
The chains field accepts any combination of the platform's supported networks. Each chain entry can be a simple name (using the platform's defaults for that network) or a detailed object specifying custom RPC endpoints, gas price limits, and finality thresholds. The platform maintains a registry of over two hundred supported chains, and the knowledge engine keeps gas cost models current for each one.
When no chain is specified, the pipeline defaults to Ethereum mainnet — the most conservative choice in terms of gas pricing and security assumptions.
Security Depth
The audit_depth parameter controls the thoroughness of the security agent's review. Three levels are available: basic performs pattern-based vulnerability scanning, standard adds coverage analysis and known-exploit matching, and comprehensive includes formal verification and adversarial fuzzing. The appropriate level depends on the contract's risk profile — a free-to-play game item system tolerates a lighter audit than a DeFi vault managing significant capital.
Formal verification can be enabled independently of the audit depth. Setting formal_verification: true adds mathematical invariant checking regardless of which audit level is active.
The Cost Guardian
Every request to the production pipeline consumes compute resources — model inference, compilation, and optimisation. The cost guardian enforces a per-request budget ceiling, preventing accidental overruns caused by complex specifications that trigger multiple self-correction cycles. The max_per_request field sets this ceiling. If a pipeline run approaches the limit, the guardian pauses execution and notifies the developer before proceeding.
The cost guardian also operates at the tier level for teams on subscription plans. Monthly quotas, overage pricing, and model-specific cost weights are all managed transparently. The platform's pricing section provides complete details on tier allocations and cost structures.