Reputation Clearing

Every input names its issuer, and the receiver sets its weight

An input is a reputation summary or a negative event about the clearing's subject. It references a portable summary or a portable negative event by digest, names the issuing operator, and carries the receiver's weight for it in basis points, from 1 to 10000.

The clearing lists the operators party to it, and every input's issuer must be one of them. It names the receiver's local weighting policy and the open-admission policy its class is drawn from, and it sorts every input into exactly one of accepted or rejected. Only accepted inputs count toward the sybil control.

The sybil control caps what any one issuer can contribute

Five settings bound the clearing, and the validator refuses any clearing that breaks one. The reference clearing's values are in parentheses.

1. Local weighting. localWeightingRequired is true on every valid clearing, so the receiver's own weights always apply.
2. Inputs per issuer. One issuer contributes at most maximumInputsPerIssuer inputs (2), and at most one accepted reputation summary.
3. Oracle cap. No input's weight exceeds oracleCapBps (4000), so no single issuer becomes the oracle.
4. Independent issuers. Accepted inputs come from at least minimumIndependentIssuers independence groups (2).
5. Corroboration. With negativeEventCorroborationRequired, a blocking negative event needs a second, independent issuer.

An input's independence group is its issuerIndependenceGroupId when it names one, and its issuer otherwise, so two issuers in one group count once. A clearing that accepts no input skips the minimum, and its class is then public_untrusted.

A blocking negative event stands only with a second issuer behind it

A negative event marked blocking can keep a subject out. The validator groups accepted blocking events by independence group and refuses the clearing when they all come from one group.

In frc-1, indexer-operator-a and origin-operator each report a blocking event, so the pair stands. Only negative events block: a reputation summary marked blocking is refused. Corroboration is requirement TRUSTMAX-04 in the qualification matrix on Federation Assurance.

The federation guide clears frc-1 and refuses three variants of it

The guide project validates the published reference clearing, then hands the same validator a clearing with two accepted summaries from one issuer, one without local weighting, and one under an unsupported schema.

Clear shared reputation under local weighting

Validate the reference clearing, then refuse a clearing with two accepted summaries from one issuer and a clearing that drops local weighting.

Complete the project setup, then run the program from federation-guide/. The download includes every constructor and input.

cargo run --locked --bin reputation

reference clearing frc-1: valid; 4 inputs from 4 operators; effective class Reviewable
sybil control: at least 2 independent issuers, at most 2 inputs per issuer, oracle cap 4000 bps
two accepted summaries from one issuer: refused (invalid clearing: accepted reputation summaries must come from distinct issuers)
clearing without local weighting: refused (invalid clearing: federated reputation clearing must require local weighting)
unsupported schema: refused (unsupported schema: chio.federation-reputation-clearing.v0)

Clearing checks the contract over declared inputs; it does not fetch or verify the referenced summaries and negative events. Receiver-side scoring is a separate local policy, documented under Economy.

//! Validate a shared reputation clearing and refuse the shapes that would turn
//! it into an oracle: two accepted summaries from one issuer, and clearing
//! without local weighting.
use chio_federation::error::FederationContractError;
use chio_federation::reputation::{
    validate_federated_reputation_clearing, FederatedReputationClearingArtifact,
};
use serde_json::Value;

fn receive(value: Value) -> Result<FederatedReputationClearingArtifact, FederationContractError> {
    let clearing: FederatedReputationClearingArtifact = serde_json::from_value(value)
        .map_err(|e| FederationContractError::InvalidClearing(e.to_string()))?;
    validate_federated_reputation_clearing(&clearing)?;
    Ok(clearing)
}

fn main() -> Result<(), Box<dyn std::error::Error>> {
    let reference: Value = serde_json::from_slice(&std::fs::read("reputation-clearing.json")?)?;
    let clearing = receive(reference.clone())?;
    println!(
        "reference clearing {}: valid; {} inputs from {} operators; effective class {:?}",
        clearing.clearing_id,
        clearing.inputs.len(),
        clearing.participating_operator_ids.len(),
        clearing.effective_admission_class
    );
    println!(
        "sybil control: at least {} independent issuers, at most {} inputs per issuer, oracle cap {} bps",
        clearing.sybil_control.minimum_independent_issuers,
        clearing.sybil_control.maximum_inputs_per_issuer,
        clearing.sybil_control.oracle_cap_bps
    );
    let mut duplicate = reference.clone();
    duplicate["inputs"][1]["issuerOperatorId"] = "origin-operator".into();
    duplicate["inputs"][1]["artifactRef"]["operatorId"] = "origin-operator".into();
    let err = receive(duplicate).unwrap_err();
    println!("two accepted summaries from one issuer: refused ({err})");
    let mut unweighted = reference.clone();
    unweighted["sybilControl"]["localWeightingRequired"] = false.into();
    let err = receive(unweighted).unwrap_err();
    assert!(matches!(err, FederationContractError::InvalidClearing(_)));
    println!("clearing without local weighting: refused ({err})");
    let mut wrong_schema = reference;
    wrong_schema["schema"] = "chio.federation-reputation-clearing.v0".into();
    let err = receive(wrong_schema).unwrap_err();
    assert!(matches!(err, FederationContractError::UnsupportedSchema(_)));
    println!("unsupported schema: refused ({err})");
    Ok(())
}

Open the source file. Each program asserts its expected refusals; keys, timestamps, and digests change between runs.

You should see frc-1 valid with effective class Reviewable and the sybil control read back, then three refusals, each naming the rule or schema that failed.

Reputation from outside a clearing arrives as evidence you weigh

When your operator imports a partner's evidence package, the local comparison view reports native reputation and imported trust side by side. It shows explicit provenance and echoes the imported-trust policy at report time; the share's import-time requireProofs flag rides in its provenance. By default, proofless shares are rejected, stale signals expire, and the composite score is attenuated.

An Agent Passport carries issuer-signed credentials with identity and reputation information, including references to receipt evidence. Your operator checks the credential signatures and applies its own issuer, status, and evidence policy. A referenced receipt root identifies evidence, and each receipt beneath it is verified on its own. Compare a presented passport with your own receipts for the same subject, and the CLI prints both scores and the attenuation between them:

chio reputation compare --subject-public-key 5a2d…e7c4   --passport passport-halden-bounty-417.json

subject     5a2d…e7c4 (fixer-2)
passport    passport-halden-bounty-417, issuer did:chio:z6MkpA7…c2T, signatures verify
native      0.71 composite over 38 receipts on your kernel
imported    0.84 claimed, 0.42 after 0.50 attenuation, proofs required
policy      verifier policy satisfied; the passport authorizes no call

• Issuance. A passport feeds the verifier policy that decides whether the trust service issues a capability for its subject (chio trust federated-issue). A presented passport authorizes no tool call itself, and the federated grant it leads to requires a DPoP proof at your door.
• Several issuers. The bounded CrossIssuerPortfolio profile composes credentials from several issuers as an evidence container, and adds no trust root of its own.
• Lifecycle. Status is issuer-signed, pulled from the status resolve URL, and kept for its TTL; a stale status fails closed. When verifier policy requires an active lifecycle, stale, superseded, revoked, and not-found refuse the presentation.

Read more in Portable reputation and Reputation and passports.

Next: set the policy a clearing's class comes from