Ratna

Project Stash Vault

Engineering archive shaped for long-horizon work, not short-term portfolio churn.

Vault 01 / Aerospace

Case file / 2026

Featured case file

Satellite SLA Marketplace

An on-chain marketplace for satellite imaging tasks where requesters fund capture jobs, operators bond execution commitments, and escrow settles against verifiable SLA outcomes.

Recommended starting point for the aerospace archive.

View Repo

Next.jsTypeScriptFoundrySolidityGoIPFSDocker

#satellite tasking#escrow#sla verification#mission operations

20-second project scan

What to understand first

A fast scan for recruiters and engineers: ownership, technical depth, proof status, and current outcome in one place.

Problem, solution, and system shape

The project framed as a system: the problem, the solution boundary, and the architecture choices that make the implementation credible.

Problem

Satellite capture agreements are not just procurement records; they are timing-sensitive operational commitments with real failure modes. If requirements, evidence, and payment logic are loosely managed, it becomes hard to prove whether an operator actually met the task or whether a requester is justified in disputing delivery. This project is interesting because it turns an aerospace coordination problem into a system with explicit trust boundaries across contracts, storage, verification, and operator-facing workflows.

Solution

Satellite SLA Marketplace is a full-stack tasking system for remote-sensing work that needs stronger accountability than email, PDFs, and manual payment flows can provide. The platform treats an imaging request as a contract-backed operational workflow: a requester publishes mission requirements, an operator commits with bonded collateral, artifacts and manifests are anchored through IPFS, and a verifier service can evaluate delivery evidence before escrow settles or a dispute path is opened.

Architecture

The contract surface is intentionally narrow: it owns listings, accepted task agreements, bonded commitments, escrow state, and dispute transitions, while heavier evidence handling stays off-chain.

IPFS is used as the artifact plane for manifests, evidence packages, and dispute materials so task history remains auditable without turning the chain into a storage layer.

Technical highlights

Where the engineering depth shows up

The implementation details a technical reviewer should notice before reading the full case file.

Highlight 01

The contract surface is intentionally narrow: it owns listings, accepted task agreements, bonded commitments, escrow state, and dispute transitions, while heavier evidence handling stays off-chain.

Highlight 02

Highlight 03

Built the local development flow around Foundry deployment, contract testing, ABI export, and frontend sync so the smart-contract and UI layers do not drift apart during iteration.

Highlight 04

Kept the verifier logic in Go rather than embedding all delivery logic on-chain; that makes proof evaluation extensible while preserving a clear on-chain source of truth for financial state.

Platform layers

How the system is composed

A layer-by-layer view of the components that make the system work together, from contract state and verification boundaries to the operator-facing product surface.

Layer 01

3 surfaces

Contract layer

Foundry-based contracts model listings, funded task agreements, operator bonding, escrow release, and dispute transitions so the economic state of a capture task is explicit and inspectable.

SolidityFoundryEscrow lifecycle

Layer 02

3 surfaces

Verifier service

A Go verification service watches task state, resolves manifests, and exposes extensible proof hooks so delivery checks can evolve without rewriting the contract surface.

GoVerification hooksTask evaluation

Layer 03

3 surfaces

Artifact and manifest layer

IPFS is used for task manifests, evidence payloads, and supporting dispute artifacts so the chain stores commitments and identifiers while bulk evidence remains portable.

IPFSArtifact manifestsContent addressing

Layer 04

3 surfaces

Requester and operator console

A Next.js frontend provides wallet-connected flows for publishing tasks, bonding commitments, reviewing evidence, and stepping through settlement or dispute states without hiding the underlying contract model.

Next.jsTypeScriptWallet UI

Layer 05

4 surfaces

Developer workflow

A Docker-based local stack, contract deployment scripts, ABI export flow, and CI/CD checks keep the project usable as an engineering system rather than a one-off prototype.

DockerABI exportTestingCI/CD

Proof surface

Artifacts, references, and public access points

Ready links and planned proof artifacts are shown together so reviewers can distinguish published evidence from reserved case-study slots.

Repository

Available

GitHub repository

Public source code, implementation structure, and current engineering baseline.

View Repo

Diagram

Planned

Marketplace lifecycle diagram

