Economics

BNW uses one transparent numeric convention without defining one global currency: 1 service credit is always 1,000,000 integer microcredits. Every priced offer also names a BNW principal as its credit issuer. Amounts from different issuers therefore look the same, but are not silently treated as interchangeable.

This preserves simple user-facing values while avoiding a false global balance. Signed receipts alone cannot prevent a requester from spending the same balance with disconnected providers during a network partition. BNW will support multiple explicit settlement methods rather than embedding a mandatory blockchain, clearing service, or network currency.

Offer terms v1

bnw.offer-terms/1 is strict JSON stored as an immutable blob and referenced by CapabilityOffer.metadata. It contains:

• the credit issuer;
• a minimum and hard maximum charge per invocation, in microcredits;
• sorted metering rates such as request, input-token, output-token, or gpu-millisecond;
• accepted settlement methods; and
• optional current slot and queue estimates.

The offer’s signature binds the metadata CID, so changing price or availability requires a new short-lived offer. Load and price remain provider claims. Requesters apply local policy and may ignore them.

receipt-only means the parties can later produce signed usage evidence, but it does not prove that funds were reserved. issuer-reservation-v1 names the planned Milestone 10 reservation protocol; publishing support for that method does not yet implement settlement.

witnessed-utxo-v1 names the resilient non-transferable resource-credit direction. It requires an immutable bnw.credit-policy/1 CID in settlement_policy.

Create and inspect terms:

bnw capability offer-terms create inference-terms.json \
  --credit-issuer <ISSUER_BNW_ID> \
  --minimum-charge-micros 50000 \
  --maximum-charge-micros 5000000 \
  --rate input-token=2 \
  --rate output-token=5 \
  --settlement receipt-only \
  --available-slots 2 \
  --queue-millis 250

bnw capability offer-terms validate inference-terms.json
bnw capability offer-terms inspect <TERMS_ID>

Attach the printed terms CID to a normal provider offer:

bnw capability offer <CAPABILITY_ID> \
  --endpoint bnw.peer=<PEER_ID> \
  --expires-at <UNIX_TIMESTAMP> \
  --metadata <TERMS_ID>

Rates are microcredits per one named unit. The maximum is an offer-level ceiling, not the final charge. A future provider quote will bind an exact input and may commit to a lower ceiling.

Witness policy and partitions

A live DHT peer list is not a consensus committee. Different partitions can see different peers, and an unconstrained “keep adding witnesses until any threshold signs” scheme can create two disjoint quorums for conflicting spends.

bnw.credit-policy/1 therefore defines one immutable issuer epoch with:

• an exact sorted witness committee;
• an explicit threshold that must exceed two thirds of the committee;
• an optional machine-safe failure-domain label for selection and audits; and
• a previous-policy CID for every epoch after zero.

Create a bootstrap policy. This four-member example requires three signatures:

bnw economy policy create credit-policy.json \
  --issuer <ISSUER_BNW_ID> \
  --epoch 0 \
  --threshold 3 \
  --witness <WITNESS_1>=residential-us \
  --witness <WITNESS_2>=cloud-eu \
  --witness <WITNESS_3>=university-us \
  --witness <WITNESS_4>=enterprise-ap

Attach the resulting policy to witnessed offer terms:

bnw capability offer-terms create inference-terms.json \
  --credit-issuer <ISSUER_BNW_ID> \
  --minimum-charge-micros 50000 \
  --maximum-charge-micros 5000000 \
  --rate input-token=2 \
  --rate output-token=5 \
  --settlement witnessed-utxo-v1 \
  --settlement-policy <CREDIT_POLICY_ID>

Derive the contact order for an economic transaction:

bnw economy policy witnesses <CREDIT_POLICY_ID> <TRANSACTION_ID> \
  --requester <REQUESTER_BNW_ID> \
  --provider <PROVIDER_BNW_ID>

The transaction, policy, and participant IDs determine a stable pseudo-random contact order. Requester and provider are excluded. Contact attempts may progress through that order, but the committee and threshold never change inside the epoch. If too few eligible witnesses are available, status is unavailable-pending-only; it must not be projected as settled or mutate the spendable UTXO set.

Failure-domain labels help avoid correlated outages but are claims until independently attested. Witnesses will validate only the economic envelope—signatures, policy, inputs, output amounts, receipt hashes, sequence/expiry, and prior spentness—not private prompts or model outputs.

The current protocol accepts reservation attestations under an explicitly referenced policy, but it does not yet implement policy activation or rotation certificates. A future epoch transition must itself be authorized by the prior policy rather than allowing an issuer to replace the committee unilaterally.

Local resolution

Portable-agent dependencies can be resolved from the local verified store:

bnw agent resolve <AGENT_CAPABILITY_ID>

bnw agent resolve <AGENT_CAPABILITY_ID> \
  --credit-issuer <ISSUER_BNW_ID> \
  --max-per-invocation-micros 5000000

Resolution validates the agent profile, every exact dependency manifest and descriptor, and active canonical provider offers. Zero-slot offers are excluded. When an issuer is specified, eligible offers are ordered by their maximum charge and then by offer CID. Without an issuer, prices from different issuers are not compared; typed transparent terms are preferred and the offer CID provides the deterministic tie-break.

Resolution is local and snapshot-dependent. It is not global consensus, a reservation, permission to invoke, or permission to spend. Missing public descriptors can be fetched with bnw catalog inspect <CAPABILITY_ID> or by following and synchronizing the referenced capability.

