You run a guarantor that downloads each full batch body, verifies every actor, grant, oracle and sequencer signature, replays from the previous state root and recomputes every committed root. Sign only when all of them match byte for byte; on one byte of disagreement you withhold the signature and publish a dissent naming the first divergent sequence. Equivocation, an upheld fraud challenge or an upheld availability challenge takes bond, and reporters keep a 10% share.

What it does

Guarantors are bonded operators that independently re-execute each LayerX batch before it settles on the Paxeer chain. A guarantor downloads the complete batch body, verifies every actor, grant, oracle and sequencer signature, replays from the previous state root and recomputes every committed root, and signs only when all of them match byte for byte. A checkpoint is finalised once at least the configured threshold of attestations over a byte-identical certificate is registered on Paxeer. Signing two different checkpoints for the same batch, an upheld fraud challenge or an upheld data-availability challenge takes the bond and ejects the guarantor.

Key capabilities

• Full independent re-execution of each batch before any attestation is signed.
• One-byte disagreement withholds the signature and publishes a dissent naming the first divergent sequence.
• Equivocation slashing needs only two signed attestations; anyone may report it.
• An attestation also commits that the guarantor holds the availability data for that batch.
• Slashing reaches bond that is already unbonding but still inside its delay.
• Reporters keep a 10% share of the slashed amount; the rest is burned or routed to a configured account.

Differentiators

Guarantors re-execute the full batch and must agree on every committed root before signing, rather than sampling or accepting the producer's roots. Equivocation is slashed permissionlessly: the two signed attestations are the entire proof and no arbiter is involved. A slash also cuts unbonding entries that have not passed their completion time, so exiting early does not escape it.

Outcomes

• Settlement anchors only after separately bonded parties recompute the result
• Anyone reports equivocation using the two signed attestations alone
• Slashing reaches unbonding bond still inside its delay

Technical notes

• Slash fractions default to 100% for equivocation, 100% for upheld fraud and 50% for upheld unavailability, with a 10% reporter share. One (guarantor, reason, batch) offence is slashed once, and the record keeps both checkpoint hashes.
• Module defaults: threshold 1 (valid range 1 to 32), 21-day unbonding delay, 3,600,000 ms maximum attestation delay, and a challenge window of 0 seconds. Registration by anyone other than the authority stays pending until the authority activates it, unless permissionless registration is switched on.
• Protocol caps: at most 32 attestations per certificate and 32 genesis guarantors, 274 bytes per attestation, 64-byte header signatures, and a validity-proof field of at most 1,048,576 bytes. Eight divergence categories are defined: signature, state root, result code, fee, effects, balance, receipt and events.
• The Solidity bond contract accepts only the USDL token at the fixed address 0x85FcD13735F4309833A503EE804ea32395851479, derives the minimum bond as a basis-point share of custodied value, and requires a withdrawal delay of at least one day. Eligibility also requires an active signer authorisation for the checkpoint epoch, no jail flag and no unresolved slashing.
• Operator floor is documented as 16 physical cores, 64 GB ECC memory, NVMe with power-loss-protected fsync, 35 TB usable and 50 Mbit/s committed bandwidth; 32 cores, 128 GB and 1 Gbit/s are recommended. That floor is sized against a documented target of 4,000 activities per second and roughly 4.5 MB/s of availability data, and a documented retention of 90 days past finality for activities, receipts, oracle inputs and recovery metadata, 30 days for state diffs.
• Not yet implemented: certificates carry an empty validity proof and no validity-proof generation is claimed, so threshold attestation is an economic guarantee rather than a validity proof. Fraud and data-availability disputes are decided by the authority on both the module and the contract side; there is no on-chain fraud-proof verifier. The beta runs two guarantor identities from the same cluster, so there is no operational independence yet. The module's default challenge window of 0 seconds finalises with no dispute delay, while the deployment configuration validator rejects any challenge window under one hour.

More in Network