DamageBDD FAQ: Capabilities, Evidence and Payments

An evidence-native platform for building, operating, verifying and exchanging software and digital services. Its core product executes behaviour scenarios and produces inspectable results. The platform map covers ECAI knowledge retrieval, erm local operations, Nostr signing and retention, Blossom files and payment-related integrations.

Choose one evaluation with an agreed outcome. A known API failure and its fix are a useful first demonstration. The manual explains account/API access; the module reference describes available steps. Plain-language scenarios still need supported step implementations and suitable fixtures. Self-hosting also needs the configured dependencies.

It records that the selected assertions passed for that execution, target and input. It does not establish all possible behaviour, permanent availability, regulatory compliance or the absence of vulnerabilities. Re-run relevant checks when the software, data or environment changes.

The documented workflows associate feature/report identities with execution and accounting records. Report content, IPFS availability and a confirmed chain transaction are separate things. Check the actual publication and confirmation path for your deployment. A hash makes changes detectable against a trusted reference; it does not make false input true or keep a file online.

Independent execution and agreement between nodes are part of the project vision. Do not infer a verified network-wide consensus service, adversarial reward system or automatic settlement from a single-node execution report. The capability matrix separates component implementation from the evidence for complete workflows.

Indexing, retrieval with source references, private-corpus access controls, typed relation processing and interfaces for LLM-assisted answers and repair review. Repeatable identities are useful for provenance. They do not make an answer true, recover text by reversing a hash, or eliminate model errors. See the ECAI overview.

DAMAGE is an Aeternity AEX9-style utility token used for execution-credit accounting and verification spend. It is not described here as governance-only. The token model records 8 decimals and the 42,000,000 DAMAGE supply policy, with 80% founder/custody and 20% public/market allocation. The described contract permits owner minting and holder burns; the policy is not an immutable contract-level supply cap or a live circulating-supply audit.

The documented spend path transfers an amount to the node/operator and records feature/report references. Burning and swap marking are separate contract operations. Running a test must not be advertised as a deflationary burn without evidence that the deployed path performs that operation.

A top-up pays an invoice and credits DAMAGE after the configured listener processes settlement. Contractor compensation is a separately agreed BTC or Lightning payment. Swap/hold-invoice jobs and remote wallet interfaces have their own permissions and state transitions. See payment flows. A paid invoice is not a passing test; a passing test is not a payment receipt.

No general escrow, automatic payout, redemption, buyback, price stability or return guarantee follows from the documented components. A specific service must state its terms, control of funds, confirmation rules and failure handling. The contractor guide describes maintainer review and payment for agreed work.

Use the deployment's quote or dry-run estimate and invoice. Cost depends on the installed step implementation, repeated work and concurrency. The pricing guide separates execution units from token purchase rates. Older fixed sats prices and conflicting module tariffs are not current quotes. Paying for execution does not buy a passing result.

That depends on the workflow. Hosted account documentation describes a custodial Aeternity wallet; an external wallet can remain user-controlled. nsecbunker separates client permissions from the operator-managed signing key. Neither a Lightning payment nor a remote signer makes every layer self-custodial. Confirm the active custody arrangement before using it.

The public service terms restrict submissions to test data. Private retrieval capabilities need a controlled deployment, appropriate permissions and data terms. Check which records may reach which model and how access is revoked; encryption alone does not establish those boundaries.

Read the capability matrix and each linked reference. The nsecbunker suite has a dated, release-specific live report. Many other pages record source review, a pilot or a proposed evaluation. A newer publication date does not renew an older test result.

Start with the dashboard or API, self-hosting, or a scoped evaluation. For contribution work, follow the contractor process. The whitepaper explains the architecture and the vision its longer-term goals.