By Heath Muchena · Sources reviewed 13 November 2026 · Original DN analysis and illustrative records
What Matters
Check permission for the exact task before counting its rewards. A game may distinguish modes, active battles, analysis tools and separately agreed exceptions. Technical access, task permission and reward eligibility need different evidence.
An AI can plan a strategy, summarize a match or control software. Those capabilities do not answer whether a game permits the proposed delegation—or whether the resulting activity qualifies for a reward.
This guide uses published Axie and Splinterlands rules to show why the boundary must be specific. It does not rank earning opportunities, provide an automated player or promise revenue. The DN record is a local evidence worksheet; it has no connection to a game or wallet.
The DN thesis
Define the task narrowly enough that the relevant rule can be applied. Keep the permission record separate from account access and reward eligibility, and preserve missing evidence before a software capability becomes an assumed entitlement.
1. Name the exact game, mode, task and phase
“Let an AI play my game” is too broad for a permission review. Break the proposal into a named task: summarize completed matches, suggest a team during an active battle, submit moves, manage a permitted administrative process or transfer an asset. Then record the game, mode, bracket and relevant season.
Splinterlands’ March 2026 terms restrict automated play and outside assistance in specified battle formats. The active-battle boundary matters: a tool that only suggests a decision can still fall within those restrictions. [3] Its Survival FAQ separately describes an automated-play setting for individual brackets. [4] One mode’s rule should not be copied to another.
The worksheet compares exact declared task, mode and phase labels. A policy reference for historical analysis does not match a proposal to act during a live battle. If a rule is unclear, preserve that uncertainty instead of choosing the interpretation that makes a projected earning strategy possible.
2. Read the current rule and any required exception
Start with the operator’s current terms and the specific event or mode rules. A software repository, a marketplace listing or another player’s use of a bot does not establish permission. Record the document version and the scope that applies to the proposed activity.
Axie’s published terms restrict automated or non-human access, with specified purposes subject to a separate written agreement. [1] The exception is not automatically obtained because the task resembles an example in a list. An older announcement should not silently replace the current agreement or a narrower event rule.
In the DN record, “allowed,” “prohibited” and “exception required” are descriptions entered from evidence. A required exception needs its own scope and reference. Even a reported covering exception produces a conditional result: the tool has not authenticated the permission, checked every condition or authorized software to run.
3. Separate technical access from authority to use it
A wallet or game account can expose several operations. Permission to read a record, submit gameplay, claim a balance, rent an item and transfer an asset should be reviewed separately. The ability to sign a transaction does not establish that the game permits the intended activity.
Splinterlands’ key guide distinguishes posting, active and owner permissions, with different operations attached to those keys. [5] This is a technical access model, not a statement that an automated player may use every operation in every format.
Document who owns the account and assets, who can authorize the task and which access is actually necessary. Do not give an assistant a seed phrase, master password or raw private key to complete this worksheet. Keep the real access configuration in a controlled record and use a short reference here.
A change in the delegated task should reopen the permission review. An inventory summary should not quietly grow into a tool that submits battles or moves valuable items.
4. Check reward eligibility independently of task permission
A permitted activity and a reward-eligible result are separate propositions. The account, assets, event, season, participant and conduct rules may all matter. A successful API response or completed match does not by itself establish a payable claim.
Sky Mavis’ support guidance says owners remain responsible for scholars’ violations on accounts they control, and describes restrictions on SLP claims and receipt for accounts with banned Axies. [2] This is a concrete reason to inspect consequences for the particular account and assets instead of assuming that delegation transfers responsibility.
The worksheet keeps a reward-eligibility reference separate from the task’s permission. Reported eligibility remains conditional; ineligibility is a visible conflict even if the task is otherwise described as allowed. The tool does not infer eligibility from possession of an NFT, a high rank or an agent’s claim that it followed the rules.
Do not create more accounts, disguise automation or manipulate matches to work around an unresolved restriction.
5. Reconcile activity, rewards and receipts before calling it income
Keep match outcomes, in-game balances, claim events, token receipts and cash conversions as separate evidence. An agent’s estimated reward should not be substituted for a platform record. Nor should a transfer between reward categories be counted as a second earning event.
Splinterlands’ CSV guide describes transaction types, amounts, dates and IDs. It also explains that claiming can reduce an unclaimed balance while moving the amount into another category. [6] A negative unclaimed entry therefore needs its event context; it is not automatically a lost reward or a new cash expense.
Record rental, access, network, service and human-review costs where they actually arise. Distinguish a token quantity from a cash valuation, and distinguish a forecast from a completed receipt. This guide supplies no expected win rate, daily earning estimate or return comparison between people and agents.
For this permission record, retain only an evidence alias. The tool is deliberately not another trading or income calculator.
6. Give the review an owner and a change boundary
A permission record should say who will revisit it when the game, mode, task, rules or exception changes. A record made for one season can be useful history without remaining an authorization for the next. An agent’s own confidence is not a substitute for that review.
Define what the assistant is allowed to do while a question is unresolved. For example, organizing redacted documents may be within the user’s instruction while submitting an active battle remains outside the proposed delegation. That boundary must also respect the operator’s rules; “read-only” analysis is not automatically permitted during every competitive event.
Keep evidence of the scoped permission and the ability to manage the account independently. If access is withdrawn, separately verify the state of any asset or reward process already started. This worksheet does not revoke keys, stop other software, submit an appeal or recover an account.
The useful handoff is compact: this game, this task, this rule, this exception if required, this responsible owner and these unanswered conditions.
DN Game Automation Permission Record
Describe one proposed task. Compare its mode, task and phase with a current policy record. Use aliases only. The output never grants permission, starts a game or requests credentials.
No current calculation. Enter a record or load a labelled example.
This worksheet sends no entered values to a server, connects to no account and stores no input in browser storage. Downloads contain the entries you supplied. Use aliases rather than private data. Other site services remain subject to the site’s privacy policy.
Labelled examples and practical use
The first fictional case matches MODE-A and TASK-HISTORY-A outside an active battle to the same labels in POLICY-A-v2. It reports a scoped permission but remains conditional. It does not establish that any real game permits that task.
Other cases show a prohibition, a missing required exception, a reported exception whose conditions still need review, a policy for another mode and an allowed task with an ineligible reward. All six cases are invented. A mismatch prevents the rule from being reused; it does not decide what the correct rule would be.
Methodology, assumptions and limits
The model accepts eighteen short fields. A task-policy comparison requires a game context, both task and mode labels, both phases, a policy reference and a reader declaration of comparable context. It compares exact trimmed labels, case-sensitively. Different context is outside scope; missing evidence is unknown.
A matching reported prohibition produces a record conflict. A scoped permission remains conditional. A required exception remains unknown without coverage and evidence; a reported non-covering exception conflicts, while a covering reference remains conditional. Account authority, reward eligibility and review responsibility are independent findings. There is no score, live policy lookup, legal certification or game action.
Sources were checked on 13 November 2026. Axie’s public terms carry a January 2024 revision date and its ban article an October 2024 date; those dates are retained rather than presented as new rules. Splinterlands’ terms are dated March 2026, and Survival settings remain bracket-specific. Historical announcements are not used as blanket permission. No account, season outcome or reward receipt was tested.
Frequently asked questions
Does owning a game asset permit an AI to play with it?
Ownership and gameplay permission are separate. Axie’s published terms restrict automated access and make specified exceptions subject to a separate written agreement. [1]
Can a decision helper be restricted even if it never clicks?
Yes. Splinterlands’ policy restricts external assistance during active battles in named formats, not only automated submissions. [3]
Do all game modes have the same automation rule?
No such assumption is justified. Splinterlands’ Survival documentation makes automated play a bracket-specific setting. [4]
Does a conditional result mean I may run the tool?
No. It means the entered record still has conditions the worksheet cannot authenticate or resolve. The worksheet grants no game, account or legal permission.
Primary sources
Reviewed13November2026. A publication or export time does not refresh the evidence.
- Axie Infinity Terms of Use — Current public terms, last dated January 2024: automated access restriction and separately agreed exceptions.
- Sky Mavis: banned Axies and appeals — Published support description of gameplay automation restrictions, owner responsibility and SLP limits.
- Splinterlands Terms of Service — March 2026 terms; named battle-format and active-battle assistance restrictions.
- Splinterlands Survival Mode FAQ — Bracket-specific automated-play setting; not blanket permission across every game mode.
- Splinterlands Hive Keys — Technical account permission types; not authorization under gameplay rules.
- Splinterlands Currency Activity CSV FAQ — Exported transaction fields and unclaimed-to-claimed bookkeeping; not verified earnings or complete tax records.
Turn the unresolved question into a research brief
For a scoped review of the public documents behind a claim, explore the DN Research Desk. An enquiry is subject to agreed scope and capacity; it does not certify a deployment, establish an entitlement or commit you to a paid service.
Disclosure: this article promotes DN’s own research service. Commercial enquiries do not purchase a favorable conclusion. No external provider is promoted through an affiliate link here.
Related DN research
About the Author
