Preliminary MiCA / EMT / PSD2 Perimeter Analysis

Milestone 2 Final Draft v1.1

Date: 16 September 2026

Status and purpose

This memorandum provides a preliminary regulatory analysis of the current VersusArena USDC architecture under Regulation (EU) 2023/1114 on Markets in Crypto-assets (MiCA) and the separate payment-services overlap arising because USDC is an e-money token (EMT) in the EEA. It focuses on: (i) custody and administration of crypto-assets on behalf of clients, (ii) transfer services for crypto-assets on behalf of clients, and (iii) the potential application of Directive (EU) 2015/2366 (PSD2) to EMT settlement flows.

The analysis is based on the product and developer facts currently confirmed by VersusArena, including the User-Controlled Wallet structure, the funded tournament smart-contract model, the three predefined settlement Outcomes, the restricted administrator role during Competition result review, the emergency refund limitation, the confirmed self-funded and captain-funded team models, and the current upgradeability requirement.

This is a preliminary perimeter analysis, not a formal regulatory opinion or competent-authority clearance. The conclusion depends on the technical implementation matching the factual assumptions set out below. The MiCA and PSD2 analyses are separate: a defensible position outside the MiCA transfer-service perimeter does not by itself determine whether an EMT-related activity is outside PSD2. If the EEA becomes a material launch market, the final implementation should be checked against the deployed smart-contract permission model and, where a high-reliance opinion is required, confirmed with relevant EEA payment and crypto regulatory counsel.

1. EXECUTIVE SUMMARY

The current architecture materially improves VersusArena's position compared with the earlier Developer-Controlled Wallet / Treasury model.

At the User-Controlled Wallet level, the custody case is relatively strong. Users control the wallet credentials or keys through Circle's User-Controlled Wallet architecture and personally authorise sensitive wallet actions. VersusArena does not receive the private key and cannot perform unrestricted server-only transfers from the user's wallet. On the currently confirmed facts, this strongly supports the position that VersusArena is not providing custody and administration of the User-Controlled Wallet itself.

The more important MiCA question arises after the user voluntarily transfers a specific Participation Amount into the Tournament Smart Contract. The smart contract temporarily contains participant USDC until a Final Outcome is submitted and the predetermined payout or refund logic executes. The fact that assets are in a smart contract does not by itself answer the custody question. The relevant issue is whether VersusArena can safeguard or control those assets on behalf of users through administrative, upgrade, pause, emergency, rescue, settlement or other permissions.

The currently confirmed limitations are favorable. After funding, the participating sides, source wallets, Participation Amounts, prize structure, 10% Platform Fee, payout logic and refund logic are fixed. The backend cannot set an arbitrary recipient or amount. VersusArena may submit only Team A Wins, Team B Wins or Void/Refund. Emergency handling is limited to returning funds to the original payers. If these limitations are technically real and cannot be bypassed through another administrative function, the custody risk is substantially reduced and there is a strong basis to argue that VersusArena does not exercise the type of asset control contemplated by MiCA custody.

Transfer-service analysis is less binary. MiCA defines transfer services by reference to a service of transferring crypto-assets from one DLT address or account to another on behalf of another person. The strongest argument for VersusArena is that its ordinary role is not to receive or execute a user's transfer instruction. It determines the Competition result, submits only a predefined result state, and the smart contract independently calculates the corresponding recipients and amounts from parameters accepted before funding.

The result-review function increases regulatory sensitivity because an administrator may choose between Team A Wins, Team B Wins and Void/Refund, and that choice determines which pre-programmed settlement branch executes. However, this does not automatically make the activity a transfer service. The legal characterization remains materially stronger if the administrator is genuinely adjudicating the Competition result under pre-agreed rules, is technically limited to the same three predefined Outcomes, cannot choose a wallet or amount, cannot alter the fee, cannot create a new payment path, and cannot use another administrative function to redirect assets.

