Known Limitations
ALX defines specific guarantees for Block identity, declared parent relationships, and verification. The sections below list the limits of those guarantees in protocol version 1 and in the current implementations, and the evidence to record before relying on them.
Protocol Limitations
Protocol version 1 has the following limits. Trust Boundary lists the claims verification does not establish.
| Limitation | Effect |
|---|---|
| Content is limited to ALX values | undefined, BigInt, dates, binary data, and other unsupported types are rejected. Applications encode such values first, for example binary data as a hexadecimal or base64 string. |
| Safe integers only | Integers outside -(2^53 - 1) to 2^53 - 1 are rejected. Larger values need a string encoding. |
| No Unicode normalization | Visually identical strings in composed and decomposed forms produce different hashes. |
| Fixed size limits | Content nested more than 128 levels deep and parent sets larger than 256 hashes are rejected. |
| Declared lineage only | Verification binds declared parents to Block identity. Application evidence determines whether the declarations cover every real-world dependency. |
| No reverse links | A Block records only its parents. Children and descendants require an application index. |
- Protocol and Package
- Build, Deployment, and Audit
- Contract Control Model
Implementation capabilities differ; evaluate the exact package version and source revision.
| Capability | Status |
|---|---|
eip712 attestation suite | JavaScript package only. Outside portable signing-extension conformance, with no cross-language vectors. |
| Protocol Requests | JavaScript package only. No conformance vectors. |
| Content profile extension | Provisional and schema-only. No vectors. |
validateGraph(graph, context) adjacency form | Deprecated in the JavaScript package. Use validateGraph(seed, source, context). |
signBlock() and verifyBlockSignature() | Deprecated. Scheduled for removal in v2.0. |
Connect every contract address to reproducible source, build, deployment, and review evidence.
Record the source revision, compiler configuration, artifacts, deployment manifest when published, chain ID, contract address, transaction evidence, and audit status. Contract source code alone does not establish deployment or audit status. ALX on Base publishes the current evidence for the Base deployment.
Evaluate authorization, administration, recovery, upgrade, publication, timestamp, and finality controls.
ALXAnchor accepts submissions from any address, and the first transaction to record a value sets anchoredBy and anchoredAt permanently. A recorded value carries no authority of the recording address. Contract controls belong to the specific deployment; core ALX Block validity remains independent of those controls.
Integration Checklist
Before deploying an integration, record the following, and reevaluate the recorded assumptions after implementation upgrades, canonicalization or signing changes, infrastructure changes, or broader user-facing claims:
- Protocol specification version
- Package or implementation version, source revision, and conformance results
- Claimed extensions and signing suites
- Signing domain and message format, when used
- Contract source, build configuration, and deployment evidence, when used
- Application trust and acceptance policies
When to Use These Limits
Review the applicable limitations before production deployment, implementation upgrades, infrastructure changes, or user-facing claims based on verification results.