Five levels.
One long shift.

01 / THE PREMISE

A ladder is useful only
when its rules are visible.

PALU SHIFT (帕鲁打工局) is a five-level token issuance contract deployed on BNB Chain. Primary subscription and issuance are restricted to wallets with a verified Binance .ai Agent ID. A scheduled price increase alone cannot demonstrate demand; a finite schedule is paired with market checks before another level opens.

Each level offers fewer units at a higher published price. Advancing requires the previous allocation to sell out and the designated pool average to meet the next issuance price under fixed oracle and reserve checks. A falling market can stop new issuance; ordinary ERC20 transfers and secondary-market purchases and sales remain unrestricted by Agent ID.

Higher mint prices are conditions for issuance. They are not promises about future market prices.

Five levels, one very tired office worker. PALU SHIFT turns the issuance ladder into a pixel-art workday: Clock In, Coffee Run, Deep Work, Overtime, and Clock Out. These names are a story layer, not a salary, employment right, or yield mechanism. The contracts must enforce the rules independently of the story.

PALU SHIFT is an independent fan-made pixel-art experiment inspired by the Palu office-worker character seen on Binance’s Chinese X account. It is not affiliated with or endorsed by Binance, and it is not connected to other PALU tokens. No Binance official logo is used; PSHIFT is not a Binance-issued token.

02 / ONE UNIT

A clear starting point.

A unit (called a share in the interface) is a primary-issuance purchase of 10,000 PALU SHIFT tokens. It is not an NFT, a mining machine, a share of the treasury, or a promise of income. Clock In begins at 1 USDT per unit, equivalent to 0.0001 USDT per token. The ERC20 ticker is PSHIFT and uses 18 decimals.

Every level delivers the same token quantity per unit. Unit prices and allocation limits are published in advance, so the buyer can compare the issuance price with the secondary market. Network fees and any third-party trading fees are separate.

03 / FIVE LEVELS

A finite path forward.

The schedule fixes an upper bound, not a sales forecast. No level is guaranteed to fill or open. A later level cannot bypass the previous level’s sold-out condition. The protocol’s 90-day issuance window can end with unused allocations.

Later-level issuance is capped globally at 100 units in each Unix clock hour, across all later levels. Unused hourly capacity does not accumulate. A clock-hour boundary can allow up to 200 units in a short interval spanning two hours. Each transaction accepts 1–10 whole units and must fit both the remaining level allocation and that handle’s remaining quota.

04 / CAPITAL & SUPPLY

Money has a destination.
Supply has a ceiling.

At full subscription, this allocates at most 33,030 USDT to liquidity and 3,670 USDT to project operations. There is no free team token allocation and no additional protocol buy or sell tax. Exchange fees still apply.

Separate budgets for buyers and liquidity

User issuance is capped at 300,000,000 tokens. Liquidity provision has a separate ceiling of 270,000,000 tokens: at most 9,000 additional tokens per purchased unit. The combined lifetime issuance cap is therefore 570,000,000 tokens.

Liquidity additions use the synchronized reserve ratio, with token quantities rounded down. Before every later mint, spot and TWAP must both be at least the current issuance price; the actual token-side mint cannot exceed 9,000 tokens per unit. Payment collection, liquidity creation, buyer tokens and the treasury payment are atomic: a failed step reverts the complete transaction. The expectedLevel argument rejects a purchase if its stage changed before execution.

The 270,000,000 budget is a maximum, not an automatic distribution. A higher pool price requires fewer PALU SHIFT tokens for the same USDT addition. Unused capacity is permanently retired at the issuance sunset; it cannot become team inventory.

05 / CLOCK IN OPENING

Escrow first.
A market only when ready.

Clock In subscriptions start at contract deployment and end exactly 144 hours (6 days) later. The hard target is 10,000 units at 1 USDT each. Funds stay in the sale contract; no operating payment or user token issuance occurs before activation. At 10 units per handle, activation needs at least 1,000 distinct eligible handles; this does not establish 1,000 unique people.

1. Subscribe. Allocation is first come, first served in chain transaction order. An exact request for 1–10 whole units either succeeds in full or reverts; there is no partial allocation or collection of an unaccepted payment. ID quota and the 10,000-unit hard cap are checked before transfer.
2. Activate. Anyone may activate once all 10,000 units are subscribed, strictly before the 144-hour deadline. The project contributes exactly 9,000 USDT plus 90,000,000 tokens to the designated PancakeSwap V2 pair, burns its LP receipts and pays 1,000 USDT directly to the treasury. The full 100,000,000 subscriber tokens are minted into the sale escrow at activation, funding claims even after day 90.
3. Refund if activation fails. If activation has not completed at the deadline, the original paying wallet may reclaim its full accepted payment. Anyone can trigger refundFor, but payment always goes to that original payer. Current Agent ID ownership is not required for either refunds or claims.

The pair must have no pre-existing LP supply or PALU token balance at activation. Unsolicited USDT-only donations, including donations already synchronized into reserves, are accepted without blocking activation. The project’s contribution implies 0.0001 USDT per token; donated USDT can make the resulting spot price higher. Neither the deployment transaction nor a payment to the treasury address is a subscription.

06 / RULE-BASED PROGRESSION

Three gates.
No discretionary shortcuts.

For Coffee Run, the issuance price is 1.15 ÷ 10,000 = 0.000115 USDT per token. Selling out Clock In alone is insufficient. The oracle uses the designated token/USDT pair’s cumulative price, including a counterfactual current observation, and the newest stored anchor between 24 and 25 hours old. It is a 24–25-hour average, not a guarantee that every instantaneous price exceeded the threshold.