The key residual transfer-service risk is that MiCA's definition does not expressly require the service provider to have discretion over the destination or amount. A regulator could focus on the fact that VersusArena's submission of the Final Outcome is a necessary causal input for the on-chain movement. There is currently no directly applicable published ESMA Q&A addressing a competition-result oracle with this fact pattern. The conclusion is therefore interpretive rather than settled by specific regulatory guidance.

Separately, USDC is treated as an e-money token in the EEA. The European Banking Authority has advised national authorities to treat transfers involving EMTs as payment services under PSD2 where they are carried out on behalf of clients, and the transitional supervisory period identified by the EBA ended on 2 March 2026. VersusArena has favorable facts because it does not maintain a general-purpose client balance or custodial wallet, does not receive a post-match instruction to send a chosen amount to a chosen address, and the Tournament Smart Contract applies payout and refund routes fixed before funding. These facts support an argument that VersusArena is providing a Competition and result-determination service rather than a standalone payment service. However, the PSD2 analysis is functional and must remain separate from the MiCA conclusion.

The captain-funded model requires additional care. Where a captain funds team Participation Amounts and the winning payout is distributed among teammate wallets, one person's funded EMTs may ultimately settle to third-party Participants. The position remains stronger where the payout mode and allocation are fixed before funding, VersusArena cannot alter recipients or amounts after funding, and every refund returns to the Original Payer. Even so, this flow presents greater PSD2 sensitivity than a simple self-funded flow and should receive EEA-specific confirmation before a high-reliance launch.

Preliminary risk position:

• User-Controlled Wallet custody: LOW, assuming the Circle architecture operates as confirmed.
• Smart-contract custody/control: LOW TO MODERATE, depending principally on pause, upgrade, rescue and any hidden administrative permissions.
• Ordinary server-result transfer-service risk: LOW TO MODERATE, with a defensible position outside the transfer-service perimeter.
• Result-review / administrator Outcome selection: MODERATE, but still defensible outside the perimeter if the administrator is limited to genuine Competition adjudication and cannot formulate payment instructions.
• Emergency refund function: generally favorable if it can only return funds to original payers.
• Upgradeability: key unresolved gating point. A power to modify funded Competition economics or settlement logic would materially weaken both custody and transfer-service positions.
• PSD2 / EMT payment-services overlap: MODERATE residual perimeter risk for the current EEA settlement architecture, with additional sensitivity for captain-funded split payouts. The architecture has material arguments against characterization as a standalone payment service, but the issue is not resolved merely by remaining outside the MiCA transfer-service perimeter.

2. RELEVANT MICA FRAMEWORK

2.1 Custody

MiCA Article 3(1)(17) defines providing custody and administration of crypto-assets on behalf of clients by reference to the safekeeping or controlling, on behalf of clients, of crypto-assets or of the means of access to those crypto-assets, including private cryptographic keys where applicable.

The definition is therefore broader than the simple question of who physically possesses a private key. A business can present custody risk if it has substantive control over client crypto-assets even where it does not hold the user's personal wallet key.

For VersusArena, this means the analysis must be performed at two separate levels:

(a) control of the User-Controlled Wallet; and

(b) control of USDC after it enters the Tournament Smart Contract.

2.2 Transfer services

MiCA Article 3(1)(26) defines providing transfer services for crypto-assets on behalf of clients as providing services of transfer, on behalf of a natural or legal person, of crypto-assets from one distributed-ledger address or account to another.

Article 82 then regulates CASPs providing transfer services and requires, among other things, a client agreement describing the modalities of the transfer service, security systems, fees and applicable law.

ESMA's final Guidelines on transfer services under MiCA apply to firms that already fall within Article 3(1)(26). They are useful in showing that the regulated service is conceived as a client-facing transfer service with identifiable transfer modalities and client rights, but they do not create a separate bright-line test for when an automated smart-contract event becomes such a service.

2.3 The importance of the phrase on behalf of

