Cryptographic integrity establishes authenticity. CELA addresses the continuity required to trust what happens next.
A valid signature shows that a record is authentic. It does not show that the next state change was authorized, or that the evidence still holds in the context where it is being used. CELA is an architecture for that gap: it ties evidence, its lineage and the authority behind each transition into a record that can be verified independently.
A short introduction to Continuity-Enforced Lineage Architecture.
CELA at a Glance
CONTINUITY AS EVIDENCE
CELA keeps an append-only, signed record of what happened and of who was allowed to make it happen.
Each accepted event is tied to an authenticated source and to its place in a continuous history, so that
a missing, reordered, substituted or rewritten step shows up when the record is verified.
This website is itself signed and can be checked in your browser below.
2
Signatures Required
—
Signed Files Served
4
Operational Modes
0
Servers Needed to Verify
The Security Problem
Authentic is not the same as authorized. A record can carry a perfectly valid signature and still be the wrong record to act on.
Signatures answer one question: were these bytes signed with this key? Systems that act on evidence need more.
Was this the next step in the history, or a replay of an earlier one? Was the source allowed to make this change?
Is the evidence being used in the context it was produced for? Has anything been dropped or substituted along the way?
When those questions go unanswered, valid cryptography can be used to carry stale, replayed or unauthorized state.
The CELA Approach
CELA treats a trust decision as the outcome of four questions, not one:
E
Evidence: what was produced, by which authenticated source
V
Verification: is it intact and correctly signed?
C
Continuity assessment: does it follow from the verified history, without gaps or substitutions?
T
Trust decision: accept, reject or mark as indeterminate, with the reason recorded
Cryptographic integrity underpins every step
Execution authority decides which transitions may happen
This is a conceptual model for explaining the architecture, not a description of internal processing stages.
Continuity
Why each step must follow from the verified history, without gaps or substitutions.
Cryptographic Foundations
HYB
Hybrid Website Signature
Live
Every file this site serves is listed with its SHA-256 in a manifest. The manifest is signed with ECDSA-P256 (FIPS 186-5) and ML-DSA-44 (FIPS 204). Both signatures must verify; a missing post-quantum signature is a failure, not a fallback.
PQC
Why Two Algorithms
ECDSA-P256 is the established classical standard. ML-DSA-44 is NIST's lattice-based signature, designed to stay secure against quantum computers. Requiring both means a forger has to break both.
Ed
Lineage Records
Classical today
CELA's lineage records are signed with classical signatures today. Post-quantum signatures for lineage records are planned.
Signature verification proves who signed. Continuity and authority are what CELA adds on top.
Operational Modes
A mode changes what the system can present. It never relaxes what counts as verified.
REALTIME Mode
Authenticated live sources are present, and new evidence is being recorded.
LINEAGE-ONLY Mode
No live sources. Trust is derived only from the signed history.
FALLBACK Mode
The last verified state is shown and clearly labelled with when it was verified.
DEGRADED Mode
Something is missing, and the system says what, instead of presenting partial evidence as complete.
Capability Status
What exists today, stated plainly:
Hybrid-Signed Website
Live · verifiable below
Tamper-Evident Lineage Records
Implemented · tested
Production rollout in progress.
Independent Verification
Implemented · tested
Records can be re-verified by tools that do not trust the component that produced them.
Authorized Transition Enforcement
Implemented · opt-in
Post-Quantum Lineage Signatures
Planned
Externally Trusted Timestamps
Planned
Limitations
What CELA does not claim:
A valid signature proves that a key was used, not who held it. A compromised credential is resolved by revocation, not by cryptography.
CELA makes recorded history tamper-evident. It does not prove that every event was captured, and it does not detect intrusions on its own.
Timestamps come from the signer's clock, not from an external time authority.
Post-quantum signatures currently protect this website's manifest, not the lineage records.
A compromised majority of authorities can still agree with each other. CELA keeps their decisions attributable; it cannot overrule them.
The applications listed below are potential uses, not existing deployments.
Bitcoin Anchoring
Every hour the newest signed history is timestamped in Bitcoin through OpenTimestamps, and every anchor statement and proof is published by its hash — so anyone can check this site's continuity against the blockchain itself. See the live anchor index →
Threat Model
What CELA does about each class of adversary, including what it does not do:
CRITICAL
Advanced Persistent Actors
Evidence, not prevention: CELA keeps tamper-evident, attributable records of what it ingests, so later changes to that history cannot go unnoticed.
HIGH
Quantum Computing
This site's manifest already carries an ML-DSA-44 signature. Lineage records will follow.
HIGH
Supply Chain
The signed manifest covers every file this site serves. It does not prove how those files were built.
MEDIUM
Impersonation
A source must prove its identity before anything it sends is recorded, and it cannot speak for another source without explicit authority.
MEDIUM
Temporal Attacks
A dropped, reordered or rewritten step breaks the history's continuity and fails verification.
The threat model at a glance.
monartcity.xyz Is Signed by CELA
✓Every served file listed with its SHA-256
✓Classical and post-quantum signatures, both required
✓Verified in your browser, with no backend
✓Signing keys rotate; retired keys stay published
Classical Signature
AlgorithmECDSA-P256 · SHA-256
Signature Size96 base64 chars (70–72-byte DER)
Key IDfrom jwks.json
StandardFIPS 186-5
Post-Quantum Signature
AlgorithmML-DSA-44 (Dilithium2)
Signature Size3,228 base64 chars (2,420 bytes)
Key IDfrom jwks.json
NIST StandardFIPS 204
Public Verification Demonstration
Fetches this site's manifest.json, manifest.sig.json and jwks.json, recomputes the root_hash exactly as the signer does, and verifies both signatures in your browser.
Properties tested: every listed file hash is covered by the manifest; the manifest matches its signed value; ECDSA-P256 and ML-DSA-44 both verify against the published keys; the signature is recent. Limits: this checks the website's own signature. It does not exercise CELA's lineage records or authority controls, and it trusts the keys published on this site.
Try to break it. Each button changes a copy of what was just downloaded, then runs the same checks on the copy.
How root_hash is computed
Site signer: root_hash computation
def manifest_root_hash(manifest: dict) -> str:
"""sha256 of the compact, key-sorted manifest without ``root_hash``."""
body = {k: v for k, v in manifest.items() if k != "root_hash"}
return hashlib.sha256(json.dumps(body, separators=(",", ":"), sort_keys=True).encode()).hexdigest()
ECDSA-P256 check with WebCrypto (cela_verify.js)
cela_verify.js (served at /cela_verify.js)
try {
const key = await webcrypto.subtle.importKey('jwk', { kty: 'EC', crv: 'P-256', x: jwk.x, y: jwk.y, ext: true },
{ name: 'ECDSA', namedCurve: 'P-256' }, false, ['verify']);
const sig = derToP1363(b64decode(classical.signature));
// trigger_daily_signing signs the manifest's own root_hash; it must equal the recomputed one.
const ok = await webcrypto.subtle.verify({ name: 'ECDSA', hash: 'SHA-256' }, key, sig,
new TextEncoder().encode(manifest.root_hash || ''));
add('ECDSA-P256 signature', ok ? VERIFIED : REJECTED,
ok ? 'verifies against ' + classicalKid : 'does not verify against ' + classicalKid);
Overall verdict: never better than the weakest check (cela_verify.js)
cela_verify.js (served at /cela_verify.js)
function overall(checks) {
if (checks.some(c => c.outcome === REJECTED)) return REJECTED;
if (checks.some(c => c.outcome === INDETERMINATE)) return INDETERMINATE;
return VERIFIED;
}
…
const ts = record.timestamp || record.signed_at;
const age = ts ? (Date.now() - Date.parse(ts)) / 3.6e6 : NaN;
add('Signed within ' + freshnessHours + ' h',
Number.isFinite(age) ? (age >= 0 && age < freshnessHours ? VERIFIED : INDETERMINATE) : INDETERMINATE,
Number.isFinite(age) ? 'signed ' + age.toFixed(1) + ' h ago (signer clock, not a trusted timestamp)' : 'no usable timestamp');
return { checks, overall: overall(checks), root_hash: rootHash };
Threat Response Simulator
Pick an attack to see, at a high level, how each protective layer responds, including where a defence depends on people or process. Only the website tamper scenario runs real checks; the others are illustrative.
Defence Summary
Stage 1: Admission & Identity
⏳ Pending
Choose an attack and start the simulation to see how this layer responds.
↓
Stage 2: Integrity Checks
⏳ Pending
Choose an attack and start the simulation to see how this layer responds.
↓
Stage 3: Policy Decision
⏳ Pending
Choose an attack and start the simulation to see how this layer responds.
↓
Stage 4: Response & Evidence
⏳ Pending
Choose an attack and start the simulation to see how this layer responds.
↓
Stage 5: Audit & Recovery
⏳ Pending
Choose an attack and start the simulation to see how this layer responds.
Key Features
Dual Signature
Both ECDSA-P256 and ML-DSA-44 must verify. A missing post-quantum signature is REJECTED.
Freshness
A signature older than 24 h is reported INDETERMINATE, never VERIFIED.
Client Verification
Checked in your browser with WebCrypto and a pinned ML-DSA-44 build. No backend involved.
Every File Covered
The manifest lists the SHA-256 of every served file; verify.html re-hashes each one.
Key Rotation
Signing keys rotate; retired public keys stay published so older signatures can still be checked.
Fail-Closed
Missing or invalid evidence gives REJECTED or INDETERMINATE, never VERIFIED.
Tamper Evidence
A changed byte in a recorded event or a served file fails verification.
Attributable Records
Every recorded event names the authenticated source that produced it.
Independent Verification
Records can be re-verified by tools that do not trust the component that produced them.
Potential Applications
Proposed applications, not current deployments. Today CELA's live public use is this website's signed manifest.
Digital Evidence
Evidence whose chain of custody and every later transformation can be checked, not just its original signature.
AI Systems
Lineage for data, models and automated decisions, so it can be shown which inputs and which authorized changes led to an outcome.
Secure Data Pipelines
Detecting dropped, replayed or substituted records between stages of a pipeline.
Distributed Systems
Attributable, verifiable state transitions across nodes that do not fully trust each other.
High-Assurance Infrastructure
Tamper-evident operational records that can be checked long after the fact, with post-quantum signatures where they matter.
Research & Review
Independent technical assessment of the architecture with academic and institutional partners.
Technical Engagement
Request a Technical Review
For qualified reviewers, institutional partners and prospective adopters. Detailed technical material is shared under agreement after an initial conversation.
Documents
IMPLEMENTED · TESTED · OPEN TO VALIDATION
These documents describe what CELA does today, how it was tested and how you can check it yourself.
They state results, not construction: how each mechanism is built is covered in the restricted
technical edition, which is shared under agreement with reviewers who want to reproduce the work.
CELA v3: Implementation and Validation Brief
Public edition · Version 3 · 29 October 2026
Version 3 of the CELA whitepaper reports the system as built. Each claimed security property is tied to an
implemented control and to the result of adversarial testing against it. Where a guarantee depends on how a
deployment is provisioned, v3 says so and defines an assurance tier instead of claiming it unconditionally.
The brief covers what is implemented, the results below, how the testing was done, the assurance tiers, the
limits of the evidence and how to validate CELA independently.
Live infrastructure monitor. The monitor shows the state of each CELA layer from signed snapshots. While the services run, a new snapshot is published when they start, when their state or the hardware changes, and at least every 5 minutes. It reaches the page within about a minute, without a site update, and your browser checks its signature against this site's published keys before showing it.Live
Hourly Bitcoin anchoring. Every hour while the system is live end to end, the newest signed history is timestamped in Bitcoin through OpenTimestamps. Anchoring pauses while the system is not live, and the monitor says so instead of showing an old anchor as current.Live
Public anchor evidence. Every anchor statement and its proof is published by its SHA-256, with an index, so anyone can download and check them. Each statement names the one before it, so the chain cannot be cut or reordered without the check failing.Live
Open-source anchor verifier. The tool that checks the published anchors from your own machine, released under Apache-2.0. See CELA Anchor Verifier below.Released
Operator view. The operator sees the same live state with host detail in a separate view. Its snapshots are signed and encrypted for the operator; it is not a public page.Operator only
These additions do not change the results in the brief. Bitcoin anchoring shows when each anchored history
existed and that it has not been rewritten since; it does not show that the history was recorded honestly in
the first place.
Validation Results
Security properties claimed in v2 and how they fared in v3 testing:
Property
Result
What the testing showed
Tamper evidence
Validated
Altered records, altered signed fields, wrong keys and malformed signatures were all rejected.
Replay detection
Validated
A genuine identity proof replayed in a new session was rejected, as was authority input without fresh proof.
Rollback resistance
Validated · deployment-scoped
Broken links, regressions and truncation of the history were refused or detected. Against an attacker with full control of the host, this also requires an independent witness off the host (Tier 2).
Deterministic auditability
Validated
The independent auditor verified a clean history and caught every injected gap, overlap, truncation and downgrade.
Traceability across time
Validated
Ordering and provenance hold, and a forged sender identity was kept out of the record. Ordering is by sequence; trusted wall-clock time is a deployment add-on.
Reduced feasibility of hidden persistence
Mechanism validated · deployment-scoped
The independent-verifier gate fails closed when required. The guarantee holds when the gate is required and the witness sits outside the host.
Admission and key-lifecycle integrity
Validated
Unregistered and duplicate sources were refused, and key handling failed closed instead of creating or replacing keys.
Post-quantum lineage signatures
Planned
Not part of v3. Today post-quantum signatures cover the website manifest only.
Method: in-house adversarial testing by the CELA team from a separate attacker host, judged by
the system's own verifiers, with a positive control for every test, in clean-room state with test keys. This is
not a third-party audit. Independent testing is invited below.
Validate It Yourself
Verify this website's signature. Use the in-browser check on the Overview tab, or check the public manifest.json, manifest.sig.json and jwks.json with your own ECDSA-P256 and ML-DSA-44 code.
Act as an outside witness. Keep a copy of lineage_checkpoint.json. It records points in CELA's signed history and is covered by the site signature. The list only grows: every later version must contain your entries unchanged, with counts that only go up. If an entry is dropped or changed, the history was rewritten, and your copy is the evidence.
Check the Bitcoin anchors. Run the open-source CELA Anchor Verifier against this site. It needs nothing from CELA but the published files, and checks the proofs against Bitcoin block headers from a source you choose.
Request a structured review. Reviewers can receive the restricted documents below and arrange to reproduce the validation.
Open source · Apache-2.0 · Python 3.8+, no other packages
The verifier downloads every published anchor statement and proof from this site and checks them on your
machine. Nothing the site publishes is trusted: the index only says where to look, and every file is checked
against its own hash.
git clone https://github.com/Monart-Studio-Ventures/cela-anchor-verifier
cd cela-anchor-verifier
python3 cela-anchor-verify --site https://monartcity.xyz --bitcoin
Published copy: every file matches the hash it is published under, and the newest anchor the live monitor names is in the chain.
Chain: anchors are numbered without gaps and each names the one before it, so none can be removed, replaced or reordered.
Proof: each OpenTimestamps proof belongs to its statement and is confirmed in a Bitcoin block.
Time: each anchored history existed by the block's time.
Freshness: anchoring is still running.
Each result is verified, rejected or not yet checkable. The newest anchor usually waits 1 to 6 hours for its
Bitcoin confirmation, so "not yet checkable" is normal for it. Block headers come from two public Bitcoin
explorers that must agree, or from your own node. A pass shows when each anchored history existed and that the
chain has not been rewritten since; it does not show that the history was recorded honestly in the first place.
Each run is counted when it fetches the anchor index, like any visit; its result stays on your machine.
