DualForge is a dual-key mining game that runs on BNB Chain and is accessible only to holders of Binance .ai Agent IDs. By binding each Agent ID to a deterministic element and using that element in every core formula, the protocol turns a verifiable on-chain identity into a set of transparent, auditable game mechanics. This article walks through the computations that drive pairing, rig weight, upgrades, and emissions, and shows how the contract logic enforces caps and pool-opening conditions.
1. From Agent ID to Element – a pure-function mapping
Every Binance .ai Agent ID has a bare handle (the textual identifier without the "@" prefix). DualForge derives an element from this handle with a single hash operation:
elementIndex = keccak256(bareHandle) mod 5
The resulting index maps to one of five elements in a fixed order:
| Index | Element |
|---|---|
| 0 | metal |
| 1 | wood |
| 2 | water |
| 3 | fire |
| 4 | earth |
Because the computation is a deterministic hash, anyone can run it off-chain before committing any BNB or $DFORGE tokens. The element is immutable for the lifetime of the ID. This design makes the element a public, verifiable attribute of the identity, similar to an on-chain NFT trait but without requiring an additional token mint.
2. Pairing IDs – a small combinatorial design space
A mining rig in DualForge is forged by two distinct Agent IDs, each contributing one key. The pairing process is manual: players enter a public lobby, view the elements of available partners, and select a counterpart. No automatic matchmaking occurs, which keeps the combinatorial space transparent and gives participants full control over their affinity.
Affinity is calculated from the two elements:
| Relationship | Multiplier |
|---|---|
| Same element | 2.00 |
| Generating (e.g., wood → fire) | 1.50 |
| Overcoming (e.g., water → fire) | 1.00 |
The relationship table follows the classic Wu Xing cycle: wood generates fire, fire generates earth, earth generates metal, metal generates water, water generates wood; the overcoming cycle runs in the opposite tension (metal overcomes wood, wood overcomes earth, earth overcomes water, water overcomes fire, fire overcomes metal). With only five elements, there are exactly three affinity outcomes, making the design space easy to enumerate and audit. The affinity multiplier feeds directly into each key's effective weight, which determines its share of the emission pool.
3. Rig weight, levels, and the burn-to-upgrade loop
Each key has a level, from Lv1 to Lv5; a newly minted key starts at Lv1. The level maps to a multiplier:
| Level | Multiplier |
|---|---|
| Lv1 | 1.0 |
| Lv2 | 1.8 |
| Lv3 | 3.2 |
| Lv4 | 5.5 |
| Lv5 | 9.0 |
The effective weight contributed by a key in a given cycle is:
effectiveWeight = levelMultiplier × affinity + teamBonus
teamBonus is +0.20 when the partner is a genuinely new recruit you invited, and 0 otherwise. It is added after the multiplication and is never scaled by level or affinity. The single-key cap follows directly: 9.0 × 2.00 + 0.20 = 18.2.
Level-up costs
Levels are upgraded by burning $DFORGE. The burn schedule is per step:
| Upgrade to | $DFORGE burned |
|---|---|
| Lv2 | 3,000 |
| Lv3 | 10,000 |
| Lv4 | 30,000 |
| Lv5 | 80,000 |
A key taken all the way to Lv5 burns 123,000 $DFORGE in total. Upgrades are per key and unilateral — each partner upgrades their own key, and a rig's output is split between the two keys in proportion to their weights, so whoever upgrades earns a larger share.
Paid vs. trial keys
A paid key costs 0.01 BNB; a rig therefore requires 0.02 BNB in total. Each Agent ID may own up to 10 paid keys, and the entire system caps at 10,000 paid keys. For onboarding, DualForge offers 5,000 trial rigs. An ID can claim a single trial key for a nominal 0.00011 BNB. The trial key's weight is:
trialWeight = 0.1 × affinity × teamFactor
teamFactor equals 1.20 if the partner is a newly recruited invitee, otherwise 1.00.
4. Emission distribution and pool-opening thresholds
DualForge uses an equal-split emission model. The paid-key emission pool keeps 10% in reserve for the post-sale ember period; the remaining 90% is the sale-period pool. In each round the protocol computes:
roundEmission = remainingPool / remainingRounds
All rigs that ignite during that round split roundEmission in proportion to their keys' effective weights. Because the weight already incorporates the affinity multiplier and level, the distribution rewards higher-affinity pairs and upgraded keys without any extra weighting logic.
Caps and liquidity-pool triggers
- Key caps: 10,000 paid keys total, max 10 per ID.
- Pool opening: If 2,000 keys become paired before day 10, the mining pool opens early. Otherwise, on day 10 the pool opens provided at least 1,000 keys are paired. If fewer than 1,000 keys are paired, the sale is cancelled and only the liquidity-pool portion of the key price is refunded — a partial, difference-only refund.
These thresholds are transparent and can be monitored on-chain. The early-opening rule encourages participants to coordinate pairings quickly, while the day-10 fallback ensures the protocol can still launch with a smaller but viable base.
Closing note
DualForge's design shows how a verifiable on-chain identity (the Binance .ai Agent ID) can be turned into a deterministic game mechanic: every calculation — element derivation, affinity, weight, upgrade cost, and emission split — is reproducible off-chain and enforced on-chain. The sale window opens on October 30, 2026 at 18:00 CST (UTC+8) and runs for ten days, followed by a fourteen-day ember period for existing pairs. Full specifications: https://dualforge.fun and the whitepaper at https://dualforge.fun/whitepaper. Updates: https://x.com/DualForgeBSC. Contracts are deployed and source-verified on BSC mainnet (ForgeCore 0x60D9531378911b39248Dec7170AE661360d6F29c, $DFORGE 0x7c8E12714f7E582Ad8163a09bAb49Fd28CA673fd).
Anyone can reproduce the keccak256-mod-5 element function and check a prospective partner's element before pairing — that check is the first strategic decision in the game.
Top comments (0)