ERC-8454: AIFi Unit Framework

Abstract

This ERC defines the AIFi Unit Framework (AUF): a registry and descriptor model through which any economic object in an AI-driven economy can be named, bounded, described, observed, classified and valued as one whole.

In this document, AIFi refers generically to the production, exchange and financial activity that forms around AI systems: agents, executable skills, tasks, services, models, compute, data and the capital positions that connect them. The term does not refer to any particular project, issuer or brand.

An AIFi Unit (a Unit) is an economic object with an explicit boundary: a versioned Unit Definition that lists its elements, the typed relations and the rights and obligations under which those elements are included, its economic interfaces (ports), and its authorities. A Unit can be a single element (a running agent, a static skill package, a task with escrowed funds, a model license, a compute quota, a data access right, a financial position) or a composition of such elements and of other Units, including compositions in which new elements emerge.

On top of Unit Definitions, the framework fixes a single assertion envelope with three normative content kinds: characterizations (stackable economic roles such as source, sink, conductor, damping, container, pledge, valve and control, together with behavior attributes, behavior models, structure profiles and knowledge states), observations (per-asset stocks and port transfers over a window, with coverage and reconciliation rules) and valuation receipts (the result that an identified method produces for an identified interest, perspective, snapshot and assessment boundary, in a declared denomination and result kind).

Methods, profiles and extension vocabularies are content-addressed descriptors. The framework standardizes what is being defined, observed, classified and valued, and how such statements are referenced, versioned, superseded and revoked. It leaves the valuation functions themselves, the behavior models and the credit models open, so that evaluators can plug in any method while every reader still understands what a given number refers to.

Motivation

Agents, skills, tasks, models and capital are increasingly issued, traded and composed on chain. Several proposals already describe individual kinds of these objects, their discovery and their collective decisions. What is missing is the layer underneath all of them: a shared answer to the question "what is being treated as one economic whole here, what does it do economically, and what does this value figure mean?"

Without such a layer, three failures recur:

1. Two parties refer to "the same" agent business but include different resources, licenses and obligations in it. A valuation of one cannot be compared with a valuation of the other.
2. A unit is given a single permanent label ("a staking pool", "a task") although its parts play different economic roles under different conditions, which hides the costs, locks and controls that matter for analysis.
3. Two evaluators publish 100 and 200 for the same object, and nobody can tell whether those are net equity, a daily yield, a probability of completion or a credit grade, in which currency, as of when, and for whose interest.

This ERC fixes a common language for exactly these three points: boundary, economic characterization and valuation statement. It does so with a small on-chain kernel (two registries) and content-addressed off-chain documents, so that independent implementations, indexers, marketplaces, credit systems and collective decision processes can interoperate on economic units of any composition, including purpose-bound agent swarms, one-person companies run by agents, and portfolios of task claims.

The framework is informed by the circuit view of token economics, in which cash plays the role of charge, cash flow the role of current and value difference the role of potential, and in which sources, storage, friction, locking and conduction compose into larger "financial chips". That view is carried here as an optional analysis profile with explicitly stated premises, not as a law that every Unit must satisfy. The normative core is independent of it.

Specification

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals, as shown here.

1. Terminology

• Unit: an economic object with an explicit boundary, treated as one whole for description, observation, characterization and valuation. A Unit is identified by a registry and an unsigned integer unitId.
• Unit Definition: a versioned document that fixes the boundary of a Unit: its elements, relations, ports, authorities and validity. Each version is committed on chain by its boundaryHash.
• Element: a constituent referenced by a Unit Definition, identified by a kind and a reference string.
• Relation: a typed edge between the Unit and an element, or between two elements, carrying the economic terms (scope, term, quantity, share, exclusivity, obligations, basis) under which the element is included.
• Port: an economic interface of the Unit through which funds, resources, deliverables, rights, commitments or control signals enter or leave.
• Definition Controller: the account entitled to publish new versions of a Unit Definition and to transfer or renounce that entitlement.
• Acknowledgment: a typed on-chain statement by an account about an element of a specific Unit version (participation, resource use, fund operation or endorsement of the description).
• Assertion: a statement about a specific Unit version made under the assertion envelope of this ERC. Assertion kinds are characterization, observation, valuation and extension.
• Controller Assertion: an assertion whose asserter was the Definition Controller of the subject Unit when the assertion was recorded. Every other assertion is a Third-Party Assertion.
• Role: a stackable economic function attributed to a Unit, a port or an element under stated conditions (source, sink, conductor, damping, container, pledge, valve, control).
• Observation: a measurement record of stocks, transfers and non-cash state changes of a Unit over a window, with provenance and coverage.
• Method: a content-addressed descriptor of a valuation or analysis procedure, including its input and output schemas, algorithm reference, assumptions and composability declaration.
• Interest: the economic claim or perspective that a valuation refers to (for example the whole business, the net equity, a revenue right, a usage right, a fulfillment claim or an obligation).
• Valuation Receipt: an assertion of kind valuation whose content records the subject, assessment boundary, interest, snapshot, method, inputs and result.
• Profile: a named set of requirements identified by a profile identifier, used for roles, structures, applications, behavior models and methods. Profiles defined by this ERC use the auf: namespace. Extension profiles use the x: namespace.
• Resolver: software that reads registries and descriptors and reconstructs Units, their containment trees, acknowledgments and assertions.

2. Conformance

A conforming deployment consists of one Unit Registry (Section 4) and one Assertion Registry (Section 11) that references it. Both registries MUST implement ERC-165 and MUST report the interface identifiers of Section 15.

A conforming Unit Definition, characterization, observation, method descriptor or valuation receipt is a JSON document that satisfies the corresponding data model of Sections 3 and 7 to 10 and whose canonical hash (Section 3.2) equals the hash recorded on chain.

A conforming resolver MUST implement the rules marked for resolvers in Sections 3.6, 5.3, 6.4, 8.3, 10.6 and 13.

Implementations MAY support only a subset of profiles. A consumer that encounters an extension it does not support, and that the document marks as required, MUST report the document as unsupported and MUST NOT silently continue as if the extension were absent (Section 13.3).

3. Unit Definition

3.1 Document

A Unit Definition is a JSON object with the following members. Members marked (R) are REQUIRED.

3.2 Canonicalization and boundary hash

The boundaryHash of a Unit Definition is the Keccak-256 digest of the UTF-8 encoding of the document after canonicalization with the JSON Canonicalization Scheme (RFC 8785).

The same rule applies to every other document of this ERC: characterization content, observation content, method descriptors, profile descriptors and valuation receipt content. The digest of a method descriptor is its methodId; the digest of a profile descriptor is the content hash recorded for that profile.

