[Proposal setup] Proposal title

Please provide your proposal title

Cardano OpenTimestamps Protocol (C-OTS)

[Proposal Summary] Budget Information

Enter the amount of funding you are requesting in ADA

120000

[Proposal Summary] Time

Please specify how many months you expect your project to last

8

[Proposal Summary] Translation Information

Please indicate if your proposal has been auto-translated

No

Original Language

en

[Proposal Summary] Problem Statement

What is the problem you want to solve?

Cardano lacks an open, verifiable way to prove data existed at a given time. Developers rely on ad-hoc or duplicated solutions or centralized tools. A shared layer like Bitcoin OTS is missing.

[Proposal Summary] Supporting Documentation

Supporting links

• https://opentimestamps.org/
,
• https://dgi.io/ots-tutorial/
,
• https://petertodd.org/2016/opentimestamps-announcement

[Proposal Summary] Project Dependencies

Does your project have any dependencies on other organizations, technical or otherwise?

No

Describe any dependencies or write 'No dependencies'

No dependencies

[Proposal Summary] Project Open Source

Will your project's outputs be fully open source?

Yes

Please provide details on the intellectual property (IP) status of your project outputs, including whether they will be released as open source or retained under another licence.

All components- contract, aggregator, SDKs, CLI, proof format, and documentation will be released under the Apache-2.0 License. This permissive license includes explicit patent protection, encourages commercial and institutional adoption, and ensures the entire C-OTS stack remains open, reusable, and safe for long-term integration across the Cardano ecosystem.

[Theme Selection] Theme

Please choose the most relevant theme and tag related to the outcomes of your proposal

Infrastructure

[Campaign Category] Category Questions

Describe what makes your idea innovative compared to what has been previously launched in the market (whether by you or others).

C-OTS introduces a shared, open, and verifiable timestamping layer for Cardano, something the ecosystem does not currently have.

Today, teams embed hashes by buidling one-off mechanisms. This approach is not interoperable, are hard to verify, and waste development effort.

C-OTS is innovative because it:

• Brings the proven OpenTimestamps model to Cardano with a minimal Aiken contract.
• Separates hashing, batching, and anchoring, so no sensitive data touches the chain.
• Provides deterministic, offline-verifiable proofs that do not rely on trusting the aggregator.
• Enables multiple independent aggregators, avoiding centralization.
• Establishes a standard format that any dApp or backend can adopt, preventing duplicated solutions and fragmented tooling.
• This creates a reusable infrastructure layer for proofs of existence, similar to what Bitcoin already benefits from, but missing on Cardano.

Describe what your prototype or MVP will demonstrate, and where it can be accessed.

The MVP will demonstrate the full end-to-end timestamping flow:

• A user submits a salted digest through the CLI, SDK, or API.
• The aggregator batches submissions, builds a Merkle tree, and anchors the root on Cardano via the Aiken contract.
• The user retrieves a proof file containing the digest, Merkle path, and on-chain root.
• A browser-based verifier and CLI tool recompute the root offline and check it against the contract.

The MVP will deliver:

• The deployed Aiken on-chain contract
• A public test aggregator
• CLI tools for stamping and verifying
• JavaScript and Python SDKs
• A web-based verifier
• Documentation and proof-format specification

Everything will be accessible through:

• GitHub (open-source repositories)
• Hosted demo aggregator endpoint
• Public contract address on Cardano testnet

Describe realistic measures of success, ideally with on-chain metrics.

Short-term (MVP period):

• Successful deployment of the C-OTS contract on testnet
• First Merkle roots anchored on-chain (target: at least 50+ root submissions)
• At least 100 timestamp proofs generated and verified through CLI/SDK/web verifier
• Completion of the SDKs (JS + Python) and aggregator reference implementation
• Integration tests showing deterministic proof verification

Medium-term (post-launch):

• Independent teams integrating C-OTS into their workflows (target: 3+ external adopters within the first few months)
• At least 1 independent aggregator operated by a third party
• Steady anchoring activity (e.g., daily or weekly Merkle root submissions)
• Consistent contract usage: a growing count of Merkle roots stored on-chain
• Enterprise SaaS vendors beginning to use C-OTS under the hood to anchor document events, audit logs, or compliance records (e.g., e-signature, certification, and workflow platforms)

