the bleak protocol has released its contract address.
this is the asset where trading activity generates the creator fees that power the process. as volume moves through it, those fees are collected by the protocol and routed into the same claim / buy / burn cycle described above.
the fees do not sit idle or depend on someone moving them later. collection, buyback, burn and settlement are enforced onchain as one atomic path.
contract address:
BLEAK9dcrWtS9o3TYePJHsuacirJZoWzc1Gg3gpgZ2kr
Bleak promises no yield, appreciation, roadmap, or future. It specifies protocol conduct instead: fees claimed, supply burned, records kept, and failures published.
At every cycle, Bleak checks its books against a live vault balance and publishes the drift. If internal records claim more than the chain holds, that mismatch becomes the highest-priority alarm.
The proposed distribution reserve keeps a fixed slice of each claim and can top up thin rounds. Deployment is capped at 40% of accumulated reserves so the buffer cannot empty during high-volume periods.
The proposed distribution queue pays existing owed balances before new round payouts. If a round runs out of capacity, unpaid debt keeps its place at the front of the next round.
Proposed distribution accounting enforces claimed = paid + owed + remaining. Each cycle compares that identity with a live wallet-balance read. A self-derived total is not accepted as proof.
Proposed payouts below 890,880 lamports are not discarded. They become owed balance and accumulate until the wallet clears the rent floor. owed only resets after a confirmed payout.
Proposed distribution rounds draw a length between 180 and 420 seconds from the launch seed. Every visitor sees the same round. The exact length is not published in advance, removing a public settlement timer.
Splitting one balance across multiple wallets does not increase proposed distribution shares. The sum of each wallet's balance-time integral equals the integral of the original combined balance.
In Bleak's proposed distribution model, buying tokens late can raise your accumulation rate but cannot purchase earlier holding history. A wallet arriving at minute 40 starts with zero accumulated time.
Bleak's proposed holder distribution model uses time-weighted shares, not a balance snapshot. A wallet's balance sets the accumulation rate. The integral of that balance over time determines its share.
Rotating cranker, treasury, or authority does not touch the vault and cannot repin the mint. Rotation changes who may press a configured button. It does not rewrite the buy path.
The buyback destination is not caller input. Bleak checks https://t.co/6jlTV8hcko == https://t.co/gWWgijsiEU, then verifies the curve creator resolves to the vault. For any caller, the reachable mint set has one member.
Bleak's cumulative burn counter is read from chain state, not from the crank's memory. The engine does not get to report a number it derived only from itself.
For each buyback, q is the token amount actually returned by the instruction. Bleak calculates burned = q x burn_bps / 10,000 and treasury = q - burned. Every bought token lands in exactly one of those two terms.
Bleak's revenue model is dR/dt = fee rate x traded volume. When volume drops, vault inflow drops with it. The protocol does not add emissions or manufacture yield to keep the buyback number constant.
settle is open to anyone. It burns burn_bps of the vault's bought tokens and sends the remainder to the configured treasury. The caller supplies timing, not a destination.
wrap_sol and unwrap_wsol are permissionless. They only move value between the vault's SOL and wrapped SOL forms. Neither instruction can move value out of the configured flow.
collect_curve_fees and collect_amm_fees are open to anyone. Config already fixes every destination. A caller can pay the transaction fee to move fees sooner, but cannot redirect them.
Bleak keeps protocol state in two accounts. config stores authority, cranker, treasury, pinned mint, burn share, and running stats. vault holds the SOL and bought tokens while carrying no data.
Bleak's supply invariant is simple: supply(t+1) <= supply(t). The program has no mint instruction, no mint authority, and no path to acquire one. Its only supply-changing operation burns.