Numbers that carry economic quantities (amounts, shares, rates, prices) MUST be encoded as decimal strings, not as JSON numbers, so that canonicalization never alters their representation.

3.3 Elements

An element object has the members kind (R), ref (R), label, controller, expectedAcks, evidence and extensions.

kind is one of the following values, or an extension kind of the form x:<namespace>:<name>:

ref is a string that identifies the element unambiguously. Implementations SHOULD use, in this order of preference: a chain-agnostic asset identifier (CAIP-19 form) for tokens and token-bound objects; a chain-agnostic account identifier (CAIP-10 form) for accounts and contracts; a Unit reference for unit elements; a DID, URN or URI for off-chain objects. A Unit reference has the form

auf:eip155:<chainId>:<registry address, lowercase hex>:<unitId>@<version>

The elementId of an element is

elementId = keccak256( UTF-8(kind) || 0x3A || UTF-8(ref) )

where 0x3A is the ASCII colon. Two elements of one definition MUST NOT share an elementId.

Including an element in a Unit Definition is a statement by the Definition Controller. It does not by itself transfer, grant or prove any right over that element. The relation under which the element is included (Section 3.4) states what is claimed, and acknowledgments (Section 5) and evidence state what is confirmed.

3.4 Relations

A relation object has the members type (R), from (R), to (R), scope, validFrom, validUntil, quantity, share, exclusive, obligations, counterparty, basis and extensions.

from and to are either the string "unit" or the elementId of an element of the same definition, written as a 0x-prefixed lowercase hex string.

type is one of the following values, or an extension type of the form x:<namespace>:<name>. Meanings are stated from the from party towards the to party; when from is "unit" the relation is the Unit's own.

quantity is an object { "amount": <decimal string>, "unit": <string> }. share is a decimal string or a rational string of the form "1/3" in the closed interval from 0 to 1. exclusive is a boolean. obligations is a string. counterparty is a CAIP-10 account, a DID or a URI. basis is an array of evidence references (URIs or 0x hashes).

Structural relations (contains) MUST form a directed acyclic graph across Units (Section 3.6). Entitlement, obligation, dependency and interaction relations MAY form cycles. Cross-holdings between Units MUST be expressed as entitlement relations, not as mutual containment.

3.5 Ports

A port object has the members id (R), direction (R), class (R), template, asset, account, conditions, stateEffects and extensions.

direction is in, out or inout. class is one of funds, resource, deliverable, right, commitment or control. template is an OPTIONAL profile identifier naming a port template; this ERC defines auf:port:funds-in@1, auf:port:funds-out@1, auf:port:service-out@1, auf:port:deliverable-in@1, auf:port:deliverable-out@1, auf:port:commitment-in@1 and auf:port:control-in@1. asset is a CAIP-19 identifier for funds ports. account is a CAIP-10 settlement account. conditions states when the port is active. stateEffects states which internal state the port changes.

Ports describe interfaces, not counterparties. A Unit facing many changing counterparties SHOULD declare a bounded set of port templates rather than a port per counterparty.

A transfer that crosses a port of the Unit is an external transfer. A transfer between two elements of the same Unit that crosses no port is an internal transfer. Observations and valuations MUST keep the two apart (Sections 8 and 10).

3.6 Versions, containment and freezing

Every Unit has a strictly increasing version number starting at 1. Each version commits exactly one boundaryHash and one descriptorURI that resolves to the Unit Definition.

A contains relation MUST reference a unit element whose reference pins a specific version of an existing Unit. When a version is published, the registry MUST record its contained Unit versions and MUST verify that each of them already exists in the same registry and does not belong to the Unit being published. Because a version can only contain versions that already exist, containment is acyclic by construction. Containment of Units kept in other registries MUST be expressed with depends-on or an entitlement relation, and resolvers MUST treat it as unverified containment.

Resolvers MUST expand containment by the pinned versions, never by the latest version of a contained Unit. Resolvers MUST declare the maximum depth and size they support and MUST report a tree that exceeds those limits as partially resolved.

A Unit whose Definition Controller is the zero address is frozen: no further versions can be published. A Unit MAY be registered frozen.

3.7 Authorities

The authorities object has the members definitionController (R, a CAIP-10 account or the string "none" for a frozen definition), representatives (array of accounts entitled to act on behalf of the Unit in the stated scope), beneficiaries (array of accounts or elements that receive revenue or bear costs), settlementAccounts (array of CAIP-10 accounts) and notes.

Representatives, beneficiaries and settlement accounts are declarations that point to where authority is actually held (a token contract, a swarm account, a multisig, an escrow). They are not granted by this ERC.

Controlling a Unit Definition does not grant disposal rights over the elements, representation rights for the Unit, or any right to its cash flows. Registries, resolvers and consumers MUST NOT infer such rights from the controller role.

4. Unit Registry interface

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

/// @notice Reference to a specific version of a Unit kept in the same registry.
struct UnitRef {
    uint256 unitId;
    uint32 version;
}

/// @notice Acknowledgment kinds. Values above 4 are reserved for extensions.
enum AckKind {
    None,                   // 0, invalid
    Participation,          // 1 the acknowledging account takes part in the Unit
    ResourceUse,            // 2 the acknowledging account authorizes the stated use of the element
    FundOperation,          // 3 the acknowledging account authorizes the stated fund operation
    DescriptionEndorsement  // 4 the acknowledging account endorses the description of the element
}

interface IAUFUnitRegistry /* is IERC165 */ {
    event UnitRegistered(uint256 indexed unitId, address indexed controller, bytes32 boundaryHash, string descriptorURI);
    event VersionPublished(uint256 indexed unitId, uint32 indexed version, bytes32 boundaryHash, string descriptorURI, uint256 containsCount);
    event ControllerChanged(uint256 indexed unitId, address indexed previousController, address indexed newController);
    event Acknowledged(uint256 indexed unitId, uint32 indexed version, bytes32 indexed elementId, AckKind kind, address account);
    event AcknowledgmentWithdrawn(uint256 indexed unitId, uint32 indexed version, bytes32 indexed elementId, AckKind kind, address account);

    /// @notice Registers a Unit and publishes version 1.
    /// @param controller Definition Controller; address(0) registers a frozen Unit.
    /// @param boundaryHash Canonical hash of the Unit Definition (Section 3.2).
    /// @param descriptorURI Location of the Unit Definition.
    /// @param contains Unit versions referenced by `contains` relations of the definition.
    function registerUnit(address controller, bytes32 boundaryHash, string calldata descriptorURI, UnitRef[] calldata contains)
        external returns (uint256 unitId);

