TokenPledge.
TokenPledge is an end-to-end platform for programmable token custody and release across EVM-compatible networks and Massa. It supports market-cap-triggered pledges as well as token-sale allocations with configurable cliffs and continuous linear vesting.
- Role
- Senior Backend Engineer · Smart Contract / Web3 Protocol Engineer
- Domain
- DeFi · Cross-chain escrow · Token vesting · Automated keepers
System at a glance
What the system does
Market-cap-triggered token releases
Cliff-based linear vesting
Native coin and fungible-token custody
Automated cross-chain execution
Architecture flow
From intent to verified state.
- 01
Creators configure projects and pledges through a secured NestJS API.
- 02
MongoDB stores users, project rules, monitored prices, and execution state.
- 03
Keeper services ingest market data or inspect vesting state and determine eligible releases.
- 04
Signed transactions execute the release against upgradeable EVM contracts or Massa WASM contracts.
- 05
Receipts, progress, gas data, and failures flow back into the operational record and alerting pipeline.
01 / Protocol design
Two release models, one custody system
The protocol separates how eligibility is determined from how assets are held and released.
Market-cap milestones
Assets remain locked until monitored market capitalization reaches the configured target. An off-chain keeper evaluates the external condition and submits the eligible on-chain release.
Linear vesting
Token-sale allocations use a configurable cliff followed by continuous vesting. The releasable balance is derived from pledged amount, elapsed time, vesting duration, and the amount already released.
Asset polymorphism
A zero-address convention gives native coins and ERC-20 assets one pledge interface while retaining the correct payable, transfer, and transferFrom execution paths.
02 / EVM contracts
Upgradeable custody with explicit transfer boundaries
Upgradeable architecture
OpenZeppelin Initializable and OwnableUpgradeable patterns separate storage from logic so contract behavior can evolve without forcing users to migrate active pledges.
Defensive token handling
ReentrancyGuard protects release boundaries, while SafeERC20 handles non-standard token return behavior. State transitions follow checks-effects-interactions before value leaves the contract.
Fee and storage lifecycle
A protocol fee is calculated when a pledge is initialized. Fully released positions are removed from active storage after accounting is complete, reducing lingering state and future gas overhead.
Time-based tests
Hardhat, Mocha, Chai, and Ethers.js tests advance EVM time and mine blocks to exercise cliff boundaries, partial releases, completion, and duplicate-pledge rejection.
03 / Massa contracts
The same financial rules in a WASM environment
Native WASM execution
The Massa implementation uses AssemblyScript with the Massa SDK and token standards rather than attempting to force EVM assumptions onto a different runtime.
Precise on-chain arithmetic
u256 values from as-bignum preserve crypto-sized integer precision and avoid floating-point math in pledge balances and release calculations.
Storage and serialization
Namespaced storage keys isolate pledge records by sender. Custom serializers convert structured pledge data into deterministic byte payloads suitable for low-level WASM storage.
04 / Backend & automation
The operational layer behind autonomous releases
Modular NestJS API
Controllers, services, and Mongoose models separate authentication, projects, pricing, scheduling, and blockchain concerns. JWT, Argon2, route guards, and role decorators enforce access boundaries.
Market-cap keeper
A TypeScript worker batches CoinGecko requests, applies rate-limit backoff, updates price and supply data, calculates progress, and submits release transactions when targets are satisfied.
Vesting release worker
A second daemon polls active vesting positions, queries the relevant contract for releasable value, then manages wallet signing, nonces, gas limits, fee buffers, and transaction receipts across chains.
Operational feedback
Transaction hashes and gas consumption are logged, execution state is persisted, and reverted transactions or RPC outages generate operator email alerts rather than failing silently.