Long-term ecosystem metrics:

• Reduction in duplicated timestamping implementations across Catalyst proposals
• Adoption by projects in compliance, audit, enterprise workflows, governance, research, and supply chain
• At least one commercial SaaS product publicly documenting C-OTS for verifiable data integrity
• Proofs remain verifiable offline and independent of any aggregator, ensuring longevity and auditability

[Your Project and Solution] Solution

Please describe your proposed solution and how it addresses the problem

Cardano does not have an open and verifiable method for proving that a piece of data existed at or before a specific point in time. Projects that need proof of existence often embed hashes in transactions, use centralized timestamping services, or build custom one-off mechanisms. These approaches are not interoperable, are hard to verify independently, and do not form a reusable infrastructure layer for the ecosystem.

The Cardano Open Timestamp protocol (C-OTS) provides a simple and reliable timestamping mechanism that any application can adopt.

Core Approach

C-OTS follows the model used by the OpenTimestamps protocol on Bitcoin. A client computes a salted hash of a document locally. The salted digest is submitted to a C-OTS aggregator. The aggregator batches multiple digests, builds a Merkle tree, and publishes the Merkle root to the Cardano blockchain through a minimal Aiken smart contract.

The client receives a proof file containing the salted digest, the Merkle path, and the list of operations needed to recompute the Merkle root. Verification is performed offline by replaying these operations and checking that the derived root matches the value stored on-chain.

This design separates hashing, batching, and anchoring. No document or sensitive data is written to the blockchain. Verification does not depend on the aggregator acting honestly because the proof contains everything required.

How the Solution Addresses the Problem

Reusable timestamping layer

C-OTS provides a standard method for proof of existence. This removes the need for individual projects to develop separate timestamping schemes. Any dApp or backend can adopt the same proof format, contract, and SDKs.

Trust-minimized verification

The aggregator only batches digests and submits a root. Verification involves recomputing the Merkle root from the proof and comparing it with the root stored on-chain. No trust in the aggregator is required.

Privacy by default

Documents are never transmitted. Clients submit only salted digests. The original document cannot be reconstructed from the salted digest.

Minimal on-chain logic

The Aiken contract stores only the Merkle root and the POSIX-time validity range of the transaction that anchored the root. Plutus/Aiken scripts can read the transaction’s validity interval, which defines a POSIX time bound for when the transaction was allowed to be included on-chain. The contract does not store or interpret documents or real-world timestamps.

Independent aggregators

Multiple aggregators can operate independently. Clients may submit digests to several aggregators for redundancy. Each aggregator publishes roots to the same contract.

Deterministic proof format

C-OTS uses an operation-based proof format similar to OpenTimestamps. Each step (hashing, prefixing, Merkle concatenation) is recorded explicitly. This guarantees deterministic and machine-verifiable proofs.

End-to-End Workflow

1. The client hashes the document locally and applies a random salt.
2. The salted digest is sent to one or more aggregators.
3. The aggregator batches digests and constructs a Merkle tree.
4. The aggregator submits the Merkle root to the C-OTS contract in a transaction with a clear POSIX validity interval.
5. The client retrieves the proof file, which contains the salted digest, the Merkle path, the on-chain Merkle root, and the POSIX time bounds (taken from the anchoring transaction).
6. Verification is performed offline by recomputing the root and comparing it with the value stored on-chain.

This process is simple to integrate into any application.

Components Delivered by the Project

Aiken on-chain contract

A minimal Aiken validator that records Merkle roots and reads only the POSIX-time validity interval from the transaction. It checks basic constraints, remains small, and does not validate proofs or build Merkle structures.

Aggregator service

A small batching service that collects digests, builds Merkle trees, generates proofs, and sends roots to the contract.

Proof format specification

A specification for the proof operations so that proof generation and verification remain interoperable across implementations.

CLI tools and SDKs

Command-line tools and SDKs (JavaScript and Python) for stamping documents and verifying proofs.

API endpoints

Submission and retrieval APIs for applications that prefer HTTP interfaces.

Web-based verifier

A browser-based verifier that checks proofs locally without backend dependencies.

Long-Term Ecosystem Value

