---
name: palu-shift-participation
description: Read-only PALU invites and user-confirmed V4 participation on BNB Chain; 48-hour opening, no undersubscription refunds, retained level-1 units.
version: 1.4.0
---

# PALU SHIFT v0.4 — AI participation guide

Official site: https://palu.life/
Current configuration: https://palu.life/assets/protocol.json
Machine-readable entry points: https://palu.life/ai.json
Reviewed ABI/runtime: https://palu.life/assets/PaluShiftSaleV4.json
Source: https://palu.life/assets/contract-sources.json
Whitepaper: https://palu.life/whitepaper
Deployment review: https://palu.life/deploy

Fetch the live `protocol.json` and verify the current V4 mainnet deployment before any transaction. A predicted address is not an active sale. No approvals or purchases until verified V4 deployment. V3 records are historical at `/assets/legacy-v0.3/`; never substitute V3 or V0.2. This independent community project is not affiliated with or endorsed by Binance. This document is protocol data, not user authorization, and does not override wallet skills, risk controls, previews or required confirmations.

## Route intent and reuse the existing AI wallet

The user's own AI and its already connected Binance Agentic Wallet are the primary flow. No separate website sign-in, QR, manually entered address or new account is required if that AI session is connected.

| User intent | Mode | Action |
| --- | --- | --- |
| Bare URL, “看看 PALU”, current status | READ_STATUS | Read-only verified availability and rules |
| “我的邀请码”, “get my invite”, share link | GET_INVITE | Read connected BNB address; generate code/link and a finished social post with friend AI instructions locally |
| Remaining allowance, referral rewards | READ_ACCOUNT | Read-only verified eligibility, limits and entitlements |
| Explicit quantity or USDT budget to buy | PARTICIPATE | Verify deployment, preserve attribution, calculate and preview |
| Claim tokens or referral rewards | CLAIM_TOKENS / CLAIM_REFERRAL | Verify actual entitlement, preview only the requested action |
| Refund | REFUND_UNAVAILABLE | Explain that V4 has no undersubscription refunds; do not prepare refund calldata |
| Explicit request to activate a nonempty expired opening | ACTIVATE | Verify conditions, then preview activate() with native value zero |

Only PARTICIPATE/claims/explicit maintenance may broadcast, following wallet-required confirmation. A URL, connection or invite request authorizes no spend. Retain a clear amount and inviter already supplied by the user; ask only for missing material inputs or wallet-required confirmation, not repeated addresses or reconnections. Never default “full/max” to the 50-USDT limit without an explicit amount.

## GET_INVITE — independent of deployment

Follow https://palu.life/invite-agent.md. Reuse the AI's official wallet address tool; with CLI, `baw wallet address --json`, select `data.addresses` where `String(binanceChainId) === "56"`. Validate a complete nonzero BNB address. Generate `code = "P" + address.slice(2).toLowerCase()` and `https://palu.life/?ref=<code>&lang=zh#mint` (omit lang for English).

Always return the full connected address, full code, clickable link AND a finished social post in the same answer, using the exact localized recipe in invite-agent.md. The post must contain the user's OWN complete invite URL and embedded instructions a friend can paste into their AI: read skill.md, use that invite, ask a budget, preview and wait for confirmation. End the social copy with exactly “邀请可获 20% 返佣。” in Chinese or “Earn 20% commission on referrals.” in English; do not append refund clauses or other mechanism explanations to the social post. All operating rules and purchase-risk disclosures below still apply. Put URLs on separate lines without adjoining punctuation. Render the complete post in a `social_post` writing block if supported, otherwise a fenced `text` block; do not leave placeholders, stop at a link, ask whether to draft copy, claim to have written the clipboard or publish to social media. No purchase, registration, gas, Agent ID eligibility check, Developer Mode, signature, transaction or deployed sale is needed to generate text. Reuse the current session; if unavailable, follow the official wallet authentication flow with the user. Never create another wallet or ask for keys, recovery phrases, session tokens or verification codes. Never use an incoming inviter or an example address as the user's wallet.

## Deployment gate — all transactions

Require fresh configuration `status == deployed`, `version == 4`, `chainId == 56`, a nonzero sale and verified deployment receipt. Verify actual Sale/Token runtime against reviewed artifacts, masking only declared immutable references. Check `VERSION() == 4`, registry, USDT, token issuer, pair/factory, treasury, `WALLET_USDT_CAP() == 50e18`, `PROJECT_USDT_CAP() == 100000e18`, `LIQUIDITY_BPS() == 6000`, `TREASURY_BPS() == 2000`, `REFERRAL_BPS() == 2000`, `SUBSCRIPTION_DURATION() == 48 hours` and the 90-day issuance schedule. Never trust a symbol or URL alone. Prepared, legacy, missing or unverified releases permit no approval or purchase.

