RFP ID
RFP-017 — Privacy-Preserving Token Vesting
Your Project Name
VeilVesting
Team or Organization Name
Independent
Primary Contact
akiranakao.dev@gmail.com
Team Members
Akira Nakao
Role:: Developer / Engineer / Architect
Status: Full-time independent contributor
Github: https://github.com/supersmile0426
Linkedin: https://www.linkedin.com/in/akira-n-a27a7a406/
Website:https://akira-nakao.netlify.app/
Senior software engineer and architect with experience across Web3, distributed backend systems, and full-stack product development.
Relevant technical experience includes Rust, Solidity, DeFi and smart-contract integrations, wallet and blockchain APIs, TypeScript/Node.js, Python, PostgreSQL, Docker, Kubernetes, AWS, CI/CD, automated testing, and production operations.
For VeilVesting I will directly own protocol architecture, LEZ/SPEL development, SDK and CLI implementation, frontend integration, testing, CI/CD, deployment, and documentation.
An independent security reviewer will be engaged before mainnet deployment.
Project Summary
VeilVesting is a privacy-preserving token vesting protocol for the Logos Execution Zone.
The goal is to combine publicly verifiable vesting commitments with private post-claim token ownership.
The protocol will support:
- cliff + linear vesting;
- fully linear vesting;
- milestone-based vesting;
- cancelable and permanently non-cancelable schedules;
- optionally transferable beneficiary rights;
- multi-recipient batch creation;
- public claims;
- private/shielded claims;
- SDK and CLI tooling;
- a Basecamp-compatible mini-app;
- structured lifecycle events;
- automated testing, CI, and deployment workflows.
The important privacy boundary is deliberate: vesting terms, beneficiary, token allocation, and claimed amounts remain publicly auditable, while a beneficiary may choose to receive vested assets into a private account so that subsequent token movements are not exposed as part of the same public financial graph.
This matters because token vesting is foundational infrastructure for token launches, contributor compensation, ecosystem grants, investor allocations, and incentive programs.
VeilVesting would provide reusable LEZ infrastructure for these use cases while adding a privacy property that conventional transparent vesting contracts do not provide.
Technical Approach
VeilVesting will be structured into five main layers:
- LEZ/SPEL vesting program
- Token custody and transfer adapter
- SDK and IDL
- CLI and developer tooling
- Basecamp-compatible mini-app
Vesting State
Each schedule will track the minimum deterministic state required for secure execution, including:
- creator;
- beneficiary;
- token;
- total allocation;
- claimed amount;
- schedule type;
- start, cliff, and end times;
- cancellation state;
- transferability;
- cancellation authority;
- milestone authority and milestone state.
The exact representation will follow current LEZ/SPEL account and serialization requirements.
Vesting Types
The implementation will support:
Cliff + Linear: nothing vests before the cliff, followed by linear vesting until the end.
Fully Linear: continuous vesting from start to end without a cliff.
Milestone-Based: predefined tranches are unlocked by an authorized milestone signer. A milestone can only transition once and cannot release the same allocation twice.
The fundamental claim invariant will be:
claimable = min(vested_amount(current_time), total_amount) - claimed_amount
with:
0 <= claimed_amount <= vested_amount <= total_amount
All arithmetic will use deterministic integer calculations with explicitly documented rounding behavior.
Cancellation
Cancelable schedules may be irreversibly converted into non-cancelable schedules.
When a schedule is cancelled:
- vested but unclaimed tokens remain claimable by the beneficiary;
- unvested tokens return to the creator.
Cancellation and token movement will be designed atomically so failed operations cannot leave token balances and vesting state inconsistent.
Beneficiary Transfer
Transferability will be configured at schedule creation.
When enabled, the current beneficiary may transfer the position to another public beneficiary. When disabled, transfer attempts will fail.
Transferability itself will not become mutable after schedule creation.
Public and Private Claims
VeilVesting will support separate public and private claim paths.
For private claims, the SDK will validate that the destination satisfies current LEZ private/shielded-account requirements.
The private destination will not be persisted as public vesting state.
The public chain will continue to expose the vesting commitment and claimed amount, but not the receiving private account or subsequent private token activity.
The mini-app will clearly explain this privacy boundary rather than presenting the mechanism as complete beneficiary anonymity.
LEZ Integration and Dependencies
The current RFP identifies token transfer-authority functionality as an important dependency for escrow and payouts.
I will validate the current LEZ implementation directly rather than assume that the RFP description exactly reflects the latest runtime behavior.
The token custody layer will therefore be isolated behind a narrow interface.
The vesting state machine, arithmetic, lifecycle rules, events, SDK interfaces, CLI architecture, test vectors, CI, and frontend workflows can be developed independently of changes to the underlying custody mechanism.
Where current LEZ token/PDA functionality already provides the necessary authority model, it will be documented and verified before integration. If an upstream primitive is still required, final custody integration will use the supported mechanism once available.
Events
Structured events will cover at least:
ScheduleCreatedTokensClaimedScheduleCancelledMilestoneSignalledBeneficiaryTransferred
SDK
The SDK will expose the complete lifecycle, including:
- create schedule;
- create batch;
- query schedule;
- calculate claimable amount;
- public claim;
- private claim;
- cancellation;
- permanent cancellation lock;
- milestone signalling;
- beneficiary transfer;
- event parsing.
CLI
The CLI will expose equivalent operations for developers and operators, with human-readable errors and reproducible commands.
Basecamp Mini-App
The beneficiary interface will allow users to:
- view schedules;
- inspect vested and claimable balances;
- see the next unlock;
- choose public/private claims;
- review privacy implications;
- submit transactions.
The creator interface will support:
- schedule creation;
- batch creation;
- cancellation configuration;
- authority configuration;
- milestone signalling;
- cancellation;
- beneficiary-management workflows.
Testing and Security
Testing will include:
- unit tests;
- boundary-value tests;
- invariant/property tests;
- integration tests;
- LEZ sequencer E2E tests;
- negative/error-path tests;
- deployment verification.
Important invariants include:
- claimed amount can never exceed vested amount;
- vested amount can never exceed the total allocation;
- failed transfers cannot consume claimable balance;
- milestones cannot unlock twice;
- cancellation cannot revoke already vested tokens;
- non-cancelable schedules cannot become cancelable;
- beneficiary transfers cannot modify vesting economics;
- invalid private destinations are rejected.
Compute/cycle usage will also be measured for creation, claims, cancellation, milestone signalling, beneficiary transfer, and batch operations.
Fee Model
The initial protocol fee will be 0%.
No additional protocol fee will be charged to beneficiaries for claiming vested tokens.
Milestones, Payout and Timeline
Milestone 1 — Architecture, LEZ Validation and Vesting Kernel
Duration: 1.5 weeks
Payout: $4,000
Deliverables:
- LEZ/SPEL development environment;
- architecture and state model;
- cliff + linear arithmetic;
- fully linear arithmetic;
- milestone arithmetic;
- deterministic rounding policy;
- current LEZ token-authority analysis;
- custody abstraction;
- event schema;
- CI foundation;
- unit and boundary tests.
Acceptance evidence:
- compiling implementation;
- documented architecture;
- green CI;
- reproducible vesting test vectors.
Milestone 2 — Core Vesting State Machine
Duration: 1.5 weeks
Payout: $6,000
Deliverables:
- schedule creation;
- all required schedule types;
- claimable calculation;
- cancellation;
- irreversible cancelable → non-cancelable transition;
- beneficiary transferability;
- cancellation/milestone authorities;
- lifecycle events;
- invariant tests.
Acceptance evidence:
- complete core test suite;
- deterministic failure-path tests;
- documented invariants.
Milestone 3 — Token Custody and Privacy Integration
Duration: 2 weeks
Payout: $7,000
Deliverables:
- escrow/custody integration;
- public claims;
- private claims;
- private destination validation;
- atomic claims;
- atomic cancellation;
- protected state updates after token movement;
- integration tests.
Acceptance evidence:
- end-to-end token flows;
- public/private claim tests;
- failed-transfer tests proving vesting state remains unchanged.
Milestone 4 — SDK, CLI and Batch Operations
Duration: 1.5 weeks
Payout: $5,000
Deliverables:
- complete SDK;
- SPEL-compatible IDL;
- CLI;
- batch schedule creation;
- event parsing;
- structured errors;
- next-unlock reporting;
- developer examples.
Acceptance evidence:
- SDK/CLI integration tests;
- reproducible commands covering the complete vesting lifecycle.
Milestone 5 — Basecamp Mini-App
Duration: 1.5 weeks
Payout: $4,500
Deliverables:
- creator dashboard;
- beneficiary dashboard;
- schedule and batch creation;
- public/private claims;
- cancellation;
- milestone management;
- beneficiary transfer;
- transaction confirmation;
- clear privacy disclosures.
Acceptance evidence:
- working frontend against the deployed test environment;
- documented setup and E2E user flows.
Milestone 6 — Testnet, CI, E2E and Performance
Duration: 1 week
Payout: $3,500
Deliverables:
- deployment to the target LEZ testnet;
- standalone sequencer E2E suite;
- E2E tests in CI;
- RFP requirement/test matrix;
- compute/cycle measurements;
- measured batch limits;
- deployment scripts.
Acceptance evidence:
- testnet program address;
- transaction evidence;
- green CI;
- reproducible benchmark output.
Milestone 7 — Independent Security Review and Remediation
Duration: 1.5 weeks
Payout: $8,000
Deliverables:
- independent third-party security review;
- threat model;
- review report;
- remediation of accepted findings;
- regression tests;
- final security checklist.
The $8,000 allocation is reserved for independent security review and remediation before mainnet deployment.
Milestone 8 — Subsequent Testnet Compatibility
Duration: 0.5–1 week
Payout: $2,000
Deliverables:
- deployment/validation against the next required LEZ testnet release;
- compatibility fixes;
- full regression suite;
- SDK/CLI compatibility validation;
- updated performance measurements where required.
Milestone 9 — Mainnet Release and Handoff
Duration: 0.5–1 week
Payout: $2,000
Deliverables:
- LEZ mainnet deployment;
- verified program address;
- tagged open-source release;
- complete README;
- deployment instructions;
- SDK/CLI examples;
- mini-app documentation;
- event documentation;
- maintainer handoff notes.
Total duration: approximately 11–12 weeks, subject to availability and verified behavior of required LEZ platform primitives.
Total Requested Budget (USD)
42000
Relevant Experience
I have production engineering experience across Web3, distributed backend systems, cloud-native infrastructure, and full-stack products.
Relevant technical experience includes:
- Rust and Solidity development;
- DeFi and smart-contract integrations;
- NFT marketplaces and token-based applications;
- wallet and blockchain API integrations;
- TypeScript/Node.js and Python backend systems;
- PostgreSQL and MongoDB;
- REST and GraphQL APIs;
- Docker and Kubernetes;
- AWS and cloud infrastructure;
- CI/CD and automated testing;
- distributed systems and production observability.
I have worked end-to-end across system architecture, implementation, testing, deployment, reliability, and production operations.
Relevant work:
-
Web3 / Rust — MINTABLE: Built and maintained production blockchain infrastructure and NFT marketplace systems, contributing to Web3 and smart-contract development using Rust, Solidity, Ethereum, Web3.js, and Ethers.js. Also built blockchain data pipelines for Uniswap V3 and Aave V3.
-
Smart-contract / DeFi — SOLARR: Developed NFT marketplace and DeFi products across Ethereum and Solana, including Rust/Solidity smart contracts, ERC-20, ERC-721A, ERC-1155 and ONFT-721 integrations, cross-chain purchase/swap workflows using CCIP/CCTP, and gas/security optimization.
-
Full-stack Production — MINTABLE: Built production NFT marketplace frontend and backend systems using React, Next.js, Node.js, TypeScript, Python, NestJS, FastAPI, REST/GraphQL, Elasticsearch, AWS, Docker, Kubernetes, CI/CD, monitoring, crypto payments, and automated testing.
-
Portfolio: https://akira-nakao.netlify.app
-
LinkedIn: https://www.linkedin.com/in/akira-n-a27a7a406/
Post-Delivery Plan
I will remain the primary maintainer of VeilVesting after grant completion.
Post-delivery maintenance will cover:
- compatibility with future LEZ releases;
- dependency upgrades;
- critical security fixes;
- bug fixes;
- CI maintenance;
- SDK and CLI compatibility;
- documentation improvements;
- review of community issues and pull requests;
- support for downstream Logos projects integrating the vesting SDK.
The architecture will intentionally separate core vesting logic from token, wallet, and frontend integrations so that changes in the surrounding LEZ ecosystem do not require rewriting the core protocol.
Security-critical issues will receive priority.
All grant-funded code and technical deliverables will remain publicly available under the required MIT and Apache 2.0 licenses.
Permissions and Consent
Program Requirements
RFP ID
RFP-017 — Privacy-Preserving Token Vesting
Your Project Name
VeilVesting
Team or Organization Name
Independent
Primary Contact
akiranakao.dev@gmail.com
Team Members
Akira Nakao
Role:: Developer / Engineer / Architect
Status: Full-time independent contributor
Github: https://github.com/supersmile0426
Linkedin: https://www.linkedin.com/in/akira-n-a27a7a406/
Website:https://akira-nakao.netlify.app/
Senior software engineer and architect with experience across Web3, distributed backend systems, and full-stack product development.
Relevant technical experience includes Rust, Solidity, DeFi and smart-contract integrations, wallet and blockchain APIs, TypeScript/Node.js, Python, PostgreSQL, Docker, Kubernetes, AWS, CI/CD, automated testing, and production operations.
For VeilVesting I will directly own protocol architecture, LEZ/SPEL development, SDK and CLI implementation, frontend integration, testing, CI/CD, deployment, and documentation.
An independent security reviewer will be engaged before mainnet deployment.
Project Summary
VeilVesting is a privacy-preserving token vesting protocol for the Logos Execution Zone.
The goal is to combine publicly verifiable vesting commitments with private post-claim token ownership.
The protocol will support:
The important privacy boundary is deliberate: vesting terms, beneficiary, token allocation, and claimed amounts remain publicly auditable, while a beneficiary may choose to receive vested assets into a private account so that subsequent token movements are not exposed as part of the same public financial graph.
This matters because token vesting is foundational infrastructure for token launches, contributor compensation, ecosystem grants, investor allocations, and incentive programs.
VeilVesting would provide reusable LEZ infrastructure for these use cases while adding a privacy property that conventional transparent vesting contracts do not provide.
Technical Approach
VeilVesting will be structured into five main layers:
Vesting State
Each schedule will track the minimum deterministic state required for secure execution, including:
The exact representation will follow current LEZ/SPEL account and serialization requirements.
Vesting Types
The implementation will support:
Cliff + Linear: nothing vests before the cliff, followed by linear vesting until the end.
Fully Linear: continuous vesting from start to end without a cliff.
Milestone-Based: predefined tranches are unlocked by an authorized milestone signer. A milestone can only transition once and cannot release the same allocation twice.
The fundamental claim invariant will be:
claimable = min(vested_amount(current_time), total_amount) - claimed_amountwith:
0 <= claimed_amount <= vested_amount <= total_amountAll arithmetic will use deterministic integer calculations with explicitly documented rounding behavior.
Cancellation
Cancelable schedules may be irreversibly converted into non-cancelable schedules.
When a schedule is cancelled:
Cancellation and token movement will be designed atomically so failed operations cannot leave token balances and vesting state inconsistent.
Beneficiary Transfer
Transferability will be configured at schedule creation.
When enabled, the current beneficiary may transfer the position to another public beneficiary. When disabled, transfer attempts will fail.
Transferability itself will not become mutable after schedule creation.
Public and Private Claims
VeilVesting will support separate public and private claim paths.
For private claims, the SDK will validate that the destination satisfies current LEZ private/shielded-account requirements.
The private destination will not be persisted as public vesting state.
The public chain will continue to expose the vesting commitment and claimed amount, but not the receiving private account or subsequent private token activity.
The mini-app will clearly explain this privacy boundary rather than presenting the mechanism as complete beneficiary anonymity.
LEZ Integration and Dependencies
The current RFP identifies token transfer-authority functionality as an important dependency for escrow and payouts.
I will validate the current LEZ implementation directly rather than assume that the RFP description exactly reflects the latest runtime behavior.
The token custody layer will therefore be isolated behind a narrow interface.
The vesting state machine, arithmetic, lifecycle rules, events, SDK interfaces, CLI architecture, test vectors, CI, and frontend workflows can be developed independently of changes to the underlying custody mechanism.
Where current LEZ token/PDA functionality already provides the necessary authority model, it will be documented and verified before integration. If an upstream primitive is still required, final custody integration will use the supported mechanism once available.
Events
Structured events will cover at least:
ScheduleCreatedTokensClaimedScheduleCancelledMilestoneSignalledBeneficiaryTransferredSDK
The SDK will expose the complete lifecycle, including:
CLI
The CLI will expose equivalent operations for developers and operators, with human-readable errors and reproducible commands.
Basecamp Mini-App
The beneficiary interface will allow users to:
The creator interface will support:
Testing and Security
Testing will include:
Important invariants include:
Compute/cycle usage will also be measured for creation, claims, cancellation, milestone signalling, beneficiary transfer, and batch operations.
Fee Model
The initial protocol fee will be 0%.
No additional protocol fee will be charged to beneficiaries for claiming vested tokens.
Milestones, Payout and Timeline
Milestone 1 — Architecture, LEZ Validation and Vesting Kernel
Duration: 1.5 weeks
Payout: $4,000
Deliverables:
Acceptance evidence:
Milestone 2 — Core Vesting State Machine
Duration: 1.5 weeks
Payout: $6,000
Deliverables:
Acceptance evidence:
Milestone 3 — Token Custody and Privacy Integration
Duration: 2 weeks
Payout: $7,000
Deliverables:
Acceptance evidence:
Milestone 4 — SDK, CLI and Batch Operations
Duration: 1.5 weeks
Payout: $5,000
Deliverables:
Acceptance evidence:
Milestone 5 — Basecamp Mini-App
Duration: 1.5 weeks
Payout: $4,500
Deliverables:
Acceptance evidence:
Milestone 6 — Testnet, CI, E2E and Performance
Duration: 1 week
Payout: $3,500
Deliverables:
Acceptance evidence:
Milestone 7 — Independent Security Review and Remediation
Duration: 1.5 weeks
Payout: $8,000
Deliverables:
The $8,000 allocation is reserved for independent security review and remediation before mainnet deployment.
Milestone 8 — Subsequent Testnet Compatibility
Duration: 0.5–1 week
Payout: $2,000
Deliverables:
Milestone 9 — Mainnet Release and Handoff
Duration: 0.5–1 week
Payout: $2,000
Deliverables:
Total duration: approximately 11–12 weeks, subject to availability and verified behavior of required LEZ platform primitives.
Total Requested Budget (USD)
42000
Relevant Experience
I have production engineering experience across Web3, distributed backend systems, cloud-native infrastructure, and full-stack products.
Relevant technical experience includes:
I have worked end-to-end across system architecture, implementation, testing, deployment, reliability, and production operations.
Relevant work:
Web3 / Rust — MINTABLE: Built and maintained production blockchain infrastructure and NFT marketplace systems, contributing to Web3 and smart-contract development using Rust, Solidity, Ethereum, Web3.js, and Ethers.js. Also built blockchain data pipelines for Uniswap V3 and Aave V3.
Smart-contract / DeFi — SOLARR: Developed NFT marketplace and DeFi products across Ethereum and Solana, including Rust/Solidity smart contracts, ERC-20, ERC-721A, ERC-1155 and ONFT-721 integrations, cross-chain purchase/swap workflows using CCIP/CCTP, and gas/security optimization.
Full-stack Production — MINTABLE: Built production NFT marketplace frontend and backend systems using React, Next.js, Node.js, TypeScript, Python, NestJS, FastAPI, REST/GraphQL, Elasticsearch, AWS, Docker, Kubernetes, CI/CD, monitoring, crypto payments, and automated testing.
Portfolio: https://akira-nakao.netlify.app
LinkedIn: https://www.linkedin.com/in/akira-n-a27a7a406/
Post-Delivery Plan
I will remain the primary maintainer of VeilVesting after grant completion.
Post-delivery maintenance will cover:
The architecture will intentionally separate core vesting logic from token, wallet, and frontend integrations so that changes in the surrounding LEZ ecosystem do not require rewriting the core protocol.
Security-critical issues will receive priority.
All grant-funded code and technical deliverables will remain publicly available under the required MIT and Apache 2.0 licenses.
Permissions and Consent
Program Requirements