    /// @notice Publishes a new version. Only the Definition Controller. Reverts for frozen Units.
    function publishVersion(uint256 unitId, bytes32 boundaryHash, string calldata descriptorURI, UnitRef[] calldata contains)
        external returns (uint32 version);

    /// @notice Transfers or renounces definition control. address(0) freezes the Unit permanently.
    function setController(uint256 unitId, address newController) external;

    /// @notice Records an acknowledgment by msg.sender for an element of a Unit version.
    function acknowledge(uint256 unitId, uint32 version, bytes32 elementId, AckKind kind) external;

    /// @notice Withdraws an acknowledgment previously recorded by msg.sender.
    function withdrawAcknowledgment(uint256 unitId, uint32 version, bytes32 elementId, AckKind kind) external;

    function unitCount() external view returns (uint256);
    function controllerOf(uint256 unitId) external view returns (address);
    function isFrozen(uint256 unitId) external view returns (bool);
    function latestVersion(uint256 unitId) external view returns (uint32);
    function versionOf(uint256 unitId, uint32 version)
        external view returns (bytes32 boundaryHash, string memory descriptorURI, uint64 publishedAt, uint256 containsCount);
    function containedAt(uint256 unitId, uint32 version, uint256 index) external view returns (UnitRef memory);
    function acknowledgedAt(uint256 unitId, uint32 version, bytes32 elementId, AckKind kind, address account)
        external view returns (uint64);
}

Registry rules:

1. unitId values MUST be assigned sequentially starting at 1 and MUST never be reused.
2. registerUnit and publishVersion MUST revert when boundaryHash is zero, when any entry of contains references a non-existent Unit or version, or when any entry references the Unit being published.
3. publishVersion and setController MUST revert unless msg.sender is the current Definition Controller. Both MUST revert for frozen Units.
4. Versions are immutable once published. A correction is a new version.
5. acknowledge MUST record block.timestamp for the tuple (unitId, version, elementId, kind, msg.sender) and MUST revert when the version does not exist or kind is None. withdrawAcknowledgment MUST reset the record to zero and MUST revert when no record exists.

The registry does not validate that elementId belongs to the definition, that the acknowledging account controls the element, or that the definition at descriptorURI hashes to boundaryHash. Resolvers perform these checks (Sections 3.2 and 5.3).

5. Acknowledgments

5.1 Meaning

An acknowledgment is a statement by its account about one element of one Unit version. Its meaning is fixed by its kind and nothing else:

• Participation: the account states that it takes part in the Unit in the role described for the element.
• ResourceUse: the account authorizes the use of the element under the terms of the relation that includes it.
• FundOperation: the account authorizes the fund operation described for the element (for example a funds port settling to an account the acknowledging party controls).
• DescriptionEndorsement: the account states that the description of the element is accurate.

Kinds MUST NOT be collapsed into a single boolean by resolvers or consumers.

5.2 When acknowledgments are expected

A Unit Definition MAY state, per element, which acknowledgment kinds it expects (expectedAcks, an array of the kind names participation, resource-use, fund-operation and description-endorsement). Elements included with depends-on are external dependencies and MUST NOT be required to acknowledge anything; an analyst MUST be able to define a Unit over objects whose controllers never sign.

5.3 Resolver rules

A resolver MUST report, per element, which expected acknowledgments are present, by which accounts, and whether the acknowledging account is a plausible controller of the element. For token-bound elements the plausible controller is the current token owner or an account it has approved; for account elements it is the account itself; for other elements the resolver MUST state that controllership was not verified. An element with missing expected acknowledgments is claimed, not confirmed.

6. Assertions

6.1 Envelope

Every statement about a Unit version other than the definition itself is recorded as an assertion with the following on-chain envelope:

The content document is a JSON object with at least the members auf ("1.0"), kind (the kind name), subject (unitId, version, boundaryHash and the Unit Registry address in CAIP-10 form) and the kind-specific members of Sections 7, 8 and 10. Its canonical hash MUST equal contentHash.

6.2 Controller and third-party assertions

A Controller Assertion is a self-declaration. A Third-Party Assertion is an external evaluation. Both use the same envelope and the same content models; they differ in meaning, not in format. A signature or transaction proves origin and commitment. It does not prove that the conclusion is correct, that costs are complete or that rights are valid. Consumers choose which asserters they trust for which kinds.

6.3 Profiles and identifiers

A profile identifier is a string of the form <namespace>:<class>:<name>@<major>. This ERC reserves the namespace auf. Extension profiles use x:<owner>:<class>:<name>@<major> where <owner> is a domain name or a CAIP-10 account controlled by the publisher. profileId = keccak256(UTF-8(identifier)).

Profiles defined by this ERC:

The profileId of a characterization assertion MUST be the identifier of the characterization content model it follows. The profileId of an observation assertion MUST be the identifier of the observation content model. The profileId of a valuation assertion MUST be the methodId of the method used. The profileId of an extension assertion is the extension profile.

6.4 Validity, revocation and supersession

An assertion is current when its status is active and the current time lies within its validity window. An asserter MAY revoke its own assertion at any time; revocation is final. An asserter MAY record a new assertion that supersedes an earlier active assertion of its own with the same kind about the same Unit; the earlier assertion then has status superseded and MUST keep resolving to its original content.

Resolvers MUST return expired, revoked and superseded assertions on request, marked as such, and MUST NOT present them as current. A valuation receipt recorded for one version of a Unit is not a valuation of any other version (Section 10.4).

7. Characterization

A characterization content document follows auf:characterization:v1@1 and has the members roles, attributes, models, structure, applications, knowledge, evidence and extensions. All members are OPTIONAL, but a document with no roles, no structure and no knowledge member is not useful and SHOULD NOT be recorded.

7.1 Roles

A role statement has the form: a part of the Unit, under a state and conditions, performs an economic function. It is an object with the members role (R), scope (R), mechanism, state, conditions, window and evidence.

scope is { "type": "unit" }, { "type": "port", "id": <portId> } or { "type": "element", "id": <elementId> }.

Roles are stackable. One Unit, port or element MAY carry several roles at once, and the roles of a Unit are not required to sum to anything. A role is a function in a relation, not a permanent label of the object.

A source statement SHOULD name its mechanism so that production, external injection, financing, borrowing and issuance are not accumulated as one kind of value creation. A sink statement SHOULD say what is absorbed and whether an output of another form is produced in return. A damping statement SHOULD say where the cost or loss arises. A pledge statement SHOULD state the locked object, release conditions, guarantee relation and slashing or recourse conditions.

7.2 Behavior attributes

