The design
pallet-energy-market (runtime index 103) lets a registered generator offer attested energy — a quantity, a period, a price — and a buyer take it, settling in DMS or DUSD. It consumes DeviceStatus from the registry (only registered, active devices may offer) and is meant to consume two more traits:
EnergyPriceOracle— a reference price to bound offers and detect manipulation.EnergyRewardDispatch— the hook that pays a generator or relay for energy or service delivered.
What () means
In the live runtime both traits are implemented by () — the unit type, a no-op provider. The call paths exist and compile; the oracle check returns nothing and the dispatch does nothing. The architecture document's dependency table lists this explicitly: runtime wiring uses () where the concrete provider is deferred; replace with the real Pallet<Runtime> once the bridging implementation is added.
This is the type system's version of wired, not exercised. A no-op trait is honest — it does not pretend to check — and it is a gap. The "wire it or retire it" rule of runtime 217 applies: either these traits get real providers (a price feed from pallet-oracle; dispatch through pallet-mesh-rewards) under an economic-class upgrade, or the market's dependent functions are removed until they do.
Where the data comes from
pallet-solar-generation, fed by OmilooS gateways reading inverters over Modbus. Its own corroboration trait (SolarDataOracle) is also (). So today the chain could hold an energy offer backed by a self-reported, uncorroborated reading — which is why no offer should be made with value until the traits are real, and why none has.
What a real market would need
- Oracle: an independent irradiance or grid-price source through
pallet-oracle(index 47). - Dispatch: payment on delivery, bridged to the rewards pallet.
- Corroboration of generation readings.
- Regulatory: energy trading is licensed in most jurisdictions; a pilot would be between consenting parties on a testnet, with test value.
- Devices: more than zero attested inverters on the public testnet.
Why publish a pallet with no-op traits
Because the alternative — describing the energy market as functional — is what the previous version of this page did for another network's energy figures. A no-op trait in a public dependency table tells a developer exactly what is missing. That is worth more than a percentage.
Based on ARCHITECTURE.md (cross-pallet dependency map), PALLET_REFERENCE.md and the runtime 217 rule.