# Guarantors Independent batch replay, bonded attestations, checkpoint certificates, and settlement accountability. Guarantors connect Layer X execution to Paxeer settlement. Each guarantor retrieves sealed batch data, independently executes it, compares the committed results, and signs an attestation only after verification. The certificate aggregates the required eligible attestations into evidence that the settlement registry can check. ## Replay before signing 1. Pin the network, sequencer identity and key, and authorized batch range. 2. Retrieve the signed candidate header and its availability chunks. 3. Verify request correlation, chunk indices, hashes, Merkle proofs, the terminating response, and the reconstructed availability root. 4. Load the verified genesis and registration state, validate actor signatures and authority, and replay the kernel and Programs runtime. 5. Compare receipts, state diffs, recovery metadata, and committed roots before retaining or signing evidence. The producer verifies receipt signatures with the sequencer public key; it does not need the sequencer private key. Deterministic program calls, program-owned transfers, and storage-occupancy charges participate in the same replay. Replay failure stops attestation production. ### Data availability is part of verification Candidate retrieval is bounded by deadlines, frame limits, arena limits, and a canonical limit of 4,096 chunks. Reconstruction verifies the five ordered availability classes and the signed header's availability root using canonical 65,536-byte chunk encoding. A missing terminator, unavailable data, or a root mismatch is a refusal to sign. ## Attestations and certificates Guarantors exchange canonical attestations through authenticated peer connections. An incoming attestation must pass signature and recovery verification, bonded-membership checks, and checkpoint-identifier recomputation from a locally verified header. The certificate assembler sorts guarantor identifiers and requires the configured threshold. | Evidence | Meaning | | --- | --- | | Signed batch header | Sequencer commitment to batch ordering and roots. | | Guarantor attestation | A bonded signer's statement about a verified checkpoint. | | Checkpoint certificate | Canonical aggregation of the required eligible attestations. | | Settlement registration | The registry accepts the certificate under the deployed domain and contract rules. | Checkpoint-certificate and guarantor-attestation signatures use distinct domain separators: `LXP/v2/checkpoint-certificate` and `LXP/v2/guarantor-attestation`, each followed by a null byte. Certificates carry an empty validity-proof field. An attestation is bonded re-execution evidence, not a zero-knowledge validity proof. ## Bonded membership The GuarantorBond contract records each guarantor's signer, bond controller, deposited amount, membership epochs, jail status, and slashing state. Membership governance activates and removes guarantors, rotates signers, and changes jail status with increasing governance sequences. Membership changes advance the set version used by eligibility checks. The minimum bond is the custodied value multiplied by the configured basis-point requirement, rounded up. Eligibility depends on sufficient backing and the contract's active membership, signer authorization, epoch, jail, ejection, and unresolved-slashing checks. Depositing tokens alone does not create membership authority. ### Unbonding 1. Membership governance removes the guarantor from the active set. 2. The bond controller starts an eligible withdrawal for a specified amount. 3. The configured unbonding delay elapses without unresolved slashing blocking the withdrawal. 4. The controller finalizes the withdrawal, or cancels the pending request before finalization. The deployed unbonding delay is a contract configuration and is at least one day. A pending withdrawal is not immediately spendable backing released from the contract. ## Equivocation and accountability Verified contradictory statements for the same identity, epoch, and batch form equivocation evidence. GuarantorBond validates canonical domain-bound attestations and signer authority before applying its equivocation slashing path. The separate slashing authority controls checkpoint-related slashing and unresolved-slashing status under the contract's access rules. For example, two signatures from one authorized guarantor over conflicting checkpoints for the same epoch and batch are evidence to investigate and submit through the defined verification path. A timeout or a malformed unsigned response is not, by itself, that signed contradiction. ## Settlement confirmation The submitter validates the deployed chain and registry binding, encodes the certificate, and submits a settlement transaction. Registration is confirmed against successful receipt status, transaction identity, the canonical block, and every checkpoint-registration event field. An existing registration is accepted only when it records the exact certificate. The node independently verifies the finality bundle returned to it. The producer then compares the node's stored finality evidence with the submitted bundle. These checks connect locally verified execution, the registered certificate, and the evidence applications subsequently consume. ## Operator responsibilities Maintain a distinct signing identity, exclusive persistent-state ownership, durable availability data, and retained attestations. Reuse stored attestations for a previously signed batch rather than generating replacement signatures. Peer transport uses mutual TLS with CA and hostname verification. Organizational and infrastructure independence require separate operator arrangements; two different keys alone do not establish that independence. Replay supports the direct-owner authority path and explicitly refuses unsupported oracle inputs or incomplete rotated-signer history. Treat these refusals as verification boundaries. A guarantor must obtain sufficient replay evidence before attesting. ## Continue See [Finality](https://docs.paxeer.app/finality), [Governance](https://docs.paxeer.app/governance), and [Security and trust boundaries](https://docs.paxeer.app/security).