attributes is an object with the members linearity (linear, piecewise-linear, nonlinear, unknown), determinism (deterministic, stochastic, unknown), timeVariance (time-invariant, time-varying, unknown) and memory (memoryless, history-dependent, unknown). Each attribute is declared separately. These values are not mutually exclusive across attributes: a mechanism can be linear, stochastic and history-dependent at once.

7.3 Behavior models

models is an array of model statements, each with profile (R, a model profile identifier), modelRef (hash or URI of the model document), parameters, initialConditions, applicability (observation window, scale, operating range, error bound) and evidence. A behavior model describes how inputs, state, history, environment and triggers map to output flows and next state. It is a model of the Unit under stated premises, not a property of the Unit.

The financial-circuit model profile (Section 14.1) is one such profile. Others are extensions.

7.4 Structure

structure is { "profile": <structure profile> } with OPTIONAL interfaces and notes. auf:structure:simple@1 means a single element with no contains relation. auf:structure:composite@1 means the Unit has more than one element or at least one contains relation. auf:structure:chip@1 is a packaged functional body with explicit external interfaces and an internal composition structure; whether it can be simplified to an equivalent simpler model is a result of analysis, not a condition of the profile. A running agent MAY adopt the chip profile and MAY at the same time carry source, container and control roles.

7.5 Applications

applications is an array of application profile identifiers with OPTIONAL per-entry parameters. auf:application:credit@1 (Section 14.2) marks a Unit whose eligibility, limits, pricing or access depend on history, state and evidence.

7.6 Knowledge state

knowledge is { "status": <value>, "notes": <string> } with status one of classified, unclassified, insufficient-evidence or not-applicable. A characterization that states what is not known is valid and SHOULD be preferred to silence.

8. Observation records

An observation content document follows auf:observation:v1@1 and has the members window (R), snapshotAt (R), assets (R), nonCash, coverage (R), method, source and evidence.

8.1 Quantities

For each asset a (identified in CAIP-19 form, or by an extension identifier for off-chain resources) the record distinguishes:

• the stock Q_a inside the boundary at the opening and closing of the window;
• the cumulative external transfers through each port p, F_{p,a}, with direction;
• minting and burning of a inside the boundary;
• explicit adjustments with a stated reason.

An asset entry has the members asset (R), opening, closing, inflow, outflow, minted, burned, adjustments (array of { "amount", "reason", "evidence" }), transfers (array of { "port", "direction", "amount", "counterparty", "evidence" }) and missing (array of member names that could not be observed).

Transfers that cross no port (internal transfers between elements of the Unit) MUST NOT be reported as inflow or outflow of the Unit. They MAY be reported in a separate internal array for analysis.

8.2 Reconciliation

For every asset whose members are all present, the record MUST satisfy

closing - opening = inflow - outflow + minted - burned + sum(adjustments)

Quantities of different assets MUST NOT be added. Converting quantities into a common unit of account requires a price source and time point, which belong to a valuation, not to an observation.

8.3 Coverage, missing values and non-cash changes

coverage has the members observed (array of what was covered), missing (array of what was not covered, with reasons), method (how the values were obtained or verified) and source (indexer, attestation or other source). A member that could not be observed MUST be listed in missing and MUST be absent from the asset entry; it MUST NOT be reported as zero. Resolvers MUST treat an absent member as unknown.

Depreciation, model drift, credit deterioration, changes of obligations and other changes that are not realized transfers MUST be reported under nonCash as state or estimate entries ({ "subject", "kind", "from", "to", "basis" }), not as flows.

A realized net cash flow over the window for one asset is inflow - outflow. It is an observation result. Using it for a forward-looking value requires a method (Section 14.4.2).

9. Method descriptors

A method descriptor is a JSON document with the members auf (R), kind (R, "method"), name (R, a profile identifier of class method), version (R, semantic version), summary (R), inputs (R, a JSON Schema or a reference to one), outputs (R, a JSON Schema or a reference to one), algorithm (R, { "description", "formula", "implementation": { "uri", "hash" } }), assumptions (array of strings), applicability ({ "roles", "interests", "structures" }), composability (R), publisher and extensions.

methodId is the canonical hash of the descriptor. A URI alone does not fix a method; the descriptor MUST fix the input and output schemas and the algorithm version. Parameters that vary per evaluation are not part of the descriptor; they are bound into each valuation receipt.

composability is { "mode": <value>, "conditions": <string> } with mode one of additive, sub-additive, super-additive, conditional, context-dependent, unsupported or unknown. The mode describes how the method treats a composite in relation to its parts under the stated conditions. A method MUST state how it handles internal transfers, shared rights, overlapping contributions and composition effects, or declare the mode unsupported.

Methods MAY be registered in the Assertion Registry (registerDescriptor) for discovery. Registration is write-once per hash and does not imply approval.

10. Valuation receipts

10.1 Content

A valuation content document has the members subject (R), assessmentBoundary, interest (R), snapshot (R), method (R), inputs (R), result (R), horizon, validUntil, evaluator, notes, evidence and extensions.

10.2 Interest and perspective

interest is { "id": <interest profile>, "perspective": <value>, "detail": <string> }. perspective is one of holder, user, executor, funder, counterparty or analyst.

The same Unit can have different values for different interests and perspectives. A bounty held in escrow, the opportunity value of fulfilling the task and the value of the deliverable to the buyer are three different valuations and MUST be recorded as such.

10.3 Snapshot and assessment boundary

snapshot is { "asOf": <timestamp>, "observations": [<assertionIds>], "hash": <0x hash> } where hash is the canonical hash of the observation and state documents used. assessmentBoundary is { "hash": <0x hash>, "deltaURI": <string>, "notes": <string> }. When the evaluator values the Unit exactly as defined, assessmentBoundary.hash MUST equal the subject boundaryHash. When the evaluator adds or removes elements (for example includes a compute purchase obligation the definition omitted), assessmentBoundary.hash MUST be the canonical hash of the evaluator's own Unit Definition document, deltaURI MUST resolve to a description of the differences, and the receipt MUST still name the original subject. An evaluator MUST NOT publish a new version of the subject Unit for this purpose unless it is the Definition Controller.

10.4 Comparability

Two valuation receipts are comparable only when they agree on subject version, assessment boundary, interest, perspective, denomination, as-of time and horizon, and when their methods are the same or declared comparable. A matching boundaryHash is necessary but not sufficient. A receipt about version n of a Unit says nothing about version n+1.

10.5 Result

result is an object with kind (R) and kind-specific members:

denomination is an ISO 4217 currency code or a CAIP-19 asset identifier. decimals is the number of decimal places used for the on-chain value. Scores, grades and monetary values are different result kinds; a score MUST NOT be recorded as a monetary value. uncertainty ({ "type", "parameters" }) MAY accompany any result.

