Open Grant Proposal: SwissTokint Retrievable Proof Batches

# Open Grant Proposal: Retrievable Merkle Evidence Bundles for Financial Agents

**Project Name:** SwissTokint Retrievable Proof Batches

**Proposal Category:** `Developer and data tooling`

**Individual or Entity Name:** Mehdi Mauroux, individual applicant leading the SwissTokint two-person project team. The grant agreement and payments would use the same applicant unless the Filecoin grants team approves an eligible project entity before contracting.

**Proposer:** `SwissTokint`

**Project Repo(s):**

- https://github.com/SwissTokint/swisstokint-open-risk-infrastructure

**Filecoin ecosystem affiliations:** None.

**Technical Sponsor:** None yet.

**Do you agree to open source all grant-funded work under the MIT/Apache-2 dual licence?:** Yes.

# Project Summary

Autonomous financial agents can emit thousands of events, but publishing full audit logs can expose proprietary methods, account information and unnecessary personal data. SwissTokint has already implemented an open Receipt v0.2 format that keeps raw event payloads local, signs compact method and policy commitments, and batches receipts into deterministic Merkle roots with cross-language inclusion proofs.

This grant would add a Filecoin-native, selectively disclosed evidence layer for those high-frequency batches. The project will package encrypted or public evidence objects into deterministic CAR archives, store the archives through current Filecoin storage tooling, link each Filecoin content identifier to the corresponding Merkle batch manifest, and provide an independent availability verifier. A reviewer can prove that a receipt belongs to an anchored batch, retrieve only the evidence authorised for that mandate and verify integrity without downloading or exposing the complete strategy dataset.

The proposed deliverable is not a generic agent-reasoning archive and does not store exchange credentials, balances or complete trading instructions. Its Filecoin-specific contribution is a reproducible batching, retrieval and availability-verification profile for many small, privacy-sensitive proofs.

## Impact

High-frequency proof receipts are individually small and expensive to store as separate deals. Simply placing a JSON log on IPFS does not define how thousands of receipts map to an economic storage object, how an inclusion proof links a receipt to that object, or how a reviewer detects that required evidence has become unavailable.

Getting this right creates a reusable Filecoin workload for financial agents, risk engines, DAO automation and other systems that need selective audit evidence. The benefits are:

- economically sized deterministic bundles rather than one deal per event;
- a portable map from receipt → Merkle root → evidence manifest → Filecoin CID;
- independent retrieval and integrity checks;
- privacy-preserving selective disclosure;
- explicit availability status instead of assuming that a content address remains retrievable.

Success means a third party can generate 100,000 synthetic receipts, build the same Merkle root in TypeScript and Python, retrieve an authorised evidence object from Filecoin test infrastructure, verify inclusion and fail safely when data, signature or path is altered.

## Outcomes

1. **Deterministic Evidence Bundle v0.1 specification.** Canonical manifest, CAR layout, encryption metadata boundary, Merkle mapping, content identifiers, retention fields and error semantics.
2. **TypeScript and Python Filecoin adapters.** Bundle, upload, retrieve and verify high-frequency receipt evidence without changing the public Receipt v0.2 core.
3. **Availability verifier CLI.** Given a receipt, inclusion proof and batch manifest, verify the root, retrieve the authorised object, re-derive its CID and return machine-readable `AVAILABLE`, `UNAVAILABLE` or `INVALID` results.
4. **Retrieval sampling and benchmark harness.** Configurable probes for 1k/10k/100k receipt batches; measurements for bundle size, upload/retrieval latency, verification cost and failure behaviour.
5. **Public CI and reproducible documentation.** Testnet integration, tamper/unavailability fixtures, an operator guide and a third-party reproduction report.

Success metrics:

- deterministic parity across TypeScript and Python for every reference fixture;
- 100,000 synthetic receipts processed in the benchmark;
- successful retrieval and verification of every authorised reference fixture;
- every tampered CID, manifest, receipt and Merkle path rejected;
- one third party reproduces the workflow using only public documentation;
- no exchange secret, balance, private key, direct personal identifier or raw strategy parameter in a public manifest.

## Data Onboarding

The grant is a developer-tooling and testnet integration project. Figures below are bounded estimates, not production commitments:

- Month 1: under 1 GiB of fixtures and synthetic bundles;
- Month 3: 5–20 GiB of repeated batch, failure and retrieval tests;
- Month 6: 20–100 GiB depending on benchmark repetitions and pilot consent;
- Month 12: post-grant usage depends on external integrations and is not claimed as a grant deliverable.

## Adoption, Reach, and Growth Strategies

The initial users are bot developers, financial-agent teams, treasury automation projects and reviewers who need tamper-evident evidence without exposing complete logs. The public SwissTokint SDK and Docker relay provide the first reference integration.

