Cross-Org Swarms

Four checks stand between the hop and the partner’s tool

Two checks run where the hop departs and two where it arrives. Each is a separate function with its own error type, and passing one never stands in for another.

Your kernel runs the departing pair. verify_swarm_authority_bundle refuses a hop whose continuation, witness chain, route plan, budget allocation, join receipt, or revocation epoch does not tie back to the signed graph; it refuses an empty set of trusted witness issuer keys before reading the bundle, and a bundle with no continuation tokens or no witness chains before reading a hop. validate_route_plan_target then refuses a route plan whose selected route, protocol target, and egress contract do not all name the same bridge.

The partner’s kernel runs the arriving pair at its own door. evaluate_cross_boundary_admission refuses an action class outside the treaty scope, an intersection whose digest is not the expected one, and required evidence that is absent or unverified. The class’s joint signature must then resolve; for a quorum class, verify_for_execution refuses an aggregated group signature without an active roster and a completed authorization slot.

The graph layer reads no treaty, ladder manifest, or peer kernel id. It proves that the graph’s own issuer authorized the hop and that the egress fields agree. Acceptance belongs to the treaty, whose shared contract keeps the stricter governance mode and co-sign requirement of the two operators.

Read more in Swarm Authority, which walks the bundle and the order of its checks.

The partner admits action classes under the stricter of two ladders

A treaty admits action classes. Each participant publishes a signed governance ladder naming the classes it takes part in and the governance each carries, and each kernel folds the two ladders on its own.

for participant in &treaty_scope.participant_kernel_ids {
    // … find this participant's action class
    let rank = ladder_mode_rank(&action.mode)?;
    if rank > mode_rank {
        mode_rank = rank;
        mode.clone_from(&action.mode);
    }
    destructive |= action.destructive;
    if let Some(existing) = consistency_model.as_ref() {
        if existing != &action.consistency_model {
            return rejected(
                "chio_federation_ladder_consistency_mismatch",
                "governance ladder consistency models do not intersect",
            );
        }
    } else {
        consistency_model = Some(action.consistency_model.clone());
    }
    if co_sign_requirement_rank(&action.co_sign)? > co_sign_requirement_rank(&co_sign)? {
        co_sign.clone_from(&action.co_sign);
    }
    // … merge the co-sign quorum
    for item in &action.evidence_required {
        evidence_required.insert(item.clone());
    }
    // … record participant_modes
}
if destructive && mode_rank < ladder_mode_rank("receipt_backed")? {
    return rejected(
        "chio_federation_ladder_destructive_below_floor",
        "intersected destructive action resolves below receipt backed mode",
    );
}
// … then the destructive crdt-commutative check

The fold takes the strictest mode and co-sign requirement, the union of required evidence, and equal consistency models; participants that disagree on consistency are refused with chio_federation_ladder_consistency_mismatch. The financial domain ladder of spec/CHIO_LADDER.md section 5.2 is the economy’s own set, and it gives the settlement, clearing, and credit classes their co-signature requirement:

Every class marked destructive: true sits at receipt_backed or above, the manifest’s declared destructive_floor, and none uses crdt-commutative. Manifest validation rejects a destructive class below its floor with chio_federation_ladder_destructive_below_floor, one paired with commutative consistency with chio_federation_ladder_destructive_crdt_not_allowed, and one with an empty evidenceRequired list.

Read more in Governance Ladder, which covers the five modes and every per-class field.

Each financial class names the signature it needs

The intersection decides which co-sign mode governs a class, and the admission report turns that mode into evidence the caller must hold. required_evidence_for_action adds bilateral_invocation when the mode is bilateral_required and quorum_signature when it is n_of_m; bilateral_if_cross_org adds neither, which makes that mode conditional.

All three quorum classes in the financial ladder are 2-of-3 at scope: treaty; the compliance ladder in the same document raises governance.case_enforce_sanction and governance.roster_rotate to 3-of-5. The FROST registry hard-codes a quorum per class and refuses a roster whose threshold and participant count disagree with a class it lists. Before the effect runs, verify_for_execution checks the group signature, the active roster and current epoch, the completed slot holding the exact proof bytes, and eight expected inputs.