10.6 On-chain core and resolver rules

The on-chain valuation core (Section 11) carries methodId, interestId, assessmentBoundaryHash, snapshotHash, resultKind, value, denominationId, decimals, asOf and horizonEnd, where interestId = keccak256(UTF-8(interest identifier)) and denominationId = keccak256(UTF-8(denomination string)). For result kinds other than monetary, interval, scenario and conditional, value MUST be zero and consumers MUST read the content document.

Resolvers MUST present, with every valuation, its interest, perspective, denomination, as-of time, horizon, result kind, method identifier and whether the assessment boundary differs from the subject boundary. Resolvers MUST NOT aggregate valuations across different interests, denominations or assessment boundaries, and MUST NOT sum the valuations of a composite's parts into a valuation of the composite unless a method with a declared composability mode is applied.

11. Assertion Registry interface

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.20;

enum AssertionKind { None, Characterization, Observation, Valuation, Extension }
enum AssertionStatus { None, Active, Revoked, Superseded }

struct AssertionInput {
    AssertionKind kind;
    uint256 unitId;
    uint32 version;
    bytes32 profileId;
    bytes32 contentHash;
    string contentURI;
    uint64 validFrom;
    uint64 validUntil;
    bytes32 supersedes;
    bytes payload;      // ABI-encoded ValuationCore for Valuation, ObservationCore for Observation, empty otherwise
}

struct Assertion {
    AssertionKind kind;
    AssertionStatus status;
    bool byController;
    uint32 version;
    uint64 assertedAt;
    uint64 validFrom;
    uint64 validUntil;
    address asserter;
    uint256 unitId;
    bytes32 profileId;
    bytes32 contentHash;
    bytes32 supersedes;
    bytes32 supersededBy;
    string contentURI;
}

struct ValuationCore {
    bytes32 methodId;
    bytes32 interestId;
    bytes32 assessmentBoundaryHash;
    bytes32 snapshotHash;
    uint8 resultKind;
    uint8 decimals;
    int256 value;
    bytes32 denominationId;
    uint64 asOf;
    uint64 horizonEnd;
}

struct ObservationCore {
    bytes32 snapshotHash;
    uint64 windowStart;
    uint64 windowEnd;
}

interface IAUFAssertionRegistry /* is IERC165 */ {
    event DescriptorRegistered(bytes32 indexed descriptorHash, bytes32 indexed descriptorKind, address indexed publisher, string uri);
    event Asserted(bytes32 indexed assertionId, uint256 indexed unitId, uint32 indexed version, AssertionKind kind, address asserter, bytes32 profileId, bytes32 contentHash, bool byController);
    event ValuationAsserted(bytes32 indexed assertionId, uint256 indexed unitId, bytes32 indexed methodId, bytes32 interestId, uint8 resultKind, int256 value, bytes32 denominationId, uint64 asOf);
    event ObservationAsserted(bytes32 indexed assertionId, uint256 indexed unitId, bytes32 snapshotHash, uint64 windowStart, uint64 windowEnd);
    event Revoked(bytes32 indexed assertionId, address indexed asserter);
    event Superseded(bytes32 indexed assertionId, bytes32 indexed supersededBy);

    function unitRegistry() external view returns (address);

    /// @notice Registers a content-addressed descriptor (method, profile, schema). Write-once per hash.
    function registerDescriptor(bytes32 descriptorHash, bytes32 descriptorKind, string calldata uri) external;
    function descriptorOf(bytes32 descriptorHash) external view returns (address publisher, bytes32 descriptorKind, uint64 registeredAt, string memory uri);

    /// @notice Records an assertion made by msg.sender.
    function assertStatement(AssertionInput calldata input) external returns (bytes32 assertionId);

    /// @notice Records an assertion signed under EIP-712 by `asserter` (EOA or ERC-1271 contract).
    function assertStatementBySig(AssertionInput calldata input, address asserter, uint256 deadline, bytes calldata signature)
        external returns (bytes32 assertionId);

    /// @notice Revokes an active assertion. Only its asserter.
    function revoke(bytes32 assertionId) external;

    function assertionOf(bytes32 assertionId) external view returns (Assertion memory);
    function valuationCoreOf(bytes32 assertionId) external view returns (ValuationCore memory);
    function observationCoreOf(bytes32 assertionId) external view returns (ObservationCore memory);
    function assertionCount(uint256 unitId, uint32 version) external view returns (uint256);
    function assertionAt(uint256 unitId, uint32 version, uint256 index) external view returns (bytes32);
    function nonces(address asserter) external view returns (uint256);
    function DOMAIN_SEPARATOR() external view returns (bytes32);
}

Registry rules:

1. The Assertion Registry is bound to one Unit Registry at deployment. assertStatement and assertStatementBySig MUST revert when the subject version does not exist in that registry, when kind is None, when contentHash is zero, or when validUntil is nonzero and not greater than validFrom.
2. For Valuation, payload MUST decode as ValuationCore with resultKind in the range 1 to 11 and methodId equal to profileId; the registry MUST store the core and emit ValuationAsserted. For Observation, payload MUST decode as ObservationCore with windowEnd not smaller than windowStart; the registry MUST store the core and emit ObservationAsserted. For other kinds payload MUST be empty.
3. assertionId MUST be keccak256(abi.encode(address(this), asserter, nonce)) where nonce is the asserter's nonce before the call; the registry MUST increment the nonce for every recorded assertion, whether recorded directly or by signature.
4. byController MUST be set to unitRegistry.controllerOf(unitId) == asserter at recording time and MUST never change afterwards.
5. When supersedes is nonzero, the referenced assertion MUST exist, MUST be active, MUST have the same kind, the same unitId and the same asserter; the registry MUST set its status to superseded and record supersededBy.
6. revoke MUST revert unless msg.sender is the asserter and the assertion is active.
7. Recorded assertions MUST remain readable forever.

12. Signed assertions

assertStatementBySig verifies an EIP-712 signature over the following typed data. For contract accounts the registry MUST verify the signature through ERC-1271.

EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)
  name = "AUFAssertionRegistry", version = "1"

Assertion(uint8 kind,uint256 unitId,uint32 version,bytes32 profileId,bytes32 contentHash,
          string contentURI,uint64 validFrom,uint64 validUntil,bytes32 supersedes,
          bytes32 payloadHash,uint256 nonce,uint256 deadline)
  payloadHash = keccak256(payload)

The registry MUST revert when block.timestamp is greater than deadline or when the signature does not verify for asserter. The nonce in the typed data MUST equal the asserter's current nonce.

