Execution. Settlement. Return.
VELLIN targets token launches on Robinhood Chain. Its planned token connects eligible holders to positive net realised execution profit through daily ETH distributions. Market buybacks and development funding complete the loop.
Pre-launch: no official token yet. Distributions and buybacks are not active. Verified token and distributor addresses will be announced on the official X account and this site.
The daily 30 / 30 / 40 split
Each closed UTC day starts with realised trading P&L. Trading fees and actual infrastructure expenses are deducted first. Only the remaining positive amount is distributed.
| Allocation | Use |
|---|---|
| 30% · Holders | ETH payments proportional to eligible VELLIN balances at the daily snapshot |
| 30% · Buyback and burn | Market purchase of VELLIN; bought tokens sent to the burn address |
| 40% · Team | Development, operations and future infrastructure |
An expense deducted before the split is not charged again as another deduction. The team allocation is its operating and development budget; it is not a second reimbursement of those same expenses.
If the net result is zero or negative, that day allocates zero to all three buckets. A daily processing schedule does not promise a daily positive payout.
The execution loop
Snipe new launches → close positions → settle costs → distribute 30/30/40 → develop the sniper → repeat.
Holder ETH connects participation to realised results. Buybacks use the market and remove the purchased tokens from circulation. The team budget supports the infrastructure and improvements needed to cover launches. Wider coverage may produce future profit; it does not guarantee it. The 40% budget does not automatically become additional trading principal.
Trade size still has a liquidity limit. Growth means evaluating more launch coverage, not blindly multiplying every entry. Read the sizing limit.
How a holder receives ETH
- The daily snapshot uses balances at the last confirmed block before 00:00 UTC, with a confirmation buffer. Balances are reconstructed from token transfers and checked against onchain balances.
- Each eligible wallet receives a proportional allocation from the 30% holder pool. The snapshot and allocation record are published for inspection.
- The developer deposits the approved net daily profit into the distribution contract in ETH. It cannot allocate funds that have not been deposited.
- An automated executor submits payment batches. The contract verifies each wallet's entitlement and sends ETH directly. There is no staking deposit.
- A repeated batch cannot pay the same entitlement twice. Rejected ETH stays reserved as a credit. Automated retries are limited to once per hour per recipient; the holder can immediately withdraw to another address.
The contract does not wake itself at midnight: the executor submits transactions. A delay in the executor can delay payment, but does not erase a funded entitlement.
What is fixed in the contract
The 30/30/40 percentages are fixed. The owner cannot withdraw the holder or buyback reserve into the team wallet. Each funded daily allocation is immutable. Valid holder payments can be delivered by anyone with the published proof; an interruption of the designated executor does not give it ownership of the funds.
Buybacks are separate transactions with a minimum token output and a deadline. A failed swap leaves that budget reserved and does not block holder payments. Sending tokens to the burn address removes them from circulation; it does not necessarily reduce the token contract's reported totalSupply.
What the developer still controls
The trading account, the approved daily profit/expense report and the submitted snapshot allocation remain operator-controlled. The distribution contract enforces allocations against that published record. It does not independently reconstruct trades, audit invoices or prove that an operator submitted every eligible wallet.
The owner can pause new funding and buybacks and change the executor. Already-funded holder claims and credits remain accessible during a pause. This is an explicit trust model, not a claim that the entire operation is trustless.
Status before launch
The distribution code, snapshot builder and daily executor pass local tests. The executor prepares approved reports, resumes funded epochs, retries deferred payments and exports chain-backed status. A report or allocation cannot silently change after preparation. Accounting approval remains an operator responsibility.
No distribution contract is deployed, no independent audit has been completed and no holder payment or buyback has occurred through this implementation. The future token and actual buyback market still need integration checks.
Launch setup lists the remaining concrete configuration. Token supply, allocation and official addresses are not invented while the token does not exist.