ESMA Q&A 2417, answered on 18 June 2026, confirms that both custody and transfer definitions depend on the service being provided on behalf of another person. In that Q&A, an issuer sending its own issued tokens to purchasers was not considered to be providing custody or transfer services on behalf of another person.

That Q&A is not directly analogous to VersusArena, but it is useful because it confirms that the existence of an on-chain transfer is not sufficient by itself. The legal role in which the relevant person acts matters.

2.4 Smart contracts and central control

MiCA Recital 22 states that crypto-asset services provided in a fully decentralised manner without an intermediary should not fall within MiCA. VersusArena should not rely on this as a safe harbor. VersusArena is an identifiable operator, runs the Competition environment and provides the result input. The relevant objective is therefore not to label the model fully decentralised, but to determine whether VersusArena actually performs one of MiCA's enumerated crypto-asset services.

The January 2025 Joint EBA-ESMA Report on recent developments in crypto-assets is relevant to the control analysis. It notes that smart-contract standards can help authorities assess whether software is genuinely self-executing or whether a central entity retains editing or other control permissions, such as administrator keys, or special rights embedded in the code. This supports focusing on the actual permission map rather than the label attached to the smart contract.

3. USER-CONTROLLED WALLET AND CUSTODY

3.1 Confirmed architecture

Based on the information provided by the client and Circle correspondence:

• the end user controls the User-Controlled Wallet credentials or keys as implemented by Circle;
• sensitive wallet actions require user approval through the relevant Circle approval flow;
• VersusArena does not obtain the user's private key or equivalent authentication secret;
• VersusArena cannot perform unrestricted server-only transfers from the user's User-Controlled Wallet;
• Circle applies its own platform-level sanctions, watchlist and blockchain-analytics controls independently of VersusArena.

3.2 Preliminary legal assessment

These facts strongly reduce the risk that VersusArena is the custodian of the user's User-Controlled Wallet. The platform provides an interface and product integration, but the user authorises sensitive wallet operations and VersusArena does not possess the means of access that would allow it to move assets from the wallet at will.

The conclusion should nevertheless remain factual rather than promotional. Product copy should say that the wallet is user-controlled and that sensitive actions require user approval. It should avoid unqualified regulatory claims such as VersusArena is not a CASP or VersusArena never controls funds because the separate Tournament Smart Contract stage still requires analysis.

Preliminary conclusion: the User-Controlled Wallet itself presents a LOW custody risk for VersusArena on the currently confirmed facts.

4. FUNDS IN THE TOURNAMENT SMART CONTRACT

4.1 Confirmed architecture

Each Payer personally authorises the specific Participation Amount or aggregate Participation Amounts that the Payer is funding for a specific Competition. No unlimited token allowance is used. In a captain-funded team Competition, the funding method and the winning-payout mode are fixed before funding: the payout is either to the captain or distributed among the winning team's Participants according to the pre-agreed allocation. Any refund is returned to the applicable Original Payer.

After funding, the following are fixed for the funded Competition:

• participating sides / participants;
• Funding Wallets or source wallets;
• Participation Amounts;
• prize structure;
• 10% Platform Fee;
• payout logic; and
• refund logic.

The backend cannot replace the recipient, enter a new recipient, choose an arbitrary payout amount, change the fee recipient after funding or change the funded participant composition.

4.2 Why the smart-contract stage matters

USDC is no longer in the user's personal wallet during this period. It is committed to a smart contract and will move only when the applicable contract conditions are satisfied. The custody analysis therefore depends on whether VersusArena has a substantive ability to control those assets through the contract.

A smart contract that is described as autonomous but can in practice be upgraded, rescued, drained, redirected or rewritten by an administrator can still create a materially different regulatory profile from an immutable or tightly constrained contract.

4.3 Current assessment

The present design materially limits asset control. VersusArena's role is restricted to submitting an allowed Competition Outcome and using narrowly defined emergency or administrative functions. The payout destination and amount are not generated by the backend after funding.