13. Extensibility

13.1 Namespaces

Identifiers in the auf: namespace are defined only by this ERC and its revisions. Extension kinds, relation types, roles, mechanisms, structures, applications, models, methods and interests use the x:<owner>: prefix. Owners SHOULD publish a profile descriptor (a JSON document with auf, kind equal to "profile", id, version, summary, semantics and schema) and MAY register its hash with registerDescriptor under descriptorKind = keccak256("auf:profile").

13.2 Extension members

Any object of the data model MAY carry an extensions member whose keys are extension identifiers. An extension member MAY carry "required": true.

13.3 Unsupported extensions

A consumer that does not understand a required extension of a document MUST report the document as unsupported for the purpose at hand. A consumer MAY ignore extensions that are not required. Silent omission of a required extension, followed by a conclusion, is non-conforming.

13.4 Revisions

Later revisions of this framework increment the auf data model version. A document with an auf version a consumer does not support MUST be reported as unsupported.

14. Profiles

The profiles of this section are OPTIONAL. An implementation that claims a profile MUST satisfy the requirements of that profile.

14.1 Financial-circuit analysis profile (auf:model:financial-circuit@1)

This profile describes a Unit, under stated premises, with the variables of the circuit view of token economics: a quantity q (a stock), a flow i (a rate of transfer), a potential difference v (a value difference that drives the flow) and the time integral phi of v.

A model statement under this profile MUST state:

• variables: for each of q, i, v and phi, the economic quantity it stands for and its unit. Dimensional consistency is REQUIRED; for example when q is a token supply and v a price per token, phi has the unit of price times time, not of locked value times time.
• elements: an array of element models, each with scope (as in Section 7.1), type and parameters. Defined types: source (v or i given independently), resistive (relation between v and i), capacitive (relation between q and v), inductive (relation between phi and i), memristive (relation between phi and q), higher-order (relation between a time derivative or integral of v of order alpha and one of i of order beta, with alpha and beta given), controlled (an element whose relation depends on a control input), switch, stochastic.
• premises: observation window, scale, operating range, linearization conditions and the error bound within which the model is claimed to hold.
• equivalents (OPTIONAL): an equivalent model of the Unit at its ports, for example a source in series with an impedance obtained by Thevenin's theorem for a linear model. An equivalent is a port-level abstraction of the Unit; it does not make the Unit a single element and it does not replace its composition.
• consistency (OPTIONAL): the result of a Tellegen consistency check, sum(v_k * i_k) = 0 over all branches of the model, which holds for any element types provided that the flows satisfy the flow conservation law and the potentials derive from node potentials of the model. The check reports whether these premises hold for the model, not whether the Unit creates or destroys economic value.

This profile makes no claim that every Unit admits such a model, that a given object is of one element type at all scales, or that a quantity reconciliation (Section 8.2) is a statement about economic value.

14.2 Credit profile (auf:application:credit@1)

A Unit under this profile has eligibility, limits, pricing or access terms that depend on its history, state and evidence. A credit statement MUST name the terms that depend on history (terms), the inputs that drive them (inputs, which MAY reference assertion identifiers, agent identity records and third-party attestations), the update rule or a reference to it (rule), and the conditions under which terms deteriorate (downgrade). History dependence MAY be declared as the behavior attribute memory = history-dependent. The memristive element type of Section 14.1 is a model label and MUST only be used when the stated relation actually holds; credit terms are in general not monotone in cumulative volume.

14.3 Chip profile (auf:structure:chip@1)

A Unit under this profile MUST declare every external port with a template or an explicit class, MUST declare its internal composition by contains, entitlement and interaction relations, and MUST carry a characterization with at least one role per external port. The profile is intended for packaged functional bodies: running agents, swarms, one-person companies operated by agents, and composed financial instruments.

14.4 Valuation profiles

Each valuation profile is a method descriptor published with this ERC (see Reference Implementation). The descriptors fix input and output schemas; the formulas below are normative for the profile.

14.4.1 Net equity (auf:method:net-equity@1)

Inputs: a list of asset positions and a list of liability positions, each with a quantity, a price in the denomination, a price source and time, and the rights and restrictions attached (locked, pledged, contingent). Output: monetary, value = sum(assets) - sum(liabilities), which MAY be negative. Positions excluded because of missing prices MUST be listed in the receipt's inputs.missing. Composability: conditional; internal claims between parts of a composite cancel, and a shared right is counted once at the share held by the Unit.

14.4.2 Realized net cash flow (auf:method:realized-net-cash-flow@1)

An observation profile. Inputs: an observation record and an asset or a set of assets with conversion rates where more than one asset is involved. Output: monetary, value = inflow - outflow over the window. The output is a historical measurement; it is not a value of the Unit and MUST NOT be presented as one. Internal transfers are excluded by construction (Section 8.1).

14.4.3 Finite-horizon discounted cash flow (auf:method:finite-horizon-dcf@1)

Inputs: a forecast of net cash flows c_1..c_n at the end of periods 1..n, a per-period discount rate r, a terminal value T received at the end of period n, and the attribution of the cash flows to the interest valued. Output: monetary,

value = sum_{t=1..n} c_t / (1 + r)^t  +  T / (1 + r)^n

The method is linear in the cash flows only when r and n are fixed; a receipt MUST record r, n and T. Composability: conditional.

14.4.4 Conditional payoff (auf:method:conditional-payoff@1)

Inputs: a finite set of scenarios s_1..s_k with payoffs x_j, probabilities p_j with sum(p_j) = 1, a per-period discount rate r, the number of periods n until resolution, and the costs included or excluded. Output: scenario with expectation

value = ( sum_{j=1..k} p_j * x_j ) / (1 + r)^n

The receipt MUST state the basis of the probabilities (declared, estimated, market-implied) and MUST state whether costs are included. The result is a valuation under the stated probability model; it is not a market price.

14.5 Bindings

Bindings connect Units to objects defined elsewhere. They are descriptive; none of them is required for conformance.

• Discovery: an element's ref MAY be the identifier of a value record anchored under ERC-8444. The record's posture (offer, tender, subject, index) is a property of the record; the economic roles of Section 7 are a separate dimension and MUST NOT be inferred from the posture.
• Agent identity: an agent element MAY reference an agent identity record such as those of ERC-8004 by its registry and identifier. Identity, liveness and reputation evidence are inputs to characterizations and valuations, not substitutes for them.
• Collective decisions: a dispute about a characterization or valuation MAY be decided under a collective decision framework such as ERC-8436. The decision outcome is recorded as a new assertion by the authorized party; it does not alter earlier assertions.
• Token-bound skills, task tenders, agent assertion frameworks and swarm registries: elements of kinds skill, task, agent and unit MAY reference tokens, tenders, assertions and swarms defined by other proposals through CAIP-19 and CAIP-10 references. A swarm describes a collaboration organization; a Unit describes an economic boundary, its roles and its measurement. One swarm MAY correspond to one Unit or to several Units cut by business or by rights.

