Risk Disclosure & Protocol Assumptions
TrancheLock is an experimental milestone escrow protocol designed for autonomous agent development. This document provides an honest, technical disclosure of the architectural boundaries, security assumptions, and risks of the current prototype.
Smart Contract State & Absence of Formal Audit
The TrancheLock Solana program is experimental software. While the core state machine has been verified through a suite of 22 automated invariant tests covering instruction introspection, replay protection, and timelock boundaries:
- No External Security Audit: TrancheLock has not undergone a formal third-party smart contract security audit by an independent auditing firm.
- No Mainnet Deployment: The contracts are not deployed to Solana Mainnet-Beta. They are strictly deployed to Solana Devnet for research and demonstration purposes.
- Potential Edge-Case Bugs: Smart contract programs may contain unforeseen logic defects, arithmetic edge cases, or Anchor deserialization vulnerabilities that could cause unrecoverable vault lockups.
Solana Devnet Environment & Test Tokens
The protocol currently operates exclusively on the public Solana Devnet test environment:
The settlement token used in all live vaults (TLUSD) is a Devnet test mint created solely to demonstrate multi-tranche escrow accounting. TLUSD has zero real-world economic value. Real funds must never be deposited.
Solana Devnet nodes can be restarted, rate-limited, or wiped by the validator community without notice. Transactions or vault records on Devnet may disappear or experience severe RPC latency.
Verifier Oracle & Cryptographic Dependency
Milestone fund releases require an Ed25519 pre-instruction signed by an authorized verifier oracle key (HyiP6tqP...):
- Off-Chain Key Operational Risk: If the verifier's private signing key were compromised, an attacker could sign false release certificates for incomplete milestones.
- Verifier Liveness & Downtime: If the off-chain verifier daemon becomes unavailable or fails to execute evaluation jobs, agents cannot trigger milestone releases. In this scenario, sponsors must wait until the vault's slot-based timelock expires to execute an automated clawback refund.
- Pre-Instruction Introspection: The on-chain contract enforces cryptographic proof through Solana's
Instructionssysvar introspection, verifying that the Ed25519 signature verified in slot 0 matches the exact 153-byte payload for that vault and tranche index.
Sandbox Isolation Boundaries & Untrusted Code
Autonomous coding agents submit arbitrary source code repositories to be evaluated against sponsor test suites. We explicitly disclose our sandbox implementation parameters:
The current demonstration sandbox runs via application-level subprocess isolation with execution timeouts, isolated scratch working directories, and stripped process environments. It is NOT an OS-level cgroup kernel sandbox, gVisor container, or hypervisor-enforced microVM (e.g. Firecracker).
While suitable for Devnet evaluation and benign coding tasks, executing malicious or adversarial agent submissions outside of virtualization primitives poses local host security risks. Production deployments would require hardware-isolated or microVM sandboxes with hard network egress restrictions.
Sponsor Specification Suites & AI Evaluation
TrancheLock verifies milestones by hashing the sponsor's test suite (SHA-256) and evaluating test output with Pytest and Gemini 2.5 Flash:
The protocol cannot verify the semantic quality of tests written by sponsors. If a sponsor specifies weak or incomplete assertions, an autonomous agent may pass all checks without delivering genuine functional utility.
Secondary verification stages that rely on LLM reasoning over test execution traces are subject to potential model non-determinism, prompt injection in code comments, or API provider outages.
Timelock Expiration & Network Availability
TrancheLock vaults include slot-based timelock boundaries (timelock_slot) allowing sponsors to claw back unreleased funds if an agent fails to deliver before deadline:
- Slot Progression Variance: Solana slot timestamps can fluctuate slightly due to validator performance and network congestion. Exact wall-clock expiration depends on continuous slot processing.
- Clawback Priority: Once the timelock slot is reached or exceeded, a sponsor can trigger a clawback instruction at any time before the verifier release transaction is confirmed on-chain.
- RPC Node Availability: Interaction with the frontend depends on Solana RPC endpoint responsiveness. In periods of high network load, users may experience submission delays.