Reading the provider market

audience: ai

The signer organism’s provider market is a public Collection<ProviderId, ProviderCard>. Any bonded peer can read it; providers write their own card; the organism’s committee scheduler selects from the collection when rotating committee membership. Consumers read the collection when they want to audit the committee’s current attestation mix independently of any specific outcome.

The ProviderCard shape

pub struct ProviderCard {
    pub provider_id:             UniqueId,
    pub schemes_supported:       Vec<SignatureScheme>,
    pub attestation_level:       AttestationLevel,
    /// Measurements digest for TDX-attested providers;
    /// long-term identity digest for software-only.
    pub attestation_digest:      UniqueId,
    pub capacity_per_second:     u32,
    pub fee_per_partial_wei:     u128,
    pub committed_at_unix_secs:  u64,
}

Every field is read-side; the write-side ACL is the provider’s ACL composed with the organism’s min_attestation_level floor. A provider below the floor cannot register.

The attestation ladder in full

The AttestationLevel enum is totally ordered; a level meets a floor iff its discriminant is ≥ the floor’s. The five levels, bottom to top:

Software

Declared identity only. The provider publishes a long-term software signing key; no hardware attestation. Consumers trust only the declaration, and if the software is compromised, all signatures it produced are suspect. Viable for staging or for signatures whose forgery cost is below the cost of attesting.

TdxLocal

TDX self-quote produced inside the guest. Peer committee members verify against declared Measurements. No external relying party. A consumer outside the committee cannot re-verify; the level’s value is to other committee members bonding against each other.

TdxRemote

TDX quote verified against Intel DCAP’s remote attestation service (or an equivalent operator-run service whose trust root is published). A consumer outside the committee can re-verify the quote and confirm the provider ran a Measurements-matched image. This is the canonical floor for production deployments.

TdxRaTlsBidirectional

Both sides of the attested channel produce and verify quotes at bond formation. A signer whose counterpart failed to produce a quote refuses to bond; a signer whose counterpart produced a non-matching quote refuses. Downgrade attacks become visible as bond-formation failures rather than as silently accepted non-attested counterparts.

TdxPlusReproducibleBuild

RA-TLS bidirectional plus the provider publishes the build recipe whose hash the Measurements attest to. A third party reproduces the build from source, verifies that the resulting binary hashes to the same Measurements, and confirms the committee is running the code the source describes. Without the reproducible root, the consumer trusts that the operator built the image honestly; with it, the consumer verifies the binary matches the source without running the operator’s image.

The eligibility check

Every provider’s card is evaluated against the organism’s deployment parameters. The check is ProviderCard::is_eligible(scheme, floor):

impl ProviderCard {
    pub fn is_eligible(
        &self,
        scheme: SignatureScheme,
        floor: AttestationLevel,
    ) -> bool {
        self.attestation_level.meets(floor)
            && self.schemes_supported.iter().any(|s| *s == scheme)
    }
}

Two conditions: the provider’s attestation level meets the floor, and the provider declares support for the scheme the organism commits to. A provider that wants to serve two schemes registers two entries in schemes_supported; a provider that wants to serve two floors in two separate deployments registers two cards with distinct provider ids.

Consumer-side selection

The consumer does not need to pick specific providers; the organism’s scheduler picks. But a consumer that cares about the attestation distribution reads the card collection and can:

• Audit the mix. Count providers at each level. If the consumer’s floor is TdxRemote and only committee_size - 2 providers meet it, the consumer knows admission will succeed only when the 2-provider gap is not on the threshold boundary.
• Rank by fee. A consumer that wants to estimate cost reads fee_per_partial_wei per card and forecasts end-to-end cost as threshold × mean(fee).
• Track capacity. A consumer planning a burst reads capacity_per_second per card and computes whether the committee can absorb the peak.

None of these are required; the organism’s scheduler runs correctness-safe selection regardless. The collection exists because mosaik’s stigmergic-collection pattern (emergent coordination — pattern 1) works at this rung: public reads, consumer-side filtering, no central allocator.

Provider competition shape

Providers compete on three axes. All three fold into ProviderCard::card_digest; a change to any is a republish event observable through the collection.

• Attestation level. Higher levels pull in more consumers (wider admission) at higher operational cost (reproducible builds require source-and- toolchain hygiene).
• Capacity. A provider with higher capacity_per_second wins more committee slots in bursty windows; a provider with lower capacity runs cheaper.
• Fee. fee_per_partial_wei is the per-partial- signature price the provider commits to. A provider charging above the committee median needs matching quality (higher attestation, lower tail latency, better availability); a provider charging at or below median gets routine allocation.

A reputation organism gating admission on ProviderCard quality (uptime, completed-requests ratio, attestation-challenge pass rate) is the closest kin to the web2 provider-reputation pattern. This chapter names the shape and stops; reputation organisms are specified once in ai/emergent-coordination.md — pattern 2.

Forward

Chapter 4 (wrapping) walks the provider side: how each attestation level is produced in practice — TDX quote, Intel DCAP verification, RA-TLS bidirectional channel, reproducible-build recipe.