15. Interface identifiers

IAUFUnitRegistry and IAUFAssertionRegistry interface identifiers are computed as the XOR of the selectors of all functions declared in Sections 4 and 11 (excluding supportsInterface), following ERC-165:

IAUFUnitRegistry       0x7128ef29
IAUFAssertionRegistry  0x46ae6e24

Rationale

Boundary first. The three questions of the framework (what is the whole, what does it do, what is it worth) depend on each other in one direction only. A classification or a valuation that does not pin the boundary it refers to cannot be compared with another. This is why the Unit Definition is versioned and hashed, why every assertion names a version, and why a valuation receipt carries an assessment boundary hash in addition to the subject.

A modeling order, not a derivation. Early drafts presented boundary, ports, flows, constitutive relations and valuation as a derivation chain. The same realized cash flows can come from different strategies, rights and risk arrangements, and a skill that has not yet earned anything must still be describable. The framework therefore treats the order as a dependency order for modeling (boundary and rights, then ports, state and obligations, then verifiable observations, then behavior models and classification under stated applicability, then valuation for a named interest), and it never claims that a later layer is uniquely determined by an earlier one.

Relations carry rights. Listing an element is not enough: the same model enters a Unit very differently as owned weights, as a monthly license, as reserved capacity or as an external dependency with a payment obligation. Typed relations with scope, term, quantity, share and exclusivity make "contains what" answerable as "contains under what terms", which is the information valuations actually consume.

Composition keeps structure. Two groups with the same three agents and two skills can be organized in parallel, in sequence, as producer-verifier-distributor, or as competitors for one outcome, and they differ in cost, output and failure modes. Interaction relations and ports keep that structure. Composition closure follows: a set of Units with compatible interfaces and rights is again describable as a Unit, which is what makes nested companies, swarms and portfolios first-class.

Acyclic containment by version pinning. Rather than running cycle detection on chain, the registry only accepts containment of versions that already exist, which makes the structural graph acyclic by construction and gives parents a stable boundary hash: a parent that pinned version 3 of a child is not silently changed when the child publishes version 4. Cross-holdings are entitlement relations and are allowed to form cycles, as they do in real economies.

Stackable roles instead of one label. A task with escrowed funds is a container while it holds funds, a pledge while delivery awaits acceptance, a conductor when it pays out, a damping element through its fees and a sink of service demand. A single label would hide most of this. Roles are statements about a part of the Unit under conditions; several can hold at once, and they are not shares of a whole.

Why eight roles. Source, sink, conductor, damping, container and pledge are the functions of the original circuit view. Valve and control were added because conditional release, eligibility gating, budget cut-offs and congestion pricing shape the economics of agent systems even when the gating element holds no funds. Credit is kept as an application profile rather than a role because credit terms depend on quality of performance, concentration and external events, not only on cumulative volume. Chip is a structure profile because being a packaged functional body is a matter of interfaces and composition, whereas being reducible to a simpler model depends on the model, the variables kept and the tolerated error.

Multi-dimensional description rather than a flat taxonomy. Linearity, determinism, time variance and memory are declared separately because they are not alternatives: a mechanism can be linear, stochastic and history-dependent at the same time. Named profiles are sets of conditions, not cells of a coordinate space, and the framework does not claim that any set of axes is complete. Completeness is instead stated operationally: any legitimate element can be referenced, any composition can state its relations and rights, and any situation that cannot yet be classified or valued can be expressed as such.

Measurement separated from valuation. Stocks, port transfers, minting, burning and adjustments reconcile per asset and are the shared, checkable base. Depreciation, drift and credit deterioration are state changes, not flows. Missing values are reported as missing because treating them as zero is the most common way a boundary is silently gamed. Valuation is then an explicit method applied to an explicit snapshot for an explicit interest. The framework standardizes the statement, not the opinion.

No universal conservation law. A Tellegen-type identity holds for any element types once flows satisfy conservation at nodes and potentials derive from node potentials. Whether economic value differences behave as node potentials, whether multi-asset exchange and liabilities are fully inside the model, and what the product of flow and potential means, are premises that a model must state. The identity is therefore offered as a consistency check inside the financial-circuit profile, never as a normative statement that every Unit conserves economic value.

Content-addressed methods. A method identifier that hashes only a URL does not fix anything, because the code behind the URL can change. Hashing a descriptor that includes input and output schemas and the algorithm version fixes what a receipt means. Parameters and evidence are bound per receipt. Registration is a discovery convenience; it is not an approval.

Interest and perspective. Receipts fix the interest valued because the same task is a purchase with a payment obligation to the buyer, a conditional income to a qualified worker and nothing tradable to a third party. Scores and grades have their own result kinds so that a score is never mistaken for a price, and negative, interval, scenario and "cannot value" results are first-class because a framework that can only express positive point values cannot describe obligations, options or honest ignorance.

Registry records, not tokens. A Unit is a registry record with a controller rather than a token because many Units (a static skill with several licenses, a portfolio defined by an analyst, a set of model rights) have no single settlement account and no transferable whole. Tokenizing a Unit, giving it an account or binding it to a swarm account are profiles layered on top; the kernel only needs the boundary, the assertions and the receipts.

Typed acknowledgments. Participation, resource-use authorization, fund-operation authorization and endorsement of a description are different commitments. A single boolean would force a model owner who merely confirms "yes, that is my model" into appearing to authorize its use. External dependencies are never asked to sign, so that independent analysis remains possible.

Why AIFi in the name. The framework is meant to be the economic base layer for the whole family of AI-native economic objects, not for agents alone. The term is defined generically in the Abstract; the openness of the framework rests on its generic definitions and interoperable data model, not on the word.

Origin. The role vocabulary and the financial-circuit profile come from the circuit view of token economics, in which real yield sources, burning resistance, capacitance-like containers and staking as a time-shaping element compose into larger structures, and in which non-linear "financial chips" are expected to appear. This ERC keeps that lineage as an analysis profile with explicit premises and keeps the normative kernel independent of it, so that readers who do not use the circuit view lose nothing.

Backwards Compatibility

No backward compatibility issues were found. The framework introduces new registries and documents and does not change any existing interface. Units reference existing tokens, accounts, records and identities by their own identifiers and never modify them.

Test Cases