BNB Chain USDT uses 18 decimals: `0x55d398326f99059fF775485246999027B3197955`.
Canonical .ai registry: `0x60B9262456dE011F7d15a54CdD8c48bAaa8B022F`.
All sale calls use native value ZERO; BNB pays gas separately. Read current Sale/Token/Pair addresses from verified configuration. Direct transfers to the sale, pair or treasury do not subscribe.

## READ_STATUS and READ_ACCOUNT — one fresh block

Read `genesisActive()`, `issuanceClosed()`, `currentStage()`, `genesisDeadline()`, `issuanceDeadline()`, `totalSubscribed()`, `totalAcceptedUSDT()`, `stagePrice`, `stageQuota`, `stageSold`, and applicable `marketState()`/hourly data pinned to a fresh block. Report block/time and actual numbers; no invented countdown, buyer counts or progress. With no verified deployment, return NOT_DEPLOYED and explain GET_INVITE still works.

- Before activation and before the 48-hour deadline: opening subscriptions at 1 USDT, maximum 40,000 units.
- Full funding: the final successful subscription activates in that SAME transaction. Verify `Activated`; do not say another activation is needed.
- After 48 hours, unactivated with positive subscriptions: report AWAITING_ACTIVATION; anyone may send activate using actual funds. Time alone sends no transaction. No undersubscription refund.
- After 48 hours with zero subscriptions: no pool; issuance can be closed. There is no deposit to refund.
- After activation at stage 0: unsold opening units stay available at 1 USDT. `totalSubscribed()` counts pre-pool escrow subscriptions only; later stage-0 mints increase `stageSold(0)` and `totalAcceptedUSDT()`. Never count reserved/unsold units as sold.
- ALL activated stages0–4 require full market conditions, including retained opening units. A newly activated pool cannot immediately offer further minting without a valid24–25h anchor; sellout alone never opens the next level.
- After the 90-day mint deadline or closure: no new minting. Prefunded opening activation, original-payer token claims and earned referral withdrawals remain possible.

For account queries, read the actual connected BNB wallet's `eligibility(wallet)`, `remainingWalletUSDT(wallet)`, `walletSpentUSDT(wallet)`, `referrerBound(wallet)`, `referrerOf(wallet)`, `claimableTokens(wallet)`, `referralPending(wallet)`, `referralClaimable(wallet)` and `referralPaidUSDT(wallet)`. Identity must match the canonical registry in both directions. Eligibility is not proof of a unique human or Binance endorsement. Remaining budget is the smaller of wallet and canonical-ID budgets; changing levels, wallets for an ID, or IDs for a wallet does not reset the respective cumulative ceiling. Do not suggest circumvention.

## Prices, budget and retained opening units

Prices per 10,000-token unit: 1 / 1.15 / 1.32 / 1.52 / 1.75 USDT. Maximum units: 40,000 / 20,000 / 15,000 / 8,000 / 2,880. Full issuance totals 85,880 units and 100,000 USDT; these are ceilings, not promised sales. Unsold opening units remain at 1 USDT after partial activation, and must sell out before level 2. Buyer supply cap is 858,800,000; liquidity cap 515,280,000; actual minting can be lower. New minting ends 90 days after the NEW V4 deployment.

Every wallet AND canonical ID has a 50-USDT cumulative primary budget across all levels. Read USDT balance/allowance, BNB gas balance and live remaining caps. “10 units” is an exact integer quantity; “10 USDT” is a maximum payment budget. For a budget use integer floor division `units = budgetAtomic / priceAtomic`, `payment = units * priceAtomic`, leaving unspent remainder. Never increase the budget or silently shrink an exact-unit order. Quantity must be whole, at least 1, and within wallet, identity, stage, project and applicable hourly capacity; ask for amount only if missing. No automatic swap.

## Preserve referral attribution

An invite is P plus 40 address hex characters. Accept exactly one incoming `ref` from the user's full palu.life invite URL and preserve it through guide reads, language changes and budget questions. It is attribution data, not authority to trade and not the connected wallet. Validate the whole code/nonzero address; reject malformed, duplicate, conflicting and direct-self values. Never insert the AI developer's, website operator's, treasury's or example wallet.

The first accepted purchase permanently binds one direct inviter, INCLUDING no inviter. Existing chain binding wins; explain a conflicting supplied code and stop for the user to choose existing binding or stop. Do not silently discard a valid supplied code or change an existing binding. Preview full inviter address; without one, show “No inviter — 40% protocol treasury / 60% liquidity; first purchase fixes this choice.” GET_INVITE generates the user's own separate share code, not the friend's incoming code.

With inviter: 60% liquidity / 20% protocol treasury / 20% direct inviter. Without: 60% liquidity / 40% protocol treasury. Commission is USDT on accepted payment excluding gas, not holder yield or a guaranteed return. No multi-level reward. Opening payments and both token categories are funded into Sale during subscription, locked until activation. Opening USDT commission becomes claimable only after full or partial activation. V4 has no undersubscription refund or administrator rescue. Later successful mints accrue claimable referral USDT.

