Know the ground.
Then take the shift.
This manual separates what you can use today from what opens after launch. The planning console works locally. Mining campaigns begin after token release and require their own verified implementation.
One project. Distinct layers.
Agent Miner is an agent-first mining project on BNB Smart Chain. Its public planning console lets you choose a rig lane, explore an epoch, allocate a resource scenario and save a local profile.
The V1 FLAP theme vault records agent profiles and operating intentions as events. It does not implement mining, staking, reward distribution, Agent ID verification or automated buybacks. A factory creates these theme vaults; it is a different address from the token, a theme vault or a mining pool.
A successful event record means an intention was recorded. It does not mean a mining shift ran, a reward became claimable or funds were distributed.
The local planning model
The model uses planning units to compare input scenarios. Units have no token, BNB or cash conversion. All numbers are calculated from your inputs; none are a live balance, hashrate or reward forecast.
| Lane | Duty cycle | Minimum allocation | Use |
|---|---|---|---|
| Scout / SC–01 | 45% | 10 units | Shorter active windows |
| Balanced / BL–02 | 65% | 25 units | Steady work and reserve |
| Deep / DP–03 | 85% | 50 units | Longer active windows |
The lane settings are illustrative planning presets. They are not on-chain yield multipliers, published eligibility gates or promises of output.
Reserved units = budget − allocated units
Active hours = epoch duration × lane duty
Resource use = allocated units × lane duty
Unspent units = budget − resource use
Status checks = ceil(active hours × 60 ÷ interval)
Allocation accepts whole percentages from 5% to 100%. Budget accepts 1 to 1,000,000 units. Epochs are 6, 12, 24 or 48 hours; monitoring intervals are 15, 30, 60 or 120 minutes. Invalid inputs suppress the derived results and cannot be saved.
Below a lane's minimum allocation, the whole shift stays on standby: active time, resource use and checks are zero. Increasing the budget or allocation, or selecting a different lane, may clear the threshold. The 12 schedule blocks are equal time windows, each split into active and standby time by the lane duty cycle.
A worked example
With a 100-unit budget, 60% allocation, Balanced duty and a 24-hour epoch: 60 units are allocated, 40 held in reserve, 39 used and 61 left unspent. The schedule has 15.6 active hours and 8.4 standby hours. An hourly check interval produces 16 planned checks.
Sensitivity and storage
Sensitivity applies a ±10 percentage-point change to duty, with all other inputs unchanged. The example above gives 33–45 units of resource use. It is a resource-use scenario, not a financial probability range.
Current inputs, up to 8 saved profiles, 12 save-history entries and the FX preference remain in this browser. Duplicate profiles are refreshed; the oldest profile is replaced when the limit is reached. History records save events. Removing a profile preserves its history. Loading a profile restores every model input. Clearing browser data removes this local workspace.
Launch states
| Capability | Current state | What changes it |
|---|---|---|
| Planning console | Available locally | No wallet required |
| Theme factory | See homepage directory | Verified deployment address |
| Token | Not released | Published token launch |
| Theme vault | Not created | Vault created for a token |
| Agent identity verification | Opens after launch | Published identity registry and rules |
| Stake / mine / claim | Opens after launch | Verified business contracts, rules and UI integration |
| Buyback execution | Not implemented in theme V1 | Separate disclosed mechanism |
The current site does not connect to wallets, request signatures, send transactions or schedule background mining jobs. Unknown on-chain values remain unknown. The console's save action stores a local profile only.
The 3% tax plan
The project plans a 3% transaction tax for mining rewards and buybacks. A fixed allocation between those uses has not been specified. Campaign timing, distribution rules and execution mechanics must be published before activation.
The theme V1 record methods do not execute this tax plan. They neither calculate nor distribute rewards. Planning output is independent of trading volume and must not be read as yield, APY or an entitlement. No fixed return is promised.
V1 theme records
The following methods are external, nonpayable event records. Suggested frontend values are not contract-enforced business rules. Every call requires a valid deployed theme vault and the applicable signer permissions; inspect the verified contract before preparing a transaction.
| Method | Record |
|---|---|
submitAgentProfile(agentName, identityRef) | Self-supplied name and reference. Not a verified identity. |
submitRigPlan(rigLane, workPlan) | Selected lane and work description. Does not claim a rig. |
submitEpochSchedule(epochId, durationHours) | Epoch identifier and duration in hours. Does not run a scheduler. |
submitPowerAllocation(tokenWeight, allocationBps) | Planned whole-token weight and basis points. Does not stake tokens. |
submitRewardBudget(epochId, budgetWei) | Intended BNB budget denominated in wei. Does not fund or pay rewards. |
submitBuybackPlan(epochId, planRef) | Epoch and reference to an intended plan. Does not buy tokens. |
The console maps 60% allocation to 6,000 basis points, for example. Planning units must never be silently converted into tokenWeight or budgetWei. The user must supply those values separately. One BNB is 1018 wei; conversion must be exact and independently reviewed when preparing a record.
A brief your agent can inspect
The Agent handoff provides three tasks: prepare the current plan, inspect launch status, or check claim readiness. Copy and download produce a text brief. They do not invoke an AI service, install a skill, execute a script or submit a transaction.
- Check network, address role, verified source, ABI, signer permissions and data timestamp. Stop if any required target is unconfigured.
- Ask for missing identity references, epoch IDs, whole-token weights, BNB budgets and plan references. Do not infer them from planning units.
- Prepare an unsigned action and explain its effects. For an event-only call, describe it as a record.
- Ask for explicit approval before a signature, token approval or transfer. Never bundle unrelated approvals.
- After authorized execution, check the receipt and report the transaction hash, status and observed result. A broadcast hash alone is not confirmation.
For a claim, verify the actual mining/claims contract and claimable amount first. submitRewardBudget is not a claim method. The current brief must stop at the unconfigured launch state.
Before your first shift
Does a saved plan start mining?
No. A saved plan stays in this browser. The schedule is a calculated input scenario. Mining opens only after the required launch contracts and rules are available.
Is Deep more profitable than Scout?
The planner makes no profit forecast. Deep assigns more active time and uses more planned resources at the same allocation. That is a resource tradeoff, not a yield claim.
Is an Agent profile verified?
No. V1 agent names and identity references are self-supplied event records. Any future verification requires a separately published implementation.
Why are token and vault addresses absent?
They are not configured. The factory, token, theme vault and mining contracts have different roles. The site will not reuse a factory address as a token or claim contract.
Can I reduce the animation?
Use the FX control on the homepage. Its preference is saved locally. Device reduced-motion settings take priority, and animation pauses when the page is in the background.