That is favorable for the custody analysis because the operator does not appear to have a general power to safeguard and dispose of participant USDC for users. It has a limited role in determining a factual or contractual condition that the smart contract uses to execute pre-agreed logic.

However, the final position depends on the complete permission map. In particular, a broad pause, rescue or upgrade key can be legally important even if the ordinary user interface never exposes that power.

Preliminary conclusion: smart-contract custody risk is LOW TO MODERATE, capable of being reduced toward LOW if the final deployed permissions confirm that VersusArena cannot redirect, extract, reassign or retroactively reprogram funded Competition assets.

5. ORDINARY SERVER-RESULT FLOW

5.1 Confirmed flow

In the standard case:

1. The relevant Payers fund the Competition under predetermined parameters, including any captain-funded payout allocation disclosed before funding.

2. The match is played on the VersusArena-controlled or integrated game infrastructure.

3. Official Match Data, including server records, MatchZy data, logs and demos, establishes the competitive result.

4. The VersusArena backend submits only Team A Wins, Team B Wins or Void/Refund.

5. The Tournament Smart Contract determines the recipients and amounts from the already fixed Competition parameters.

6. The contract executes the payout, fee routing or refund.

5.2 Transfer-service analysis

The stronger legal characterization is that VersusArena provides a Competition and result-determination service rather than a crypto-asset transfer service.

The user does not instruct VersusArena after the match to transfer X USDC to wallet Y. The user already accepted the settlement formula before funding. VersusArena does not formulate the payment details. It supplies the factual result state required by the Competition rules, and the contract applies the pre-existing financial logic.

This distinction is important because MiCA regulates transfer services performed on behalf of another person. ESMA Q&A 2417 supports the proposition that an on-chain movement is not automatically a regulated transfer service merely because a business action is connected to the transfer. The legal capacity in which the business acts remains relevant.

The principal counterargument is causation. No settlement occurs until VersusArena submits the result. A regulator could therefore ask whether submission of the Final Outcome is in substance the execution trigger for a transfer on behalf of participants. MiCA does not expressly require the service provider to choose the amount or destination before Article 3(1)(26) can apply.

On balance, the ordinary server-result flow is materially more defensible outside the transfer-service perimeter than a model where VersusArena receives payout instructions, chooses recipients, calculates amounts or manually initiates individual transfers.

Preliminary conclusion: LOW TO MODERATE transfer-service risk in the ordinary flow, with a credible and commercially usable argument that VersusArena is providing Competition result determination rather than a transfer service.

6. DISPUTE / ADMINISTRATOR OUTCOME SELECTION

6.1 Confirmed review model

Where a Competition result is disputed, an authorised VersusArena reviewer may select only one of the same predefined Outcomes:

• Team A Wins;
• Team B Wins; or
• Void/Refund.

The reviewer cannot:

• insert a wallet address;
• change a recipient;
• choose an arbitrary amount;
• change the 10% Platform Fee;
• change the fee recipient;
• add or remove a funded participant;
• create a new settlement branch; or
• manually redistribute participant USDC.

6.2 Why dispute review is more sensitive

In the ordinary flow, VersusArena can characterize its input as the transmission of an objectively verifiable server result. During a dispute, the administrator exercises judgment. The administrator may review logs, demos, technical evidence, anti-cheat information and participant evidence and decide which of the three predefined Outcomes correctly applies.

That decision has a direct economic effect because it determines which branch of the smart contract executes. The result-review function therefore creates greater transfer-service sensitivity than a purely automatic server-result feed.

6.3 Why the review function does not automatically become a transfer service

The administrator's legal task is still capable of being characterized as Competition adjudication rather than payment execution.

The relevant distinction is:

Competition adjudication model:

administrator determines the correct Competition Outcome -> smart contract determines recipients and amounts -> contract executes pre-agreed settlement.

Payment-instruction model:

administrator determines who should receive what amount -> platform instructs or executes that transfer.