Quotes and spend authorization

Milestone 10 begins with two participant-scoped signed objects. Neither changes a balance:

• CapabilityQuote is signed by the provider after it receives an invocation. It binds that exact invocation to the offer terms, issuer, minimum, maximum, and expiry.
• CapabilitySpendAuthorization is signed by the requester. It binds the invocation and quote to the maximum amount the requester consents to pay.

The provider creates a quote while the invocation is still pending:

bnw economy quote <INVOCATION_ID>

# Optionally commit below the offer-level ceiling:
bnw economy quote <INVOCATION_ID> \
  --maximum-charge-micros 3000000

After synchronization, the requester inspects the quote and authorizes it:

bnw economy status <INVOCATION_ID>

bnw economy authorize <INVOCATION_ID> <QUOTE_ID>

# Optionally authorize less than the quoted ceiling, but not below its minimum:
bnw economy authorize <INVOCATION_ID> <QUOTE_ID> \
  --maximum-charge-micros 2500000

Both commands print funds-reserved: no. A separate witnessed reservation is required before funds are locked. Provider execution is not yet automatically gated on that reservation.

Issuance, UTXOs, and witnessed reservations

The credit issuer can create an auditable bootstrap output for a requester:

bnw economy issue <REQUESTER_BNW_ID> 10000000 \
  --policy <CREDIT_POLICY_ID>

This prints an outpoint such as <ISSUANCE_ID>:0. Issuance is the only operation in this slice that creates value. An ordinary reservation must conserve value within one issuer and one owner; it cannot transfer credits directly to an arbitrary peer.

After the requester has a valid spend authorization, it proposes a reservation using one or more unspent outputs:

bnw economy reserve <INVOCATION_ID> <AUTHORIZATION_ID> \
  --input <ISSUANCE_ID>:0

The proposal locks exactly the authorization ceiling and creates only requester change. The change is output zero of the proposal, printed as <PROPOSAL_ID>:0, but is not spendable until the proposal has a witness quorum.

Each eligible committee member synchronizes the proposal and runs:

bnw economy attest <PROPOSAL_ID>

An honest witness approves at most one proposal for a given input. If it has already approved an overlapping proposal—or observes an already reserved conflicting proposal—the command records reject-conflict instead. Inspect quorum state with:

bnw economy reservation <PROPOSAL_ID>
bnw economy status <INVOCATION_ID>
bnw economy wallet --issuer <ISSUER_BNW_ID>

The projection is pending below threshold, reserved at threshold, and expired-unreserved when an under-quorum proposal expires. An observed pair of conflicting quorums is reported as catastrophic-conflict; BNW does not hide the safety failure by choosing one based on arrival order or content ID.

Credit policies and offer terms are immutable blobs rather than signed network objects. The requester assembling a reservation must have them locally. The proposal then carries a bounded proof bundle containing the signed invocation, offer, quote, authorization, terms, and policy, so a witness can validate the complete economic chain without subscribing to unrelated participant history. The bundle contains an input content ID but no inference prompt or result body. Signed issuance, proposal, and attestations replicate through the issuer, requester, provider, and fixed witness inbox scopes.

Witnessed settlement

A reserved amount is closed by exactly one witnessed CreditSettlement, which splits it into a provider payment (output 0) and a requester refund (output 1). The two always add up to the reserved amount, so settlement moves value only between the invocation’s two parties and never creates any.

Once it has signed the invocation’s result, the provider settles:

bnw economy settle <INVOCATION_ID>                       # charge the quote's minimum
bnw economy settle <INVOCATION_ID> --meter request=1     # charge metered usage at the offer's rates
bnw economy settle <INVOCATION_ID> --charge-micros 450000

The settlement carries the provider’s signed CapabilityResult and its metered usage, so witnesses can check the charge without seeing the private output. They verify the following:

• the reservation reached its quorum;
• the split conserves the reserved amount;
• a Completed result is charged at least the quote’s minimum;
• when metering is given, the charge is no more than the metered cost at the offer’s signed rates (or the minimum, if that is higher);
• a Failed or Rejected result is charged nothing.

A provider that never settles cannot hold the requester’s credit forever. One day after the invocation expires (CREDIT_RELEASE_GRACE_SECS), the requester may sign a release, which is a settlement that refunds everything:

bnw economy release <INVOCATION_ID>

Committee members attest settlements exactly as they attest reservations:

bnw economy attest-settlement <SETTLEMENT_ID>
bnw economy settlement <SETTLEMENT_ID>

An honest witness approves at most one settlement per reservation. A later provider settlement, or a release racing a late settlement, gets reject-conflict from every witness that already approved another one, and from everyone once another settlement has reached quorum. Quorum intersection therefore leaves one settlement per reservation. As with reservations, an observed pair of settled quorums is reported as catastrophic-conflict, and neither settlement’s outputs resolve.

Settled outputs are ordinary issuer-scoped UTXOs. bnw economy wallet lists the provider’s payment and the requester’s refund as spendable, and they can fund later reservations. A settled reservation no longer counts toward reserved-micros.

Still planned:

• optional witness compensation;
• opt-in execution gating on reservations;
• epoch rotation certificates;
• agent budgets.

Agent balances and budgets remain runtime state associated with principals and delegations. They do not belong in immutable portable-agent manifests.