C-OTS removes duplicated engineering effort across the ecosystem. Projects that require audit trails, research records, supply-chain events, RWA documents, governance logs, and legal evidence benefit from a shared timestamping layer. Without such a layer, teams create isolated or centralized solutions. C-OTS gives Cardano a standard, verifiable timestamping capability similar to Bitcoin’s OpenTimestamps.

Proof Format

C-OTS uses an operation-based proof structure similar to OpenTimestamps. Each operation is listed explicitly, enabling deterministic and independent verification.

On-Chain Contract

The contract stores Merkle roots as script outputs and validates only what is available in the transaction context, including POSIX-time validity bounds and basic structural checks. The design remains minimal and deterministic, reducing cost and complexity.

[Your Project and Solution] Impact

Please define the positive impact your project will have on the wider Cardano community

C-OTS gives Cardano a shared timestamping layer that the ecosystem does not currently have. Many applications need a reliable way to prove that data existed at a specific time, but today each project must build its own method or rely on centralized services. C-OTS provides a single, open, and verifiable approach that any project can use.

Industry Alignment and Enterprise Relevance

Blockchain-anchored timestamping is already used in several real-world services outside Cardano.

• Verisart uses Bitcoin-based OpenTimestamps to anchor art and certificate provenance data.
• Zoho Sign offers blockchain-based document timestamping using OTS under the hood.
• Stampery’s timestamping architecture demonstrates scalable Merkle-based anchoring similar to OTS.

These examples show that blockchain timestamping is already a practical and recognised tool in document integrity and provenance systems. Cardano has no equivalent open timestamping layer, creating a gap for applications that need verifiable data existence.

C-OTS fills this gap by providing a shared, chain-anchored timestamping method for Cardano. It supports industries that rely on long-term data integrity, compliance, certification, audits, governance, and legal workflows and makes Cardano suitable for regulated and data-sensitive environments.

Impact on developers and dApps

• Developers can add timestamping to their applications with one SDK call instead of building custom solutions.
• Projects in supply chain, RWA, governance, research, auditing, NFTs, and digital rights can record data existence in a standard way.
• Verification becomes simple because all proofs follow the same deterministic format.
• Applications do not need to depend on a single company or server; anyone can run an aggregator.

Avoiding duplicate Catalyst spending

• Multiple Catalyst proposals have requested funds to implement their own timestamping systems.
• Without a shared protocol, the ecosystem repeatedly pays for similar functionality.
• C-OTS eliminates this redundancy by providing one standard solution that future projects can reuse.

Ecosystem-level benefits

• Aggregators anchor Merkle roots at regular intervals, creating steady on-chain activity.
• Batching allows thousands of timestamps to be anchored through a single low-cost transaction.
• This creates predictable, recurring transaction volume for the Cardano network.
• A standard timestamping protocol improves compatibility between applications and reduces technical risk.

Long-term platform impact

• Establishes timestamping as a basic infrastructure service, similar to what Bitcoin already provides.
• Lowers development costs across the ecosystem by removing the need for repeated custom implementations.
• Creates a path for cross-chain interoperability with other OTS-based timestamping systems.
• Strengthens Cardano’s core tooling by adding a reliable, verifiable method for data anchoring.

[Your Project and Solution] Capabilities & Feasibility

What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

C-OTS is technically straightforward. It uses well-known components - hashing, salting, Merkle batching, and on-chain root storage, already proven by OpenTimestamps on Bitcoin. The design avoids complexity: no custom consensus, no token mechanics, and no experimental cryptography.

The team is fully capable of delivering this project. Lambdac develops Cardano-focused tooling and smart contracts, with active open-source work in Aiken/Plutus and backend systems. The engineering team has direct experience with Merkle structures, protocol integrations, APIs, and developer tooling. The lead engineer is a Cardano Summit 2025 Hackathon winner (Berlin, Masumi Track).

With three developers covering smart contracts, backend, SDKs, and web verification, and with a tightly scoped, deterministic design, the project is practical, feasible, and well within the team’s technical capacity.

[Milestones] Project Milestones

Milestone Title

Architecture and Contract

Milestone Outputs

1. Full protocol design: hashing rules, salting method, Merkle construction, proof operations, anchoring flow.
2. Initial Aiken contract with basic validation logic and unit tests.
3. Draft of the proof format specification.
4. Public GitHub repository with initial project structure.