Every later mint repeats the TWAP floor, spot floor, 4,500-USDT current-reserve minimum and 5% spot/TWAP deviation checks after synchronizing pool balances. Both directions of deviation are limited. Checkpoints are permissionless, separated by at least one hour and stored in a 26-slot ring. A keeper or community member must maintain observations. With no valid 24–25-hour anchor, new issuance stops until a suitable history exists again.

These fixed parameters have no administrator setter or bypass. The 4,500-USDT test checks current depth, not a minimum sustained throughout the averaging window; an hourly checkpoint is not a continuous liquidity observation. A passing TWAP does not prove organic demand or eliminate manipulation. Levels never skip the prior sold-out gate, and paused issuance does not pause secondary trading.

07 / PARTICIPATION

Bounded access.
Honest limitations.

Primary subscription and later issuance require 10 units or fewer per verified Binance .ai Agent ID per level. The contract reads the caller’s canonical bare handle with handleOf(wallet), checks its syntax and requires ownerOfHandle(handle) to equal the caller. Quotas are keyed by the hash of that handle and the level, rather than by wallet. A changed wallet does not create a fresh quota for the same handle.

The deployed sale’s identity registry is 0x60B9262456dE011F7d15a54CdD8c48bAaa8B022F, identified from Ptah’s published .ai integration and checked on-chain; this is not a Binance-published deployment-address list. Binance’s Agent ID documentation describes the naming and wallet flow. Registry availability and correctness remain external dependencies. A syntactically valid name alone is not ownership, and registry eligibility is not proof of a unique human or Binance endorsement. Ordinary secondary ERC20 trading has no Agent ID restriction.

The Binance documentation currently describes IDs as non-transferable and not renameable. The quota still follows the handle if a registry mapping changes; a new or replaced identity may have different rights. Refunds and initial claims remain bound to the original paying wallet. There are no referral cash rewards, free referral issuance, holder dividends, staking yield or daily token rewards.

08 / ISSUANCE SUNSET

An end that stays an end.

New primary issuance ends permanently 90 days after deployment, including the opening 144 hours. Token minting checks the deadline independently of the sale. There is no extension, replacement allocation or further level. Anyone may finalize closure after the deadline, after a failed opening, or once all five allocations have sold out.

The contract mints on demand and maintains monotonically increasing lifetime counters capped at 300,000,000 user tokens and 270,000,000 liquidity tokens. Unused capacity expires rather than becoming inventory. Final closure irreversibly disables minting; even without a closure transaction, the deadline prevents further minting. Initial subscriber tokens funded at activation remain claimable after closure because a claim transfers existing escrowed tokens.

The token and existing liquidity continue to trade after issuance closes. Operating allocations already paid to the treasury stay under the receiving wallet controller’s custody. Issuance closure creates no price floor or guaranteed exit.

09 / ECONOMIC BOUNDARIES

What the mechanism
cannot do.

It cannot manufacture demand.

Issuance gates regulate new supply. They do not create buyers, external revenue, or intrinsic redemption value.

It cannot remove arbitrage.

If the mint price is below the market, buyers may mint and immediately sell. Batching and quotas limit the rate; they do not eliminate selling pressure.

Burned LP does not protect price.

Only the project’s LP receipts are burned. External providers and PancakeSwap protocol-fee LP may have withdrawable positions. Swaps can still remove USDT, and the token can lose most or all of its value.

A TWAP is a check, not an oracle guarantee.

Thin pools and sustained manipulation can distort the average. The reserve minimum is checked at execution, not continuously. Same-pool pricing and a 5% deviation bound do not establish independent demand or make manipulation impossible.

Underlying assets and contracts can fail.

USDT can depeg or restrict addresses. DEX, token, identity, and protocol contracts introduce bugs and dependency risks. Network congestion and MEV affect execution.

Holders are not promised equity, treasury ownership, protocol revenue, governance rights, or a return. Any future feature would require a separate, clearly stated specification; it is not an implied benefit of buying the token.

10 / MAINNET DEPLOYMENT

Deployed rules.
Check the evidence.

Version 0.2 was deployed on BNB Chain on 29 October 2026 at 19:17:34 UTC. The opening deadline is 4 November 2026 at 19:17:34 UTC; new issuance ends on 27 January 2027 at 19:17:34 UTC. The designated pair exists, but pool activation is separate and requires a successful opening. Check the live panel for current subscription and pool state.
Sale: 0x64dbe3Ca5076d8604ef60a58553386c56f3813ca
PSHIFT token: 0xc8d79105B40E48BE415758c826de637Aa3815B18
PSHIFT / USDT pair: 0x82aaF1262b625D1329351BEE82e7f0192b42d197
Deployment transaction: 0x8f82fee82d44e48edd4f51d106584ca4ddb6eb5eb505813e92031aa4a8748dce
The deployment record publishes source, ABI, immutable configuration and receipt evidence. A frontend calculation is not a transaction.

• Review the fixed 144-hour opening, 90-day sunset, FCFS allocation, 4,500-USDT reserve test, 5% deviation, 24–25-hour oracle and global 100-unit clock-hour cap.
• Publish and compare the exact contract source, compiler input, ABI, constructor addresses and verified deployment bytecode.
• Test escrow, full refunds, supply caps, direct treasury payouts, ID transfers, liquidity math, oracle faults, and the irreversible issuance sunset.
• Simulate sell pressure, new-mint arbitrage, thin liquidity, and hostile transaction ordering.
• Disclose that no independent external security audit has been completed. Compilation, local scenario tests and internal review are limited evidence, not an audit certification.

The deployed contracts contain no owner, upgrade mechanism, escrow-withdrawal method, parameter setters, private team mint, secondary-transfer pause or deadline extension. The published source and fixed configuration have been compared with the deployed bytecode. External USDT, the identity registry and PancakeSwap remain dependencies; absence of an administrator does not establish safety.