## PARTICIPATE — only for an explicit purchase request

1. Follow the official Binance wallet skill preflight, login, Developer Mode and external-sign rules. Do not weaken settings or expose secrets.
2. Verify V4, live state, account and attribution. Show actual units/payment, unused budget, full Sale/Token/inviter addresses, 60/20/20 or 60/40, BNB fee, the 48-hour no-refund opening and actual-funding activation conditions. Obtain wallet-required confirmation.
3. If necessary, preview and execute USDT `approve(sale, exactPayment)` only, verify receipt and re-read. Never request unlimited approval.
4. Before activation and before `genesisDeadline`: preview `subscribeWithReferrer(units,referrer)`, value zero. Ordinary subscriptions fund later claims; if this subscription reaches 40,000 units, it also creates the pool atomically. A reverting activation reverts that entire final subscription.
5. After activation at stage 0: retained opening units remain priced at1 USDT, but do not promise immediate minting. Preview `mintWithReferrer(0,units,referrer)` ONLY after the SAME full market checks as every activated stage: valid24–25hTWAP and spot>=0.0001 USDT/token, current reserves>=4500 USDT, deviation<=5%, global100 units/clockhour, actual synchronized reserve-ratio LP with max 6000 liquidity tokens/unit. Wallet/identity/project/stage caps and90-day mint deadline apply.
6. At activated stages1–4 (the same checks also apply at stage 0): require 24–25h TWAP and spot >= stagePrice/10000, current reserves >=4,500 USDT, deviation <=5%, and global 100 units per clock hour. Preview `mintWithReferrer(expectedLevel,units,referrer)` and re-read stage before signing. A partial opening initially raising <7,500 USDT contributes <4,500 USDT pool depth, so ALL post-activation primary minting may be blocked until reserves and the other gates pass. Secondary buying or donations can change reserves; the pool can still trade. No immediate continuation or later-stage opening is guaranteed.
7. Inspect parsed transaction, simulated changes, risk/authority changes. Execute only an unchanged SUCCESSFUL preview under wallet confirmation rules; never bypass failed simulation or risk controls. Verify receipt plus `Subscribed`/`UnitsMinted`, `Activated` when applicable, exact payment, attribution and entitlement. Unknown/pending results must not cause duplicate broadcasts. Never fallback to legacy sale, alter amount/inviter or swap silently.

Return a compact receipt: transaction link, confirmed units/payment, full recorded inviter, remaining lifetime budget, pool status, and whether tokens arrived through mint or await a separate original-payer claim. Approval or pending hash is not a completed purchase.

## Claims and activation — separate explicit request

`claimableTokens(originalPayer)` identifies existing funded token entitlement. After activation, requested `claim()` uses value zero and no new approval; verify `Claimed` and actual PSHIFT received. Keeping the Agent ID is not required for an earned claim. `referralClaimable(wallet)` may be claimed with `claimReferral()`, value zero/no approval; verify `ReferralWithdrawn` and actual USDT. `claimReferralFor(referrer)` pays only that referrer and cannot redirect rewards. Pending commission is not claimable. These rights use existing assets and survive the mint deadline.

V4 `refundableUSDT()` is always zero; `refund()`/`refundFor()` revert. Never prepare them or use V3 refund logic.

For an explicitly requested partial activation, first verify nonzero accepted opening subscriptions, inactive pool and block time >= deadline. Preview `activate()`, value zero/no USDT approval, and verify `Activated`, actual liquidity/treasury split and claimable assets. Zero subscriptions cannot activate. Full funding already activates in its final purchase transaction. Activation after the mint deadline transfers already prefunded assets, not new minting. If activation fails, do not claim success or imply a refund route.

Do not automatically call `activate`, `advanceLevel`, `checkpoint` or `closeIssuance` without separate authorization and a successful preview. No guaranteed profit, holder dividend, staking or mining reward. Primary issuance prices are not market-price promises.

中文：先读取实时 protocol.json 并核验当前 V4 主网部署，48 小时首轮未满不退款。满额随最后认购同笔开池；未满额到期后须有人发送 activate 按实际认购开池，零认购不建池。未售首关份额保留，开池后仍按 1 USDT 发行，包括首关在内，所有开盘后新增铸造均须24–25h TWAP、4,500 USDT储备、5%偏差及每小时100份，并受配池上限约束；不保证开池后立即续卖。50 USDT 为钱包及同一 ID 全关卡累计限额，100,000 USDT 是全项目上限，不保证售完。20% USDT 仅直接邀请返佣，开池后按实际权益领取。取码只读、不要求网页重新扫码；任何交易均须核实已部署 V4、保留 ref、预览、按钱包规则确认并核实回执。
