DRAFT — PENDING COUNSEL REVIEW

This page is a draft awaiting review by legal counsel. Counsel review is a hard launch gate. The technical facts below are accurate as built; the framing will be reviewed before mainnet.

Trust & Verification

You should not have to trust us — you should be able to check. This page states precisely what the contract can and cannot do, how it was verified, and how to confirm every claim yourself on-chain.

1.The contract

This build points at the NILE TESTNET deployment. The vault contract address is:

TPqHynifVKgk4gZVoB7jVLD1V9q6FLrBJn

The source is verified on TronScan, so anyone can read the exact code that produced the deployed bytecode: View the verified contract on TronScan ↗

2.What we cannot do

Each statement below is enforced by a specific property of the contract, not by a promise. We state these precisely: where we say “designed to” or “the contract has no…,” we mean exactly that.

We have no admin keys.

The ABI exposes no owner, admin, or privileged role. There are only two state-changing functions: createLock and withdraw. No function lets us move, redirect, or seize a user’s tokens.

There is no pause switch.

The contract has no function to halt, freeze, or disable locks or withdrawals. It cannot be stopped by us or anyone.

There is no upgrade path.

The contract is not a proxy and uses no delegatecall. Its code cannot be replaced or pointed at new logic. A future version would be a separate, freshly deployed contract.

The fee and treasury are fixed at deploy.

The flat fee and the treasury address are set once in the constructor and have no setter functions. They cannot be changed after deployment.

Only the beneficiary can withdraw.

withdraw reverts with NotBeneficiary for any caller other than the lock’s designated beneficiary, and pays out only what has vested under the on-chain schedule.

We never take custody.

Tokens move straight from your wallet into the vault contract in the create transaction. They never pass through any account we control. The TRX fee is forwarded to the treasury in that same transaction; the vault holds no TRX.

3.How it was verified

The contract was checked at several independent layers, each catching what the one below it cannot:

  • A 52-test Foundry suite covering unit tests, fuzz tests (2,000 randomized cases each), and three handler-based invariant suites: per-token solvency (the vault always holds at least what it owes), no over-withdrawal (withdrawn never exceeds vested, vested never exceeds the locked total), and fee conservation (the vault holds zero TRX; the treasury receives exactly the fee times the number of locks created). The invariant runs exercise tens of thousands of randomized create/withdraw/time-warp sequences.
  • Slither static analysis. Every finding was triaged with written reasoning; all are false positives or accepted-by-design.
  • Two independent adversarial reviews, each prompted to break the contract — probing reentrancy, rounding theft, fee bypass, and griefing via malicious tokens — rather than to approve it, plus a separate mechanism-level verification pass.
  • A full lifecycle exercised by hand on the Nile testnet (approve → create → withdraw mid-vest → final sweep), with amounts checked against the vesting formula and the dust-sweep property confirmed live.

The test suite and methodology are available on request, and the verified contract source is already public on TronScan (linked above).

4.Guarded launch

We are honest about our posture. The contract is unaudited but source-verified, with the test suite and methodology published. Early users are advised to consider capping the size of their locks while the contract builds a track record. A paid third-party audit may follow; because the contract is immutable, such an audit would attach to the same deployed bytecode already in use — no migration, no re-deployment.

5.Verify it yourself

You do not have to take our word for any of this. Step by step:

  • (a) Open the contract page on TronScan ↗, check for the green verified-source badge, and read the code under the “Code” tab.
  • (b) Under “Read Contract,” call getLock(yourLockId) and compare the returned values with what this site shows for that lock.
  • (c) On the “Events” tab, watch the LockCreated and Withdrawn events to follow every lock and withdrawal as it happens.
  • (d) Note the constructor parameters (treasury address and flat fee). They are fixed forever — there is no function to change them.

6.Known limitations

In the interest of honesty, here is what the contract deliberately does not handle:

  • Rebasing tokens are unsupported. Tokens whose balances change algorithmically will not vest correctly; do not lock them.
  • Fee-on-transfer tokens record the received amount. For tokens that skim a fee on each transfer, the contract records the actual balance it received (the balance-delta), which may be less than the amount you sent. This is by design — it keeps the accounting honest — but it means the locked total can be smaller than the figure you entered.
  • No extension, transfer, or revocation in v1. Once created, a lock cannot be extended, reassigned to a new beneficiary, or cancelled. These features deliberately do not exist.
  • Tokens with non-ASCII symbols are rejected by the create flow. This is a conservative anti-spoofing measure to prevent look-alike token symbols.

See also the Terms & Risk Disclosure. Contact: see keypairinfra.com.