Reserved for the end-to-end flow covering request publication, operator bonding, artifact submission, verification, escrow release, and dispute escalation.

Reserved for future publication once the supporting material is ready.

Trace

Planned

Verifier hook sequence

Reserved for a service-level trace showing how a delivery package is resolved from IPFS, evaluated, and reflected back into contract state.

Reserved for future publication once the supporting material is ready.

Walkthrough

Planned

Wallet-connected operator walkthrough

Reserved for a short demo pass through task acceptance, bond placement, delivery submission, and settlement review in the frontend.

Reserved for future publication once the supporting material is ready.

Capture

Planned

Contract and ABI export capture

Reserved for the local developer flow covering deploy, test, ABI export, and frontend synchronization.

Reserved for future publication once the supporting material is ready.

System view

Architecture and implementation

The architectural boundaries and implementation choices that make the system coherent, maintainable, and operationally meaningful.

Architecture

The contract surface is intentionally narrow: it owns listings, accepted task agreements, bonded commitments, escrow state, and dispute transitions, while heavier evidence handling stays off-chain.

IPFS is used as the artifact plane for manifests, evidence packages, and dispute materials so task history remains auditable without turning the chain into a storage layer.

The frontend mirrors the underlying workflow instead of abstracting it away: request creation, operator commitment, delivery submission, verification, settlement, and dispute all map to explicit state changes.

Implementation Notes

Built the local development flow around Foundry deployment, contract testing, ABI export, and frontend sync so the smart-contract and UI layers do not drift apart during iteration.

Kept the verifier logic in Go rather than embedding all delivery logic on-chain; that makes proof evaluation extensible while preserving a clear on-chain source of truth for financial state.

Used Docker to make the stack repeatable for contracts, frontend, and service dependencies instead of relying on undocumented local setup.

Structured the project for CI/CD from the start so deploy, test, and interface-export steps can be automated rather than treated as manual release chores.

Metrics and outcomes

What is proven so far

Honest status, proof readiness, and results. Qualitative markers are used where exact production metrics are not available yet.

Status

Live Prototype

Current maturity of the project record.

Proof

Repo available

Public source code, implementation structure, and current engineering baseline.

Architecture

4 notes

Documented architecture decisions and boundaries.

Outcomes

This is the strongest example in the vault of aerospace work that genuinely benefits from programmable trust without collapsing into generic web3 product language.

It shows how contracts, verification services, storage, and operator-facing UI can cooperate around a real mission-tasking problem instead of existing as disconnected technical demos.

The project is ready to support deeper case-study material because the architecture, local workflow, and boundary decisions are already concrete.

Future Work

Add richer verifier modules for domain-specific SLA policies, including extensible proof adapters for different capture and delivery requirements.

Expand the dispute path with reviewer workflows, clearer evidence presentation, and operator/requester history views.

Harden the demo surface with richer task templates, wallet-state guidance, and publishable walkthrough assets once the flows are finalized.

Related entries

More from the aerospace vault

Vault 01 / 2026

Telemetry Attestation Rail

Research Track

A provenance rail for mission telemetry that signs critical state changes and preserves an auditable path from raw data to reviewable findings.

Built

Provenance model design, ingestion pipeline architecture, and workflow definition for anomaly review and downstream verification.

In mission environments, raw data alone is not enough. Teams need to know what record was observed, who processed it, what changed later, and whether a conclusion can be defended under review.

Strongest proof

Diagram planned

Planned

PythonFastAPIKafkaClickHouseSolidity

#telemetry#provenance#verification#mission assurance

View ProjectView Repo

Internal case file is live; public repo is not linked yet.

Vault 01 / 2025

Launch Window Planner

Live Prototype

A readiness and scheduling console for launch campaigns with typed constraint tracking, timeline visibility, and operator handoff context.

Built

State-model design, timeline interaction design, and architecture direction for a multi-team operational planning surface.

Launch work is often constrained by fragmented operational state. A good planning tool reduces ambiguity at the exact moment teams need to reason across dependencies, not inside isolated discipline dashboards.

Strongest proof

Capture planned

Planned

Next.jsTypeScriptNode.jsTailwindOpenTelemetry

#launch operations#constraint tracking#timeline UI#coordination

View ProjectView Repo

Internal case file is live; public repo is not linked yet.