Acceptance Criteria

1. Design documents describe all components clearly enough to guide implementation.
2. Aiken contract compiles, passes unit tests, and exposes a clean validator interface.
3. Proof format specification lists every operation required for offline verification.
4. Repository is public and structured for collaborative development.

Evidence of Completion

1. Published design docs, contract source code, tests, and proof-format drafts in GitHub.
2. CI logs confirming successful test runs.
3. Commit history showing active implementation progress.

Delivery Month

1

Cost

20000

Progress

20 %

Milestone Title

Aggregator and Proof Engine

Milestone Outputs

1. Working aggregator service that receives salted digests, batches them, builds Merkle trees, and generates proof files.
2. Support for running multiple independent aggregators.
3. End-to-end stamping flow from digest submission to local verification.

Acceptance Criteria

1. Aggregator collects digests, builds deterministic Merkle trees, and produces valid proofs.
2. Multiple aggregator instances operate independently without conflicts.
3. Full stamping and verification flow completes successfully and reproducibly.

Evidence of Completion

1. Aggregator and proof-engine source code in the repository.
2. Test logs showing batch creation, Merkle roots, and successful proof verification.
3. Documentation showing multi-aggregator configuration and operation.

Delivery Month

3

Cost

25000

Progress

40 %

Milestone Title

API, CLI, and SDKs

Milestone Outputs

1. REST API for submitting digests and retrieving proofs.
2. CLI tool for stamping and verifying documents locally.
3. JavaScript and Python SDKs for easy integration.
4. Example integrations for dApps and backend systems.

Acceptance Criteria

1. API responds correctly for all defined operations.
2. CLI tool works reliably across platforms.
3. SDKs provide stable, well-documented methods for stamping and verification.
4. Example apps demonstrate successful integration.

Evidence of Completion

1. API documentation and example API calls (Postman/curl).
2. CLI binaries or scripts and usage examples.
3. SDK packages and source code.
4. Test logs and sample proof files showing correct behavior.

Delivery Month

5

Cost

25000

Progress

60 %

Milestone Title

Mainnet Deployment and Web Verifier

Milestone Outputs

1. Deployment of the Aiken contract to mainnet with full documentation.
2. Client-side web verifier capable of verifying proofs entirely in the browser.
3. Second aggregator instance deployed as a reference implementation.
4. Integration tests conducted with partner projects.

Acceptance Criteria

1. Mainnet contract address published and functional for anchoring Merkle roots.
2. Web verifier loads proofs, replays operations, and matches on-chain roots.
3. Second aggregator generates proofs fully compatible with the primary instance.
4. Partner projects successfully integrate using the SDKs.

Evidence of Completion

1. Mainnet transactions showing successful root submissions.
2. Public link to the web verifier and sample proofs.
3. Integration test logs and results from both aggregators.
4. Documentation describing contract usage and verifier instructions.

Delivery Month

6

Cost

25000

Progress

80 %

Milestone Title

QA, Open Security Review, and Launch

Milestone Outputs

1. Full QA review of all components across aggregator, SDKs, API, CLI, verifier, and contract.
2. Open, community-based security review of the contract and aggregator logic (public issue review, peer inspection, and external contributions).
3. Load-testing results demonstrating aggregator stability under high throughput.
4. Final documentation, tutorials, and a complete project report with roadmap.

Acceptance Criteria

1. All components behave consistently across repeated QA runs.
2. Open security review identifies no critical issues; any findings are addressed publicly through GitHub issues and patches.
3. Aggregator remains stable under high-volume load tests.
4. Documentation and tutorials are complete, accurate, and published in the open repository.

Evidence of Completion

1. QA and peer-review notes, GitHub issues, merged fixes, and review summaries.
2. Load-testing logs and performance graphs.
3. Final documentation, tutorials, and roadmap published in the repository.
4. Public release notes confirming launch readiness.

Delivery Month

8

Cost

25000

Progress

100 %

[Final Pitch] Budget & Costs

Please provide a cost breakdown of the proposed work and resources

The total budget requested is ₳120,000, which supports an eight-month development cycle with three engineers working across smart contracts, backend systems, SDKs, and verification tooling. The project remains lean by reusing proven OpenTimestamps concepts and keeping all components minimal and deterministic.