The first ten users will be recruited through direct design-partner interviews and open-source integrations. The first 100 users will be addressed through packaged SDK releases, a five-minute local verifier example, a Filecoin-specific integration guide and reference adapters reusable outside SwissTokint. Synthetic, internal, external and paid usage will be reported separately.

## Development Roadmap

Assumed project start: **1 October 2026**, subject to a signed grant agreement. Dates will be re-baselined with the grants team if contracting completes later.

### Milestone 1 — specification and deterministic local bundle toolchain

**Completion:** 15 November 2026
**People:** two-person SwissTokint core team; Mehdi Mauroux accountable for delivery
**Funding:** USD 14,500

Deliverables:

- Evidence Bundle v0.1 specification and JSON schemas;
- deterministic CAR/manifest builder in TypeScript and Python;
- privacy and threat-model extension;
- reference fixtures for 1k and 10k receipt batches;
- CI tests for parity, tampering and forbidden fields.

### Milestone 2 — Filecoin upload, retrieval and availability verification

**Completion:** 15 January 2027
**People:** two-person core team plus bounded external technical review
**Funding:** USD 20,000

Deliverables:

- current Filecoin storage-tooling adapter on test infrastructure;
- CID-to-batch manifest mapping;
- selective retrieval flow;
- standalone availability verifier CLI;
- retry, timeout, error and unavailable-data semantics;
- testnet integration tests in public CI.

### Milestone 3 — scale benchmark, independent reproduction and release

**Completion:** 15 March 2027
**People:** two-person core team and one independent reproducer/reviewer
**Funding:** USD 15,000

Deliverables:

- 1k/10k/100k receipt benchmark harness;
- measured bundle, upload, retrieval and verification results;
- third-party reproduction report;
- versioned SDK release and operator documentation;
- final technical and maintenance report.

## Total Budget Requested

| Milestone # | Description | Deliverables | Completion Date | Funding |
|---|---|---|---|---:|
| 1 | Deterministic bundle core | Spec, schemas, TS/Python builder, fixtures, privacy tests | 15 Nov 2026 | USD 14,500 |
| 2 | Filecoin integration | Upload/retrieve adapter, manifest mapping, availability CLI, testnet CI | 15 Jan 2027 | USD 20,000 |
| 3 | Scale and release | 100k benchmark, independent reproduction, releases and docs | 15 Mar 2027 | USD 15,000 |
| | | | **Total** | **USD 49,500** |

## Maintenance and Upgrade Plans

Grant-funded code will live in the public SwissTokint repository under the agreed dual licence. The receipt protocol keeps storage adapters behind a versioned interface so Filecoin SDK changes do not alter historic receipts. SwissTokint will maintain security reporting, compatibility tests and release notes for at least 24 months after the final milestone. Breaking changes require a new schema version and migration guide.

# Team

## Team Members

- **Mehdi Mauroux** — project lead and accountable grant applicant.
- **Second core contributor** — identity, role, consented professional profile and time commitment will be supplied privately before contracting; no public profile is included without consent.

## Team Member LinkedIn Profiles

- To be provided in the private diligence annex with the contributors' consent.

## Team Website

https://swisstokint.ch

## Relevant Experience

The team has built and publicly released the current Receipt v0.2 reference stack: deterministic TypeScript and Python implementations, cross-language fixtures, Ed25519 verification, Merkle batch and inclusion proofs, a Docker relay, a risk-rule engine, CI and a written threat model. The proposal does not claim prior Filecoin production deployment; Filecoin integration is the grant-funded work.

## Team code repositories

- https://github.com/SwissTokint/swisstokint-open-risk-infrastructure

# Additional Information

- **How did you learn about the Open Grants Program?** Through public research into current open-source infrastructure funding routes.
- **Best email for grant discussion:** contact@swisstokint.ch
- **Competitive-overlap disclosure:** Filecoin issue #2155 proposes general AI-agent audit-trail storage. SwissTokint's proposed scope is a complementary high-frequency receipt-batching, selective-disclosure and retrievability-verification profile. We welcome the grants team's direction if this belongs as collaboration, a narrower module or a non-overlapping RFP.
- **No work before contract:** SwissTokint will not treat the grant as approved or begin grant-funded Filecoin work until both parties sign the agreement.

The proposal points to the SwissTokint open-risk-infrastructure repository but names no target files or tests. Start by reviewing the existing Receipt v0.2 TypeScript and Python implementations, Docker relay, CI, and threat model described in the issue. Done would require the three roadmap milestones: deterministic bundles, Filecoin retrieval and availability verification, benchmarks, documentation, and reproducible CI results.

Written by the indexing model from the issue text.