VersusArena is intentionally designed to remain in the first model.

The fact that a legal or factual decision has economic consequences does not by itself transform the decision-maker into a payment or transfer service provider. Referees, claims administrators, marketplaces and dispute-resolution functions can make decisions that trigger pre-agreed economic consequences without necessarily becoming the provider of the underlying payment service. For MiCA, however, the analysis remains fact-specific because the Final Outcome is also the on-chain execution trigger.

6.4 Factors that strengthen the non-transfer characterization

The position is stronger if:

• the grounds for Team A Wins, Team B Wins and Void/Refund are set out in the Competition Rules or Competition Parameters before funding;
• the administrator's mandate is expressly limited to determining the correct Competition result or permitted result consequence;
• the reviewer cannot formulate payment details;
• the reviewer cannot use a separate admin function to achieve a payment result that is unavailable through the three Outcomes;
• evidence and result-review procedures are documented and consistently applied;
• payout and refund formulas are fixed before funding;
• the review occurs before Final Outcome submission and on-chain Settlement;
• no general power exists to seize, redirect or forfeit participant USDC.

6.5 Factors that would weaken the position

The position would be materially weaker if:

• the administrator can substitute a recipient;
• the administrator can enter or modify an amount;
• the administrator can transfer to a platform-controlled rescue wallet and later decide where funds go;
• the administrator can change the funded payout formula;
• the dispute function is used as a general payment-routing function rather than genuine Competition adjudication;
• the platform can create ad hoc settlement states after funding; or
• a broad upgrade or admin key can bypass the nominal three-Outcome limitation.

6.6 Preliminary conclusion on arbitration / result review

The administrator's ability to select one of three predefined Outcomes increases transfer-service risk from LOW TO MODERATE in the ordinary flow to MODERATE in the dispute flow. It does not, on the current facts, require the conclusion that VersusArena is providing a MiCA transfer service.

The strongest position is that the administrator resolves a contractual Competition result under predetermined rules, while the smart contract, not the administrator, performs the financial calculation and execution. This should be reflected consistently in the Competition Rules, Terms of Use, internal procedures and product terminology.

The term arbitration should generally be avoided for this internal Competition process because it can be confused with formal legal arbitration. Competition result review, result adjudication or similar language is preferable.

7. EMERGENCY / REFUND FUNCTIONS

7.1 Confirmed limitation

The client has confirmed that emergency handling is intended to permit only a refund to the original Funding Wallets / original payers. There is no intended emergency function allowing VersusArena to withdraw participant USDC to itself or redirect it to an arbitrary address.

7.2 Legal effect

This is favorable. A narrowly constrained refund function is substantially less problematic than a general rescue or withdrawal key because it does not give VersusArena freedom to determine the destination of participant assets.

The legal analysis should still examine who can activate the refund, whether the function can be used at any time, and whether the code truly restricts the destination to original payers. The ability to decide that a Competition is Void/Refund remains an economically relevant decision, but the asset-routing discretion is tightly limited.

If a pause function exists, it deserves separate attention. A pause that only stops execution temporarily and cannot alter recipients or amounts is less concerning than a pause combined with a rescue or upgrade power. Nevertheless, an indefinite unilateral ability to prevent users from receiving settlement can itself be evidence of a degree of control and should not be treated as legally irrelevant.

Preliminary conclusion: the emergency refund design is favorable to the non-custody and non-transfer positions, subject to confirmation that there is no hidden alternative rescue path.

8. UPGRADEABILITY

8.1 Current requirement

The client has instructed developers that any new contract version must apply prospectively and must not alter the economic or settlement logic of a Competition that was already funded.

8.2 Why this is critical

Upgradeability is one of the most important remaining perimeter facts. A nominally fixed contract can provide little regulatory protection if an operator-controlled proxy, implementation contract or administrator key can change the logic governing assets already deposited.