The following cases are self-contained. Hashes use Keccak-256 over the UTF-8 bytes of JCS-canonical JSON. Monetary results are shown in the stated denomination with two decimals; the reference implementation computes them with 18-decimal fixed-point arithmetic.

Element identifiers

kind = "skill"
ref  = "eip155:11155111/erc721:0x00000000000000000000000000000000000000aa/1"
elementId = keccak256("skill:eip155:11155111/erc721:0x00000000000000000000000000000000000000aa/1")
          = 0x3f13ce02d4a85ecacba5b5a5e6658105bf3f9208088d43b2d394a1c1ca00d656

Canonicalization

The document

{"kind":"unit-definition","auf":"1.0","unit":{"name":"Vector Unit"},"elements":[],"relations":[],"ports":[],"authorities":{"definitionController":"none"}}

canonicalizes (RFC 8785) to

{"auf":"1.0","authorities":{"definitionController":"none"},"elements":[],"kind":"unit-definition","ports":[],"relations":[],"unit":{"name":"Vector Unit"}}

and its boundaryHash is the Keccak-256 digest of that byte string:

0xf77f708fc500b49c5471a1e6b9f268ccb7d26fb805a7cdf5b4a33a81b93d5be5

Valuation vectors

Exception vectors

1. Missing evidence: a net-equity receipt whose inputs lack a price for one position MUST list the position under inputs.missing and MUST NOT value it at zero; where the missing position is material the result kind MUST be insufficient-evidence.
2. Boundary change: a receipt recorded for version 1 of a Unit MUST NOT be returned as a valuation of version 2, even when the two definitions differ only by one element.
3. Internal transfer: in a Unit that contains agents A and B, a payment of 10.00 from A to B that crosses no port MUST NOT appear as inflow or outflow of the Unit; the realized net cash flow of the Unit for that transfer is 0.
4. Shared right: a skill included by two child Units with share = "1/2" each MUST be counted once at the Unit level by the net-equity method, not twice.
5. Expired or revoked evidence: an assertion past validUntil, or with status revoked or superseded, MUST be returned only when marked as such and MUST NOT be presented as current.
6. Unsupported extension: a document with an extension member marked "required": true whose identifier the consumer does not know MUST be reported as unsupported.

Registry behavior

1. registerUnit with a contains entry pointing to a non-existent Unit reverts.
2. publishVersion by an account other than the Definition Controller reverts; after setController(unitId, address(0)) every further publishVersion reverts.
3. A version that contains a version of its own Unit reverts.
4. assertStatement for a version that does not exist reverts; a valuation whose profileId differs from methodId reverts; a valuation with resultKind 0 or greater than 11 reverts.
5. Superseding an assertion of another asserter, of another kind, of another Unit, or one that is not active reverts; after a successful supersession the earlier assertion has status superseded and supersededBy set.
6. byController is true for an assertion recorded by the Definition Controller and remains true after the controller is changed.
7. assertStatementBySig with an expired deadline, a wrong nonce or a signature by another key reverts; a valid ERC-1271 contract signature is accepted.

Reference Implementation

The reference implementation, schemas, vectors and worked examples are provided with the assets of this proposal:

• AUFUnitRegistry.sol and AUFAssertionRegistry.sol, with the interfaces under contracts/interfaces, the shared types in AUFTypes.sol and the fixed-point reference arithmetic of the valuation profiles in AUFValuationLib.sol.
• JSON Schemas for Unit Definitions, characterizations, observations, method descriptors, profile descriptors and valuation receipts under schemas.
• Method descriptors of the four valuation profiles and the vectors of the Test Cases under vectors.
• Worked examples under examples: a static skill with several non-exclusive licenses, a task with escrowed funds and conditional settlement, a swarm with agents, a skill, an external model license and a task obligation, a Unit with no cash flow and a contingent obligation, and a running agent packaged under the chip profile.

Security Considerations

Boundary gaming. A Definition Controller can draw a boundary that omits costs and obligations (for example compute purchases or a pending payment) so that observations and valuations look better than the economics. The framework answers with typed relations and acknowledgments, with coverage and missing-value reporting in observations, and with the evaluator's own assessment boundary hash in receipts. Consumers should prefer receipts whose assessment boundary was set by an independent evaluator and should treat elements with missing expected acknowledgments as claimed rather than confirmed.

Self-declaration is not truth. A Controller Assertion proves who said something and that they committed to it. It does not establish that roles are correct, that costs are complete or that rights exist. Consumers decide which asserters to trust for which kinds and should weigh third-party assertions by the evidence they cite.

Evaluator collusion and spam. Anyone can record assertions. A Unit can be flooded with favorable valuations by colluding or disposable accounts. The registry keeps every assertion attributable and enumerable so that consumers can filter by asserter, by evidence and by independence; eligibility requirements for evaluators, stakes, and dispute processes are matters for profiles and for the systems that consume receipts. Eligibility of an evaluator never confers representation or asset rights over the Unit.

Double counting. Acyclic containment does not prevent the same resource from reaching a parent along two paths, and a shared skill is not a separate full asset in every Unit that uses it. Methods must handle shared rights, internal transfers and overlapping contributions explicitly, and resolvers must not add valuations of parts into a valuation of a composite without such a method. Cyclic entitlement structures require a method that declares a joint solution, an approximation or that it is unsupported; recursive summation would produce a number that looks precise and is wrong.

Stale and superseded statements. Receipts and characterizations age. Validity windows, revocation and supersession exist so that readers can tell current statements from historical ones. Consumers should refuse to act on expired or superseded assertions and should re-resolve the subject version before acting.

Controller key compromise. A compromised Definition Controller can publish a misleading new version. Earlier versions remain immutable and earlier assertions remain bound to their versions, so the history is auditable. Controllers of valuable Units should use multisignature or collectively governed accounts, and consumers should notice sudden boundary changes.

Descriptor availability and privacy. Content lives off chain behind descriptorURI and contentURI. Unavailable content makes a hash unverifiable; publishers should use durable, content-addressed storage. Definitions can disclose business relationships; publishers may keep sensitive fields as commitments and provide proofs of predicates to selected parties, while keeping the canonical hash of the full document on chain. A document that cannot be fetched is unverified, not invalid.

Signature replay. Signed assertions bind the chain identifier, the verifying registry, the asserter nonce and a deadline, so a signature cannot be replayed on another registry, another chain or after expiry.

Denomination and price manipulation. Monetary results depend on the price sources used to express positions in the denomination. Receipts record their inputs and the time of prices; consumers comparing receipts should check that the sources are independent of the Unit being valued.

Copyright

Copyright and related rights waived via CC0.