Skip to main content

Signing

ALX supports optional EIP-712 typed signatures for attaching cryptographic evidence to Blocks and protocol-related requests.

Signing does not change contentHash, blockHash, or declared lineage. A Block can be created and verified without a signature.

EIP-712 typed data allows signers and verifiers to reconstruct the same structured message and signing domain.

Signing Domain Requirements​

An EIP-712 signature is bound to the exact typed message and signing domain used to produce its digest. Changing the chain ID, verifying contract, action, payload hash, nonce, or expiry produces a different digest and invalidates the signature for the modified context.

Verification must reconstruct the exact message type and domain expected by the target implementation or deployment.

Signing Model​

ALX distinguishes between two signing purposes:

  • Block attestations associate an attester with a specific Block identity.
  • Protocol requests bind an actor to a specific action and replay context.

The two message types have different fields and verification requirements and are not interchangeable.

Block Attestation​

A Block attestation associates an attester with a specific blockHash at a stated timestamp.

BlockAttestation(
  bytes32 blockHash,
  address attester,
  uint256 timestamp
)

Block attestations are designed as durable evidence associated with a Block identity. They do not include a nonce or expiry and therefore do not provide request replay protection.

A valid attestation establishes that the recovered signer signed the specified typed message. Application interpretation determines whether the attestation represents authorship, approval, certification, or ownership.

Protocol Request​

A protocol request binds an actor to a specific operation and verification context.

The signed payload includes:

  • Actor
  • Nonce
  • Expiry
  • Chain ID
  • Domain
  • Action
  • Payload hash

The nonce and expiry support replay controls. The remaining fields bind the signature to the intended operation and context.

Protocol requests are intended for operations requiring request-specific authorization or authentication semantics. They should not be substituted for durable Block attestations.

Signature Verification​

A verifier reconstructs the expected EIP-712 typed data and domain, derives the signing digest, and recovers the signer.

For protocol requests, verification also evaluates the applicable nonce and expiry requirements.

Successful cryptographic verification establishes that the recovered signer produced a valid signature for the specified message and domain. The signature result does not, by itself, establish authorship, ownership, authority, approval, or the truth of the signed content.

When to Use Signing​

Use a Block attestation when an application needs durable evidence associated with a Block identity. Use a protocol request when an operation needs nonce, expiry, chain, domain, action, and payload binding.

Compatibility​

The current JavaScript reference uses the EIP-712 domain name AlexandrianProtocol with version 1 for compatibility.

The declarations for the current reference indicate that new registry deployments use ALXProtocol.

Integrators must use the exact domain expected by the implementation or deployment they are verifying. Domain names should not be substituted based on branding or display conventions.

Verification Binding​

Verification must be bound to the exact message type and context expected by the target.

Depending on the signed message, the verification context can include:

  • EIP-712 domain
  • Chain ID
  • Verifying contract
  • Signer or actor
  • Nonce state
  • Expiry
  • Action
  • Payload hash

The durable typed message binds a Block hash, attester address, and timestamp.

Block attestations do not include request replay prevention.