Owner transaction integrationLink to this section

Before you startLink to this section

Use the pinned Mining5 ABI and an explicitly approved deployment record; this site does not identify a live Mining5 deployment. Complete the graph identity checks, then use the connected owner's account and expected chain.

Read current collection ownership, not an old portfolio response. A contract wallet must call Mining itself; its signer acting separately is not the NFT owner.

Core pause blocks Mining checkpoints, not already-funded claims, NFT transfers or Mining merges. Mint and merge still require working fixed dependencies; NFT mint pause is a separate gate.

StepsLink to this section

1. Select claim IDs in ascending numeric order, remove duplicates and keep the batch at most 32. For a merge, explicitly choose which ID survives and explain that the donor cannot be restored.
2. Read ownerOf for every selected ID at current chain state. For merges, read both Mining positions, configuration().maximumLevel, and Core state().blockHeight.
3. Reject a merge if either position has pending activation, is at the maximum Level, differs in Level from the other, or has nextMergeBlock above completed Core height. Time passing or Ethereum blocks advancing is not enough.
4. Simulate from the actual owner account using the pinned Mining5 ABI. Handle the exact custom error instead of silently changing the selected IDs.
5. Present the simulated action, chain, Mining address, IDs and irreversible effects to the owner. Request wallet signing and submission only with the owner's authorization; the example below stops before that step.
6. After a user-authorized transaction, inspect its canonical receipt and subsequent state. Do not mark a transaction successful from a hash or a submitted status alone.

Claim preflightLink to this section

Read claimable(ids) for the validated selection and record the Ethereum block. The estimate does not check ownership or guarantee payment when the transaction executes; claims, merges, transfers, or later funding can change it.

No NFT approval, ERC-20 approval, permit, staking deposit, or checkpoint is required. Claims do not read Core; pending activation and Core unavailability alone do not prevent withdrawal of already-funded credit.

Merge preflightLink to this section

Read both positions at the same Ethereum block: active mining power, scaled unclaimed rewards, pending activation and nextMergeBlock. Record which ID survives: it keeps its ID and visuals, while the donor burns permanently.

Below the maximum Level, the survivor's next merge threshold is the current completed Core height plus the new Level's cooldown. At the maximum Level the threshold is zero, but further merging is forbidden.

Simulation-only exampleLink to this section

The client, mining, collection, and owner values below must come from the verified graph and current wallet context. This performs RPC reads and eth_call simulation only.

import { parseAbi } from "viem";

const ownerAbi = parseAbi([
  "function ownerOf(uint256 tokenId) view returns (address)",
]);
const miningAbi = parseAbi([
  "function claim(uint256[] tokenIds) returns (uint256 paid)",
  "function merge(uint256 survivorId, uint256 donorId)",
  "error Unauthorized()",
  "error InvalidClaim()",
  "error InvalidPosition()",
  "error InvalidMerge()",
  "error PendingActivation(uint256 tokenId, uint64 round)",
  "error CooldownActive(uint256 tokenId, uint64 nextMergeBlock)",
]);
const ids = [1n, 2n]; // Example selection, not a claim of ownership or issuance.
for (const id of ids) {
  const actualOwner = await client.readContract({
    address: collection, abi: ownerAbi, functionName: "ownerOf", args: [id],
  });
  if (actualOwner.toLowerCase() !== owner.toLowerCase()) {
    throw new Error(`Caller does not own ${id}`);
  }
}
const simulation = await client.simulateContract({
  address: mining,
  abi: miningAbi,
  functionName: "claim",
  args: [ids],
  account: owner,
});
console.log("Simulated payout in SQK base units:", simulation.result);
// No wallet write is performed.

Use the full source ABI to decode errors from dependencies or inherited code. A successful simulation describes one point in time; transfers and other transactions can change state before your transaction executes.

Expected resultLink to this section

A claim increases Mining's paid total by the payout and emits RewardsClaimed(owner, amount, remainderScaled, tokenIds). It pays whole SQK base units (10^-18 SQK each) and keeps any fractional base-unit credit as remainderScaled on the lowest selected ID.

For a nonzero payout, check that the bound Token's transfer matches the owner and RewardsClaimed.amount. A zero payout still combines fractional credit on the first ID and emits RewardsClaimed, but makes no Token transfer.

A merge emits the NFT burn Transfer and Mining's PositionsMerged. The survivor keeps all scaled unclaimed rewards and uses the inputs' combined old mining power until the new Level's replacement mining power activates.

Common failuresLink to this section

Verify the resultLink to this section

Check receipt status, graph address and exact events, then re-read ownership, both positions and Token balance at a consistent block. For a merge, ownerOf(donor) must no longer succeed and position(donor).level is zero; verify the survivor's level, combined old active weight, preserved scaled credit, pending replacement weight, activation round, and resulting cooldown.

Keep confirmations and the block hash with the result. Display pending transactions separately from confirmation-safe API data, which may not yet include the receipt block.

SourceLink to this section

Mining5 source specification e0617449. First-party source is private; see source and release scope.

Related pagesLink to this section

• Read contracts
• Getting a Miner
• Ownership and transfers
• Claiming rewards
• Merging Miner NFTs
• Events and errors