A power to modify an already funded Competition could be evidence that VersusArena retains effective control over participant assets. It could also undermine the argument that payout and refund instructions were fully determined before funding.

8.3 Preferred legal outcome

From a legal-perimeter perspective, the relevant requirement is outcome-based rather than a technical coding prescription:

• a funded Competition's participants, source wallets, Participation Amounts, payout formula, refund formula and Platform Fee should not be alterable by a later contract upgrade;
• a new implementation may apply to future Competitions;
• if an existing funded Competition cannot safely continue, the available protective response should be limited to a predefined refund or another legally justified mechanism that does not create discretionary redirection of participant assets.

The legal team does not need to prescribe the developers' technical implementation. The legal task is to verify that the implementation does not confer powers inconsistent with the perimeter assumptions used in this memorandum.

Preliminary conclusion: upgradeability remains a GATING ISSUE for the final custody/control assessment.

9. PRELIMINARY OVERALL CONCLUSION

On the currently confirmed architecture, VersusArena has a materially stronger MiCA perimeter position than under a custodial Treasury model.

Custody

There is a strong basis to conclude that VersusArena does not provide custody of User-Controlled Wallets. There is also a credible basis to remain outside smart-contract custody if the final contract does not give VersusArena the ability to withdraw, redirect, reassign, rescue to an arbitrary address or retroactively change settlement rights over funded participant USDC.

Transfer service

There is a defensible basis to characterize the ordinary activity as Competition result determination followed by automated execution of a user-approved smart-contract arrangement, rather than providing transfer services on behalf of clients.

The administrator result-review function increases the risk because VersusArena exercises judgment over the Outcome that causes a particular settlement branch to execute. However, the risk is materially contained by the administrator's inability to determine addresses or amounts and by the requirement that the administrator choose only among settlement paths fixed before funding.

The transfer-service conclusion is therefore not no risk. A regulator could take a broader functional view of the Final Outcome submission as an execution service because it is a necessary trigger for transfers of participant USDC. There is no directly applicable published ESMA interpretation that conclusively resolves this particular competition-oracle model.

For current drafting and MVP planning, the architecture can reasonably be treated as presenting a defensible non-custody and non-transfer-service position under MiCA, subject to the final technical-permissions check and target-market regulatory reliance requirements. This MiCA conclusion does not automatically resolve the separate PSD2 perimeter because USDC is an EMT in the EEA. The payment-services analysis in Section 12 should therefore be treated as an independent launch consideration.

10. TECHNICAL FUNCTIONS THAT COULD CHANGE THE CONCLUSION

The following functions or facts would require immediate re-analysis and could materially increase MiCA custody or transfer-service risk:

1. Any VersusArena-controlled function capable of withdrawing participant USDC from a funded Tournament Smart Contract to an arbitrary address.

2. Any ability to change the payout recipient after funding.

3. Any ability to change a payout or refund amount after funding.

4. Any ability to change the Platform Fee or fee recipient for an already funded Competition.

5. Any ability to change the funded participant composition or substitute wallets after funding.

6. Any emergency or rescue function that sends participant assets to a platform-controlled wallet for later discretionary distribution.

7. Any upgrade, proxy-admin or implementation-change power capable of modifying the economics or settlement rights of already funded Competitions.

8. Any settlement function that allows the backend or administrator to submit payment instructions containing recipient addresses or amounts instead of only the predefined Competition Outcome.

9. Any additional Outcome that permits discretionary forfeiture, confiscation or redistribution without being fixed and disclosed before funding.

10. Any arrangement where the platform receives client instructions to send USDC to third parties and executes those instructions as a service separate from Competition result determination.

11. Any move back to a pooled Treasury or internal ledger where VersusArena controls withdrawals or settlement balances on behalf of users.

12. Any change to the confirmed captain-funded model that permits VersusArena to determine, after funding, how the captain's Participation Amounts are allocated among other Participants. Under the current model, the payout mode and allocation must be fixed before funding, and refunds must return to the applicable Original Payer.