Smart contract development and review (₳18,000)

Covers design and implementation of the Aiken validator, full test coverage, and a targeted security review.

Aggregator and proof engine (₳24,000)

Funds development of the batching logic, deterministic Merkle construction, proof generation, and multi-aggregator support.

Backend API and services (₳18,000)

Implements digest submission endpoints, proof retrieval, service orchestration, and operational backend logic.

CLI tools and SDKs (₳20,000)

Provides a command-line tool, JavaScript and Python SDKs, and sample integrations for applications to adopt the protocol easily.

Web-based verifier (₳12,000)

Develops a browser-only verifier that can replay proofs and validate Merkle roots without backend dependencies.

Documentation and integration examples (₳8,000)

Includes developer documentation, protocol specification, API guides, and example usage patterns.

Quality assurance and internal security review (₳10,000)

Supports test automation, load testing for aggregator behaviour, and an internal protocol review.

DevOps, hosting, and maintenance for 8 months (₳10,000)

Covers hosting, monitoring, CI/CD, and maintaining the aggregator and public endpoints through the build and launch period.

This budget supports an 8-month, 3-developer delivery while staying lean and engineering-focused:

• The smart contract is intentionally minimal → lower audit cost.
• Aggregator and proof engine remain the largest component but optimized.
• API + CLI + SDKs share common verification logic → reduced effort.
• Web verifier is kept simple (client-side verification only).
• Documentation is concise but complete.
• QA and security review scaled appropriately for a deterministic, low-risk protocol.
• Hosting costs minimized via lightweight infra + stateless components → low hosting/DevOps cost.

The total of ₳120,000 reflects a realistic and efficient budget for delivering a complete, production-ready timestamping protocol for the Cardano ecosystem.

[Final Pitch] Value for Money

How does the cost of the project represent value for the Cardano ecosystem?

C-OTS delivers a shared, open-source timestamping layer that the Cardano ecosystem currently lacks. Without it, multiple Catalyst projects are forced to build their own isolated timestamping solutions, leading to duplicated spending and incompatible approaches. A single, standard protocol avoids this waste, reduces long-term maintenance costs, and gives all developers a consistent verification method.

The design is intentionally minimal: deterministic hashing, Merkle batching, simple proof operations, and a lightweight Aiken contract. This keeps development, auditing, and operational costs low while still providing a durable, trust-minimized foundation suitable for long-term use across the ecosystem.

Other chains already benefit from similar infrastructure. Services like Verisart, Zoho Sign, and Stampery use Bitcoin’s OpenTimestamps as a backend for proof-of-existence because it is open-source, simple, and cost-efficient. C-OTS gives Cardano the same capability and positions it as an alternative timestamping backend that external companies and integrators can anchor to, generating recurring on-chain activity at very low protocol cost.

With one well-scoped project, Cardano gains a proven utility that reduces future treasury expenditure, strengthens the developer toolchain, and creates a clear path for timestamp-heavy applications to build on the network.

[Self-Assessment] Self-Assessment Checklist

I confirm that evidence of prior research, whitepaper, design, or proof-of-concept is provided.

Yes

I confirm that the proposal includes ecosystem research and uses the findings to either (a) justify its uniqueness over existing solutions or (b) demonstrate the value of its novel approach.

Yes

I confirm that the proposal demonstrates technical capability via verifiable in-house talent or a confirmed development partner (GitHub, LinkedIn, portfolio, etc.)

Yes

I confirm that the proposer and all team members are in good standing with prior Catalyst projects.

Yes

I confirm that the proposal clearly defines the problem and the value of the on-chain utility.

Yes

I confirm that the primary goal of the proposal is a working prototype deployed on at least a Cardano testnet.

Yes

I confirm that the proposal outlines a credible and clear technical plan and architecture.

Yes

I confirm that the budget and timeline (≤ 12 months) are realistic for the proposed work.

Yes

I confirm that the proposal includes a community engagement and feedback plan to amplify prototype adoption with the Cardano ecosystem.

Yes

I confirm that the budget is for future development only; excludes retroactive funding, incentives, giveaways, re-granting, or sub-treasuries.

Yes

[Required Acknowledgements] Consent & Confirmation

I Agree

Yes