Value follows valid work.
Begin with the contract
An owner declares a useful task and its boundary. A caller requests work within that boundary. The parties can evaluate the returned fields and accompanying record against an agreed policy.
This creates a basis for organizing fees around valid work. Rejected requests and nonconforming outputs do not enter the corresponding successful work settlement flow.
Keep roles distinct
Broker matches and minimizes a request. Guardian checks the boundary and output. Vault processes the task in its controlled environment. These are responsibilities in a protocol, rather than financial tiers or staking categories.
The callable product is the capability. Its usefulness can flow to another task while the source remains with its owner.
What this deployment does
The compiler preserves a settlement condition in the Manifest. The workbench runs deterministic public examples and generates integrity records. The owner workspace registers reviewed capability declarations through a server verified session.
None of these operations transfers money. This site does not implement payment collection, token settlement, payouts, yields, buybacks, burns or dividends. A successful local Capsule is not a payment receipt.
Configuration is not activation
A token address, registry service and settlement program are different configuration boundaries. Entering a contract address cannot activate an entire protocol or authorize transfers.
An actual settlement integration would need an agreed fee model, payment authorization, acceptance rules, durable accounting and dispute behavior. Its success state must come from the implemented service rather than a browser timer.
Count what is known
The site can report the number of built-in policies, actual local runs and records returned by the registry. Those values should not be promoted into network adoption, revenue or private task success rates.
An economic mechanism is more useful when its acceptance conditions and actual implementation are easy to inspect.