13. A pause function that gives VersusArena an indefinite or economically substantive ability to block settlement combined with other powers over the assets.

14. Any wallet architecture change that allows VersusArena to initiate sensitive User-Controlled Wallet transfers without the user's required approval.

11. PRACTICAL LEGAL CONTROLS TO PRESERVE THE CURRENT POSITION

The following legal controls should remain aligned across the product, contracts and implementation:

• Competition Parameters must disclose the material economic and operational rules before funding.
• The 10% Platform Fee, payout formula and refund formula must be fixed for the funded Competition.
• Result review should be documented as Competition adjudication, not discretionary payment execution.
• The administrator should be contractually and technically limited to the permitted Outcomes.
• False evidence, match-fixing, collusion and abuse of the dispute process should be handled through Competition integrity and account remedies, not through an open-ended right to confiscate funds.
• Any user-facing description of wallet control should be factual and should not overstate the regulatory conclusion.
• A final permissions map should be retained as part of the legal/compliance file so the contractual description can be demonstrated during Circle, bank, PSP, regulatory or counsel due diligence.
• If the EEA is activated, the final deployed model should be re-checked before making a high-reliance statement that VersusArena is outside the CASP perimeter.

12. USDC AS EMT / PSD2 PAYMENT-SERVICES OVERLAP

12.1 Current EEA regulatory position

USDC is classified in the EEA as an e-money token under MiCA. MiCA also provides that e-money tokens are deemed to be electronic money. This matters because electronic money is funds for PSD2 purposes, so an EMT transaction can engage payment-services rules independently of the MiCA crypto-asset-service analysis.

In its Opinion EBA/Op/2025/08 of 10 June 2025, the European Banking Authority advised national competent authorities to regard transfers involving EMTs as payment services under PSD2 where they are carried out on behalf of clients. The EBA also addressed custody and administration of EMTs and the circumstances in which a custodial wallet can constitute a payment account. The EBA's approach is functional and focuses on the actual service performed rather than the label attached to the blockchain flow.

The EBA's follow-up Opinion EBA/OP/2026/01 of 12 February 2026 addressed the end of the transitional period on 2 March 2026. After that date, entities carrying out EMT activities that qualify as payment services cannot rely on the earlier general transition as a basis for continuing such services without the applicable PSD2 route. PSD2 therefore remains a current perimeter issue while the future PSD3 and Payment Services Regulation framework is not yet fully applicable.

12.2 Application to the VersusArena architecture

Several current facts support a position outside a standalone VersusArena payment service:

• the User-Controlled Wallet is not a VersusArena custodial wallet and the user personally approves sensitive wallet actions;
• VersusArena does not maintain a general-purpose payment account or reusable internal USDC balance for Participants;
• a Payer authorises funding of a specific amount for a specific Competition rather than giving VersusArena a general transfer mandate;
• payout recipients, payout formulas, the Platform Fee and refund routes are fixed before funding;
• after the Competition, the user does not instruct VersusArena to transfer a chosen amount to a chosen address;
• VersusArena submits only the Competition Outcome, while the Tournament Smart Contract calculates and executes the pre-agreed settlement branch; and
• refunds return to the Original Payer rather than to a destination chosen after funding.

These facts support the characterization that VersusArena's primary service is the organization, verification and adjudication of a skill Competition, with the EMT movement operating as the pre-agreed settlement consequence of that service. They are materially stronger than a model in which VersusArena holds a client balance, accepts payment instructions or manually executes transfers between users.

However, the PSD2 analysis cannot rely solely on the commercial purpose of the transaction. The EBA's analysis reflects the broad PSD2 concept of transferring funds and specifically identifies EMT transfers carried out on behalf of clients as capable of being payment services. A regulator could therefore focus on VersusArena's role in designing the settlement mechanism and submitting the Final Outcome that causes participant EMTs to move between addresses. The fact that the smart contract calculates the payment details reduces this risk but does not conclusively eliminate it.