Each path accepts only its own kind of authorization. A predicate declaring co_sign: n_of_m through the ordinary path is rejected with co_sign n_of_m requires the strict verifier API with VerifiedFrostAuthorization, and a verified authorization supplied with a bilateral_required predicate is itself an error. bind_frost_authorization_to_predicate binds a supplied authorization on five axes, and TreatyBindingRef carries the SHA-256 of the treaty scope, the ladder intersection, and the admission report, so a co-signed invocation names the exact fold and decision it was admitted under.

Read more in FROST Quorum and Bilateral Co-Sign.

A facility binding runs only with every check satisfied

Your swarm on issue #418 hands a step to your partner: bind the USD 5.00 credit facility that pays for the partner's agents. The signed graph, continuation, attenuation chain, and budget are valid, and credit.facility_bind is receipt-backed with bilateral authorization required. The analysis the partner's fixer-2 returned in an earlier step authorizes nothing here; the financial step carries its own authorization, and the partner's kernel admits it at its own door, in five stages:

1. Authority and egress. Assemble the signed graph, continuation, witness chain, and budget allocation, then run verify_swarm_authority_bundle and the route-target validation against trusted inputs. The peer and capability integration comes first.
2. Shared contract. From trusted participant manifests and a scope that binds their digests, compute_ladder_intersection produces the shared requirements and ladder_intersection_sha256 its canonical digest.
3. Evidence. Authenticate each required artifact through its own verifier and populate CrossBoundaryEvidenceRef from the results. The treaty evaluator reads the supplied verification flags and opens none of the referenced artifacts.
4. Admission. Evaluate the class against the trusted scope, the expected intersection digest, the evidence references, and the current time. A structural error and a valid refusal report both stop the action.
5. Joint authorization. Bind the bilateral verification to this invocation and treaty, continue only after every required check succeeds, and retain the contract, the report, and the invocation evidence.

// Embedding host. input is a CrossBoundaryAdmissionInput assembled from the
// trusted contract and independently verified evidence. The enclosing function's
// error type accepts the treaty error and a string error.
let report = evaluate_cross_boundary_admission(input)?;
if !report.accepted {
    // A policy refusal can be Ok(report). Returning here prevents dispatch.
    return Err(report.failure_code.as_deref()
        .unwrap_or("cross_boundary_admission_denied").into());
}
// Continue with the applicable joint-authorization checks before dispatch.

? handles structural errors only. A policy refusal returns Ok(report) with accepted false, so the explicit check is what prevents dispatch. Remove the required co-signature and the binding stops at the last check; point the target at a bridge outside the egress contract and the route check refuses it first.

The treaty CLI walkthrough runs the same sequence with captured output: intersection, admission, a missing-evidence denial, and packet verification. Its --evidence class=digest arguments assert verification the caller already performed, and a digest on the command line is not a verified signature.

A changed contract needs a new admission

A saved admission report records one decision under particular digests. When the shared terms change, the operators coordinate a replacement contract and admit the action under it.

• A participant changes its manifest. The trusted replacement’s digest is bound in the scope and the intersection is recomputed. Consistency models that disagree are reconciled in the operators’ configuration, since the same inputs reproduce the mismatch.
• The scope or intersection expires. Admission reruns on current inputs at the current time. The intersection expires at the earliest manifest or scope deadline, and an old accepted report keeps that deadline.
• An action leaves the allowed scope. It stops, and resumes only under a contract that includes it or as a different authorized operation. Renaming the request supplies no authority.
• Required evidence or a signature is missing. The artifact is obtained and verified for this invocation before admission reruns. A quorum class takes the strict quorum path, and a bilateral artifact cannot replace it.

Each refusal names its cause in failure_code, beside the report’s required evidence, present evidence, and bound digests. Stale contracts, intersection mismatches, excluded action classes, missing evidence, and unverified evidence each have their own outcome. The operator fixes the named input and reruns the checks, and the report’s accepted boolean is the decision.

If communication fails after the partner’s tool may have run, the question becomes reconciling that invocation. A new treaty decision cannot establish whether the first effect happened, or roll it back.

Next: compose a treaty end to end