12.3 Captain-funded team Competitions

The captain-funded model is now a confirmed product feature and must be assessed as part of the current architecture, not as a future exception. Before funding, the captain selects a fixed payout mode: either the winning payout is made to the captain or it is distributed among the winning team's Participants according to a pre-agreed allocation. The selected mode cannot be changed after funding, and Void/Refund returns the relevant amounts to the captain as Original Payer.

Where the winning payout is made to the captain, the payment-services analysis is closer to the ordinary self-funded model. Where the captain's funded Participation Amounts can contribute to a payout distributed among teammate wallets, PSD2 sensitivity is higher because EMTs funded by one Payer may settle to other natural persons. The predetermined allocation, absence of post-funding discretion and return-to-Original-Payer refund rule materially improve the position, but this split-payout model should be treated as a specific EEA regulatory reliance point.

12.4 Preliminary PSD2 conclusion

The current architecture provides a credible basis to argue that VersusArena is not offering a separate payment service to Participants: there is no general client balance, no VersusArena custodial wallet, no open transfer mandate and no post-match payment instruction. Nevertheless, because USDC is an EMT and the EBA has expressly identified client EMT transfers as a PSD2 payment-services issue, the position is not sufficiently settled to state categorically that PSD2 does not apply.

For MVP drafting, the appropriate conclusion is therefore a MODERATE residual PSD2 perimeter risk in the EEA, with heightened sensitivity for captain-funded split payouts and any future feature that resembles a reusable balance, client transfer instruction, discretionary recipient selection or platform-controlled withdrawal flow. If the EEA is a material launch market, a final implementation-level payment-regulatory confirmation should be obtained before relying publicly or operationally on a position outside the PSD2 authorisation perimeter.

13. DOWNSTREAM CONSEQUENCE IF TRANSFER-SERVICE STATUS CHANGES

If VersusArena were ultimately treated as providing transfer services for crypto-assets on behalf of clients in the EEA, the issue would not be limited to the MiCA authorization perimeter. Article 82 obligations and ESMA's transfer-service Guidelines would become relevant, and the Regulation (EU) 2023/1113 travel-rule framework and related EBA Guidelines would need to be re-assessed for the transfer activity, including requirements relevant to transfers involving self-hosted addresses.

For that reason, the current decision not to build a separate VersusArena Travel Rule workflow as an automatic MVP requirement remains reasonable only while the non-CASP / non-transfer-service position remains supportable.

14. AUTHORITIES REVIEWED

Primary and official regulatory sources reviewed for this memorandum:

• Regulation (EU) 2023/1114 on Markets in Crypto-assets, in particular Recital 22, Article 3(1)(17), Article 3(1)(26), Article 59, Article 75 and Article 82.
• ESMA Q&A 2417, answer published 18 June 2026.
• ESMA Guidelines on transfer services for crypto-assets under MiCA, ESMA35-1872330276-2032.
• Joint EBA-ESMA Report on recent developments in crypto-assets under Article 142 MiCA, ESMA75-453128700-1391, January 2025.
• Regulation (EU) 2023/1113 on information accompanying transfers of funds and certain crypto-assets.
• EBA Guidelines concerning the travel-rule framework for transfers of funds and certain crypto-assets, applicable from 30 December 2024.
• Directive (EU) 2015/2366 on payment services in the internal market (PSD2).
• EBA Opinion EBA/Op/2025/08 of 10 June 2025 on the interplay between PSD2 and MiCA in relation to crypto-asset service providers that transact electronic money tokens.
• EBA Opinion EBA/OP/2026/01 of 12 February 2026 on supervisory priorities at the end of the transition period under the EBA No-Action Letter.
• Circle Internet Financial Europe SAS, USDC MiCA White Paper, updated 10 July 2026, identifying USDC as an e-money token under MiCA. Issuer source used for the current USDC classification and issuance facts.

END OF PRELIMINARY ANALYSIS