From the journal

DePIN regulation in the EU for Thai hardware and node rewards

This decentralised physical infrastructure (DePIN) venture involves a Thai company designing connected computing nodes for sale to EU operators. Operators contribute capacity for business customers through a managed network. The founders are considering token rewards, a token sale for expansion and exchange trading. The strongest initial design separates device sales and fiat payment for computing work, with optional customer credits confined to an existing service and assessed separately under Thai law.

32 min read

Executive Summary

  • The Thai project can build its initial EU offer around useful hardware and an operating computing service. A company that genuinely supplies customers as principal can buy accepted work from operators for fiat. Hardware conformity, service obligations and data controls still govern that launch; a token does not establish demand or profitability.
  • Technically non-transferable credits accepted only by their issuer can fall outside the EU Markets in Crypto-Assets Regulation (MiCA) definition of a crypto-asset. Thailand’s digital-token definition does not contain the same transferability condition. Credits therefore need separate Thai classification and, where applicable, the ready-to-use exemption. (Regulation (EU) 2023/1114, art. 3(1)(5), recital 17; Thai Digital Asset Business Emergency Decree B.E. 2561, s. 3.)
  • A transferable token needs a rights-based classification before sale or listing. Access to an issuer’s own computing service can support utility-token treatment. Investment rights, a stable-value undertaking or acceptance by independent suppliers can change the route. An expectation of price appreciation alone does not establish a financial instrument. (MiCA, arts. 2(4)(a), 3(1)(6)–(9); Directive 2014/65/EU, art. 4(1)(15), (44).)
  • Operators supply consideration when they earn tokens for computing work. Ordinary customer workloads do not establish MiCA’s exception for automatically created ledger-maintenance or transaction-validation rewards. A genuine existing-service utility offer has a separate exemption, but communicating an EU listing intention can remove it before trading begins. (MiCA, art. 4(3)–(4).)
  • Thai ready-to-use treatment depends on the actual rights, service readiness and intended market. The current wholly-overseas qualification disapplies specified payment and staking conditions for one exempt category; it does not exempt every outbound fundraising sale. EU obligations apply independently. (Thai SEC Notification Kor Jor. 16/2567, cls. 3–5, as amended.)
  • The manufacturer’s Cyber Resilience Act reporting duties apply from 11 September 2026. General product requirements apply from 11 December 2027. Existing electrical, radio, consumer and other applicable product requirements can already constrain shipment. (Regulation (EU) 2024/2847, arts. 69, 71.)
  • The contracts must distinguish device performance, computing-service quality and operator remuneration. Low earnings do not automatically establish a defect, but unsupported profitability claims, undisclosed fees or unpaid accrued rewards can create liability. Consumer remedies cannot be replaced by a blanket risk disclaimer. (MiCA, arts. 7, 14–15; Directive 2005/29/EC, arts. 6–7; Directive (EU) 2019/771, arts. 7, 13, 21.)
  • Data flows, processing roles and access to customer workloads determine the network’s data obligations. Distributed infrastructure can also satisfy the Data Act’s data-processing-service definition or NIS2’s cloud-service definition. Those tests concern the service and its actual operation, even where the project launches without tokens. (Regulation (EU) 2023/2854, arts. 1(3)(f), 2(8); Directive (EU) 2022/2555, arts. 2, 6(30).)

Separate the device, computing service and payment obligation

The first commercial decision is who owes the customer the computing service. The proposed network manager should contract as principal if it intends to issue credits for its own service. It would sell defined computing capacity to customers and purchase accepted work from node operators. That recommendation changes the contractual design; the hypothetical does not establish that the manager already acts as principal.

Under this arrangement, the hardware buyer owns the specified device, while the network contract governs access, workload allocation and remuneration. Ownership alone gives no entitlement to customer demand, a particular token price or an exchange listing. Any promised minimum work allocation, buyback or payment must appear expressly in the commercial terms and financial plan. Separating documents cannot cure a sales pitch that presents the entire package as a guaranteed return.

The Thai designer may also be the branded manufacturer, seller, network supplier and token issuer, but each role needs an identified legal entity. An EU importer, downstream distributor and authorised crypto-asset service provider perform different functions. A contract can allocate work and recovery rights without transferring a statutory duty to an actor who does not hold the relevant role. (Cyber Resilience Act, arts. 3(13), (16)–(17), 18–21; MiCA, arts. 4–5, 59.)

The principal model also changes the payments analysis. Collecting the price of the company’s own service and paying its own suppliers differs from collecting and remitting money for independent node suppliers. If customers instead contract directly with operators, the manager must assess its payment-intermediation activities and the claim that its token accesses an issuer-supplied service. The contracts, invoices and actual money flows must describe the same arrangement. (MiCA, art. 3(1)(9); Directive (EU) 2015/2366, arts. 3, 4 and Annex I.)

Keep customer credits distinct from operator remuneration

A narrow customer-credit design can avoid creating a MiCA crypto-asset. Article 3(1)(5) requires a representation of value or rights that can be transferred and stored electronically using distributed-ledger or similar technology. Recital 17 addresses technically non-transferable assets accepted only by their issuer or offeror. The European Supervisory Authorities’ nonbinding guidelines interpret this as requiring an actual technical inability to transfer to another holder. A contractual prohibition, temporary lock-up or restricted front end over transferable tokens gives a weaker basis. (MiCA, art. 3(1)(5), recital 17; Joint ESA Guidelines JC 2024 28, para. 19.)

The recommended credits would purchase specified units of the principal supplier’s functioning service, remain within the customer’s account and expire through redemption under clear terms. The implementation should exclude holder transfers, transferable wrappers and administrative mechanisms that recreate a tradeable entitlement. Customers retain contractual and statutory remedies for undelivered services. A prohibition on ordinary cash conversion must not purport to extinguish legally required refunds.

Non-transferability does not settle every financial-law question. Electronic money requires stored monetary value, a claim on the issuer, issuance on receipt of funds for payment transactions, and acceptance by a person other than the issuer. Genuine credits accepted solely for the same supplier’s service lack that last characteristic. Acceptance by independent nodes or other merchants changes the test. (Directive 2009/110/EC, art. 2(2).)

A payment instrument used within a limited network has a separate potential exclusion under payments law. Direct commercial agreements with the participating providers, or a genuinely very limited range of goods or services, matter. Qualifying transactions exceeding EUR 1 million over the preceding 12 months trigger notification under PSD2; the authority can reject the claimed exclusion. That test must not be confused with MiCA’s limited-network offer rules. (Directive 2009/110/EC, art. 1(4); Directive (EU) 2015/2366, arts. 3(k), 37(2), 114.)

Operators should receive fiat for accepted work in the initial design. Non-transferable credits would not ordinarily pay their electricity bills, and issuing illiquid rewards does not establish a sustainable business. The founders must finance operator compensation and expansion through actual revenue or a separately lawful financing route. The commercial objection to this recommendation is real: a saleable reward may be central to recruitment. That choice requires the transferable-token analysis and its resulting offer and service-provider conditions.

Classify the rights before calling the token a utility

A transferable access token can qualify as a MiCA utility token only where its sole intended function is access to a good or service supplied by its issuer. The proposed principal supplier therefore offers a stronger structure than a separate issuer whose token merely connects customers with independent suppliers. Subcontracted node work can support the supplier’s own contractual service; the issuer must still undertake that service obligation. (MiCA, art. 3(1)(9).)

Financial-instrument treatment takes priority over MiCA. MiFID II includes transferable securities, units in collective investment undertakings and specified derivatives, including instruments issued through distributed-ledger technology. Standardised, negotiable rights to equity participation, debt repayment or qualifying investment returns can change the classification. A genuinely pooled investment arrangement needs its own analysis of investment policy, pooled returns and investor control. An operating computing business does not become such an undertaking merely because it needs capital. (MiCA, art. 2(4)(a); Directive 2014/65/EU, art. 4(1)(15), (44), Annex I, Section C; Regulation (EU) 2022/858, art. 18; ESMA Guidelines ESMA75453128700-1323, paras. 21–30, 37–43.)

The strongest objection to treating an appreciation-led token as an ordinary utility is the substance of its rights and the combined sales package. Yet an expectation of profit, an expansion purpose or a hoped-for price increase does not alone satisfy MiFID’s tests. ESMA’s nonbinding qualification guidelines preserve the statutory tests; an investment expectation cannot replace their elements. Hybrid rights require examination across categories. (ESMA Guidelines ESMA75453128700-1323, paras. 62, 74–76.)

A stable-value promise raises a different issue. A token purporting to maintain value by reference to one official currency can be an electronic money token. Reference to another value, right or combination can produce an asset-referenced token. A fixed quantity of computing service does not itself prove such a stabilisation promise. Reserve arrangements, redemption rights, reference prices and marketing must be examined together. (MiCA, art. 3(1)(6)–(7); Joint ESA Guidelines JC 2024 28, para. 23.)

Those categories have separate issuance routes under MiCA Articles 16 and 48, with their own exceptions and residual duties. The initial product should avoid a stable-value undertaking and investment rights unless the founders deliberately choose and fund that regulated route. Calling the same rights “utility” would leave the underlying classification unchanged.

Distinguish computing rewards from ledger rewards

Payment for customer workloads does not establish MiCA’s ledger-reward exemption. Article 4(3)(b) concerns assets automatically created as rewards for maintaining the distributed ledger or validating transactions. The device’s role in executing customer jobs, the ledger’s validation process and the token’s creation mechanism therefore need separate descriptions. Allocating previously minted treasury tokens for measured off-chain work does not satisfy that wording merely because the recipients operate nodes.

A design can use useful computing in its actual consensus mechanism. In that variant, protocol specifications and issuance records must establish the statutory function and automatic creation. The exemption cannot be accepted or rejected from the project’s name alone. Licentium’s analysis of validators supplying staking services to an Irish custodian concerns consensus and signing responsibilities; this hypothetical requires a separate account of customer computing work.

The free-offer exception is also unsuitable where the offeror receives computing services in exchange. MiCA excludes monetary and non-monetary benefits from a genuinely free distribution. The offer definition still matters: a bespoke settlement of a contractual liability is not automatically a public offer, while a public recruitment campaign supplying sufficient token and offer terms can engage it. The relevant communication and consideration must be examined before applying an exception. (MiCA, arts. 3(1)(12), 4(3)(a) and art. 4(3), second subparagraph.)

Existing service and listing plans produce different offer routes

An offer of utility tokens accessing an existing or operating issuer service can benefit from Article 4(3)(c), which disapplies Title II to that offer. The entitlement sold must actually access the operating service. Existing hardware or an unrelated live product does not establish that a promised future service already operates.

The limited-network alternative requires use only for goods or services within a limited merchant network under contractual arrangements with the offeror. A continually expanding worldwide provider network presents a poor premise for that route. Union consideration above EUR 1 million in each relevant 12-month period requires notification, and the authority can reject the claimed limited network. (MiCA, art. 4(3)(d), recital 26.)

Smaller offers have a different legal effect. Offers to fewer than 150 persons per Member State acting on their own account, offers not exceeding EUR 1 million across the Union over the specified 12 months, and offers confined to qualified investors can disapply the identified white-paper and publication requirements. Article 4(2) does not remove the whole Title II regime. Its residual legal-person, marketing-content and conduct conditions remain; ordinary business customers are not automatically qualified investors. The qualified-investor route also requires that only those investors can hold the token. (MiCA, art. 4(1)–(2).)

The paragraph 2 and 3 exemptions cease to apply when the offeror, or someone acting on its behalf, communicates an intention to seek admission to trading on a platform operated by a crypto-asset service provider established in the Union. A founder’s public listing promise on the offeror’s behalf can trigger that result before any venue admits the asset. Internal consideration of listing, without the statutory communication, is a different fact. Every subsequent offer needs its own assessment. Drawing up a crypto-asset white paper voluntarily for an otherwise exempt offer makes Title II applicable. (MiCA, art. 4(4), (7)–(8); nonbinding European Commission answer ESMA_QA_2671, updated 21 May 2026.)

A pre-operational utility sale cannot use the existing-service exception. Where the offer follows the white-paper route, its duration cannot exceed 12 months from publication. This is an offer-duration limit, not a universal deadline for completing the service. Selling rights to future expansion requires an accurate description of what holders can use now and what remains contingent. (MiCA, arts. 4(6), 12(8).)

For an ordinary Title II token, the Thai offeror can be a legal person without becoming an EU-authorised issuer merely because it offers tokens. For a third-country offeror without an EU branch, the home Member State is where the first public offer is intended or, at its choice, where the first admission application is made. An offeror with EU branches instead chooses among the Member States where it has a branch. The route requires the applicable white paper, classification explanation, notification, publication, marketing and conduct controls. Where notification is required, it must precede white-paper publication by at least 20 working days; it is not prior regulatory approval. The prescribed electronic white-paper format now includes XHTML and Inline XBRL, so a PDF alone is insufficient. (MiCA, arts. 3(1)(33)(b)–(c), 4, 6–9, 14; Commission Implementing Regulation (EU) 2024/2984, arts. 1–4 and Annex, Table 2.)

Admission to trading has its own Article 5 duties. A written agreement may allocate specified work to the trading platform, but the person seeking admission remains responsible under Article 15(3) for the information it supplies. Marketing must follow the applicable publication sequence. Where relevant, the offer must safeguard collected funds and preserve the applicable 14-calendar-day retail withdrawal right, including its statutory exceptions. (MiCA, arts. 5, 7(2), 9–10, 13, 15(3).)

Apply Thailand’s current rules to the actual distribution

The Thai company’s outbound plan needs a Thai digital-asset analysis even where EU rules permit a particular offer. Section 3 of Thailand’s Digital Asset Business Emergency Decree defines electronic token rights without MiCA’s express transferability condition. An electronic entitlement to specified computing services can therefore require examination under the Thai regime even when holders cannot transfer it. Ordinary invoicing is not automatically token issuance; the actual electronic unit, rights and holder agreement matter.

Thai SEC Notification Kor Jor. 16/2567 exempts specified ready-to-use utility offers from the public-offering provisions. Clause 3(1) covers the identified consumptive, certification and documentary categories; clause 4 adds the defined means-of-payment and staking conditions. A proposed fixed computing entitlement needs actual service readiness, clear redemption rights and comparison with the operative annex. Selling credits in fiat differs from making the token’s redemption right a fiat balance. The consumptive design should avoid money redemption, currency-denominated rights, market-price-based entitlement calculations and deposit-for-return features within the annex’s terms. (Notification Kor Jor. 16/2567, cls. 3–4, as amended by Kor Jor. 11/2568; MOP, staking and project-exchange-token annex to Notification Kor Thor. 11/2561, as amended by Kor Thor. 18/2567, Parts 1–2.)

Clause 3(2) provides a separate route for other ready-to-use tokens where the issuer does not intend listing on an exchange licensed under Thailand’s Digital Asset Business law. Clause 5 disapplies clause 4 for that category when the tokens are offered entirely overseas. The remaining readiness and listing conditions survive. An EU-facing website does not itself establish wholly-overseas distribution, and the text’s reference to a Thai licensed exchange must not be silently expanded to every foreign exchange. (Notification Kor Jor. 16/2567, cls. 3(2), 5.)

The strongest objection to the conservative credit design is that the wholly-overseas exception may permit a wider Thai structure. That possibility deserves its proper effect, but it does not remove EU offer rules or convert future-service fundraising into a ready-to-use offer. The company must document its recipients, distribution territory and listing intentions before relying on it.

Investment participation also survives the addition of utility rights. The 2025 amendment expressly includes investment tokens that carry goods or service rights as well. A prelaunch sale financing services that are not ready cannot rely on readiness merely because the project has manufactured devices. Unless a different exclusion or exemption applies, the Thai public-offer route requires SEC approval, effective filing and prospectus, and an approved ICO portal. (Emergency Decree, ss. 17–19; Notification Kor Jor. 15/2561, cls. 2, 17, 19–19/2, as amended by Kor Jor. 16/2568.)

Measured computing work is not automatically staking under the Thai annex. Its definition concerns token deposits where the recipient agrees to provide a return, subject to specified exceptions, including deposits used for transaction-confirmation mechanisms. Payment for verified off-chain work requires a different factual analysis. Lock-ups, collateral, consensus functions and return sources must be examined. The public-offer rules must also be tested against the reward arrangement; the label “reward” does not establish a cash sale or a free distribution. (Notification Kor Jor. 16/2567, cl. 4; MOP, staking and project-exchange-token annex to Notification Kor Thor. 11/2561, as amended by Kor Thor. 18/2567, Part 2.)

The platform’s services require a separate Thai review. An activity within the Decree’s digital-asset business categories requires the applicable Ministry of Finance licence on the SEC’s recommendation unless the relevant exclusion applies. Custody has exceptions, including specified own-issued-only custody, while exchange, brokerage and dealing have their own definitions and exclusions. Current operator rules contain category-specific and ancillary-business qualifications; computing credits cannot inherit the special treatment for carbon or renewable-energy certificates. Restrictions on licensed operators facilitating payment use also differ from a blanket ban on every private person accepting crypto-assets. (Emergency Decree, ss. 3, 26; Notifications Kor Thor. 11/2561, cl. 2; Kor Thor. 26/2565, cl. 2; Kor Thor. 5/2565, cls. 1–3; Kor Thor. 19/2561, cls. 6/2, 11/2(3), as amended by Kor Thor. 17/2568.)

The 2025 statutory extension concerning foreign providers serving people in Thailand addresses inward service activity. It does not provide an outbound exemption for the Thai issuer. Thai-language targeting, Thai payment arrangements and the other statutory indicators also matter if a nominally overseas service reaches Thai users. (Emergency Decree, ss. 26(3), 26/1, inserted by Emergency Decree No. 2 B.E. 2568.)

Allocate regulated token services to the responsible provider

Issuing a token and professionally providing services for clients are different activities under MiCA. Hosted key control, exchange, multilateral trading, execution, placement, order transmission, advice and transfers require a function-by-function review. Backend or administrative control can matter as much as a visible wallet interface. Paying the company’s own contractual debt does not by itself establish a transfer service for clients. (MiCA, art. 3(1)(15)–(26).)

An authorised EU crypto-asset service provider, or an eligible financial entity using Article 60, may perform the activities covered by its permission. Its authorisation does not extend to the Thai manager’s independent business through a referral or technology contract. The selected provider’s entity, services, customer contract and cross-border notification must match the actual work. The ordinary CASP route requires EU establishment and management under Article 59(2). (MiCA, arts. 59–60, 65.)

Article 4(5) nevertheless contains a narrow custody and transfer exception for assets whose offers fall within Article 4(3). It does not exempt trading-platform or exchange activity, and another non-exempt offer or admission of the same asset removes the stated protection. A blanket rule that every project wallet needs the same permission would miss this exception.

A planned EU launch should not rely on a customer-exclusive-initiative claim. Solicitation by the third-country firm or persons acting on its behalf defeats that route, and contractual disclaimers cannot manufacture the customer’s initiative. The maximum transitional period for existing providers ended on 1 July 2026; it supplies no new launch permission. (MiCA, arts. 61, 143(3).)

Classify the actual device before arranging EU shipment

The connected node falls naturally within the Cyber Resilience Act’s product inquiry because its intended use involves a data connection. The Act can also include manufacturer-designed remote processing necessary for a product function. A separately supplied computing service needs its own assessment; every cloud function is not automatically part of the hardware product. (Regulation (EU) 2024/2847, arts. 2(1), 3(1)–(2).)

The Thai company can be the manufacturer where it has the device designed or made and markets it under its name. The first EU entity placing that third-country product on the market can be the importer; a later seller can be a distributor. Own branding or substantial modification can transfer manufacturer obligations to another actor. The supply agreement should identify each actual role and its current product-law duties, while preparing for CRA responsibilities applying from December 2027. (Cyber Resilience Act, arts. 3(13), (16)–(17), 18–21.)

Current conformity work depends on the model’s electrical and radio features. The EMC Directive covers relevant electrical and electronic apparatus. The Low Voltage Directive applies within its specified voltage bands, so a low-voltage node and its mains adapter may require different treatment. Wi-Fi, Bluetooth or cellular capability can engage the Radio Equipment Directive, whose safety requirement applies without the Low Voltage Directive’s voltage threshold. Internet connectivity through a cable alone does not make the box radio equipment. (Directives 2014/30/EU, arts. 2–3, 7, 9–10; 2014/35/EU, arts. 1, 6, 8–9; 2014/53/EU, arts. 2–3, 10, 12–13.)

Specified radio cybersecurity requirements already apply from 1 August 2025. Their network, privacy and fraud provisions have different feature-based triggers, including the relevant ability to transfer money, monetary value or virtual currency. The repeal adopted in 2026 takes effect only on 11 December 2027. A token-reward screen alone does not establish every radio payment function. (Commission Delegated Regulation (EU) 2022/30, art. 1, as amended by Regulation (EU) 2023/2444; Regulation (EU) 2026/339, arts. 1–2.)

The bill of materials and sales channel also determine restricted-substance and waste obligations. RoHS requires the relevant equipment and component assessment; WEEE requires allocation of producer registration, financing and end-of-life responsibilities in the destination system. If the product is intended for, or foreseeably likely to be used by, consumers, the General Product Safety Regulation can govern risks and duties not already covered by sector-specific legislation. Its EU responsible-operator, online-offer and recall rules require their own application. (Directives 2011/65/EU, arts. 2–4; 2012/19/EU, arts. 2–3, 12–13, 16–17; Regulation (EU) 2023/988, arts. 2–3, 16, 19–20, 35–37.)

Operate current incident reporting while preparing the CRA product file

The manufacturer must distinguish three CRA dates. The notified-body chapter applies from 11 June 2026, Article 14 reporting from 11 September 2026, and the general product regime from 11 December 2027. Article 14 also applies to products placed on the market before general application. Units already placed on the market before that date become subject to the general requirements if they undergo a qualifying substantial modification from that date. The relevant placing-on-the-market event concerns each unit, not merely the model’s first launch. (Cyber Resilience Act, arts. 69(2)–(3), 71.)

For an actively exploited vulnerability, Article 14 requires an early warning within 24 hours of awareness and a fuller notification within 72 hours, without undue delay. The final report is due within 14 days after a corrective or mitigating measure becomes available. Active exploitation requires reliable evidence of malicious exploitation without the owner’s permission; a serious flaw alone does not establish that trigger. (Cyber Resilience Act, arts. 3(42), 14(1)–(2).)

A severe incident affecting product security has a separate route. Its early warning and fuller notification are due within 24 and 72 hours of awareness, without undue delay. The final-report deadline is one month after submission of the incident notification. For either trigger, the manufacturer must inform impacted users and, where appropriate, all users, and apply the non-EU reporting-route hierarchy. A CSIRT’s tightly bounded ability to delay onward dissemination does not extend the manufacturer’s initial notification clock. (Cyber Resilience Act, art. 14(3)–(8); Commission Delegated Regulation (EU) 2026/881, arts. 1, 3–5.)

The launch team therefore needs an accountable manufacturer contact, continuous incident intake and a documented route to the coordinating CSIRT and ENISA. The vulnerability and severe-incident tests must run separately. Licentium’s discussion of product-security accountability under the Cyber Resilience Act provides further treatment of the manufacturer’s reporting role.

The product file should be developed before the general duties become applicable. Article 13 and Annex I require the relevant risk assessment, security design, component due diligence, vulnerability handling, technical documentation and conformity process. The software bill of materials must cover at least top-level dependencies. Patch signing, secure distribution, coordinated disclosure and responsibility for the supplied operating system need an engineering owner.

CRA support must reflect expected use and reasonable user expectations, with a minimum of five years unless expected use is shorter. A device expected to operate longer may require a longer period. Security updates must remain available for at least ten years after issue or the remaining support period, whichever is longer. The month and year of support expiry must be clear at purchase when the general regime applies. These periods differ from a commercial warranty or the seller’s consumer-conformity liability. (Cyber Resilience Act, art. 13(8)–(9), (19).)

Conformity assessment depends on the product’s core functionality. An embedded operating system does not automatically make the entire node an important product. Separately supplied operating systems, network-management products or relevant hypervisors can alter the classification and assessment route. The company must map the actual product against the technical descriptions before deciding whether internal assessment or third-party involvement is available. (Cyber Resilience Act, arts. 7, 32, Annex III; Commission Implementing Regulation (EU) 2025/2392, art. 2 and Annex I.)

Contract for measurable performance and an effective exit

The hardware order should identify the model, supplied software, ownership and delivery terms, conformity specification, update channel and repair process. It should explain what remains usable after network access ends. The seller should avoid making essential security support conditional on holding or staking a token. A contractual warranty must describe an actual remedy, and liability limitations require review under the chosen governing law.

Operator terms should state the permitted workloads, supported configuration and the evidence used to accept computing work. A reward formula needs its measurement unit, applicable rate, fees, payment asset, settlement time and dispute process. The network should preserve auditable records and distinguish rejected work from periods when no customer work was allocated. A prospective change mechanism should identify reasons, notice and exit rights; accrued payment entitlements should survive termination.

Customer service terms should describe purchased capacity or service quality, workload acceptance, processing locations, isolation, subcontracting and incident cooperation. Downtime remedies should address the service actually promised. Termination must specify data retrieval, return or deletion, unused prepayments and the continuity needed to exit safely. Security suspension should be proportionate to the risk and should not confer an unrestricted right to retain earned operator pay.

Consumer sales require a separate version. A person acting outside trade or profession does not lose protection merely by accepting a “business operator” label. National laws implementing the Sale of Goods Directive require conformity, necessary updates and the applicable repair, replacement, price-reduction or termination remedies. The usual two-year liability baseline has qualifications for continuing digital supply and national variation. The 2026 repair amendments include a once-only 12-month extension where repair is used as the conformity remedy, subject to the permitted national alternatives and longer periods. (Directive (EU) 2019/771, arts. 7, 10, 13–14, 21, as amended by Directive (EU) 2024/1799, art. 16.)

Distance sales normally carry a 14-day withdrawal right; operating a physical node does not automatically invoke the separate digital-content exception. Online withdrawal functionality and the applicable durability, update and repair information also require attention under the current Consumer Rights Directive. Separately supplied consumer digital services can also engage the Digital Content Directive’s conformity, remedy and modification rules; digital elements supplied with the device under its sales contract remain within the goods regime. An unrestricted unilateral reward-change term or waiver of all remedies can fail the unfair-terms test. (Directive 2011/83/EU, arts. 6, 9, 11a, 16, as amended by Directives (EU) 2023/2673 and 2024/825; Directive (EU) 2019/770, arts. 3, 8, 13–14, 19, 22; Directive 93/13/EEC, arts. 3, 6.)

A governing-law clause cannot simply remove mandatory consumer protection in the consumer’s country of habitual residence where the trader directs its activities to that country and the contract falls within those activities, subject to Article 6’s exceptions. A qualifying consumer may also sue in the courts of their Member State of domicile despite the trader’s Thai domicile, subject to the regulation’s conditions. The project must choose destination markets and contract terms together, including language, local implementation and dispute provisions. (Regulation (EC) No 593/2008, arts. 3, 6, 9; Regulation (EU) No 1215/2012, arts. 17–19.)

Control customer workloads and cross-border access

The initial service should admit only workloads for which the project can enforce the promised processing and access conditions. The data map must identify who chooses jobs, controls encryption keys, sees plaintext during execution, administers the devices and exports logs or results. Keeping a box in the EU does not answer whether a separate Thai recipient can access its contents.

Under the GDPR, roles follow who determines processing purposes and means. A business customer can be controller of its workloads, the network supplier its processor, and operators authorised subprocessors. Processing for the network’s own purposes can change that allocation. Account and billing records can have a different controller from customer payloads. The controller and processor need the appropriate Article 28 contract. The processor must obtain the controller’s prior specific or general written authorisation for subprocessors and impose the required equivalent obligations on them; it remains liable to the controller for their performance of those obligations. (Regulation (EU) 2016/679, arts. 3, 4(7)–(8), 28.)

Thailand has no EU adequacy decision on the Commission’s published list. A qualifying transfer to a separate Thai recipient therefore needs another Chapter V basis. The Commission’s standard contractual clauses provide one possible route within their scope, with the appropriate module and assessment of destination law, access practices and effective safeguards. Signing them does not establish that the technical design permits compliance. The EDPB’s nonbinding guidance distinguishes remote access within the same controller from disclosure to a separate recipient. (GDPR, arts. 44–46; Commission Implementing Decision (EU) 2021/914, art. 1 and Annex, cls. 14–16; EDPB Guidelines 05/2021, version 2.0, paras. 9, 16–17.)

Encryption in transit or storage does not solve every access issue where a processor must see plaintext. The EDPB’s nonbinding recommendations identify that limit; the result depends on the actual destination-law and technical assessment. An initial restriction to demonstrably non-personal workloads can reduce the payload-transfer problem. An EU-only processing chain can also help, provided the recipient entities and actual access rights establish that payloads are not made available to a separate Thai recipient. Those restrictions must operate in routing, permissions and contracts, while personal account data still needs its own treatment. (EDPB Recommendations 01/2020, version 2.0, paras. 94–95; GDPR, arts. 5–6, 32.)

Thai processing duties also remain relevant. Thailand’s Personal Data Protection Act applies to controllers or processors in Thailand even where the relevant collection, use or disclosure occurs elsewhere. Its controller and processor provisions require the applicable security, instructions, processing agreement and breach cooperation. An EU contract cannot substitute for those local duties. (Thai Personal Data Protection Act B.E. 2562, ss. 5, 37, 40.)

Test the service against the Data Act and NIS2

The Data Act does not classify every connected computing box as a connected product. Its definition excludes equipment whose primary function is storing, processing or transmitting data for a party other than the user. A node devoted to customer workloads needs analysis of its primary function and the identity of its user. Connected-product data-access obligations should follow that test. (Regulation (EU) 2023/2854, art. 2(5).)

The managed network can independently qualify as a data processing service, including through highly distributed resources. Chapter VI applies to covered providers offering services to EU customers, including providers established elsewhere. Its contractual and technical switching duties require removal of the specified exit obstacles. The ordinary notice ceiling is two months, with a standard 30-calendar-day transition and the prescribed technical-infeasibility procedure. A retrieval period of at least 30 days follows the transition. (Data Act, arts. 1(3)(f), 2(8), 23–25.)

For services subject to Article 29, permitted switching charges are limited to directly incurred switching costs before 12 January 2027. From that date, those switching charges are prohibited. The rule does not abolish every ordinary service charge or early-termination payment. Qualifying bespoke services are exempt from specified duties, including Article 29, but remain subject to the rest of the applicable switching regime. A covered non-EU provider needs the required EU legal representative. The service contract and export capability must implement the applicable route before workloads are accepted. (Data Act, arts. 29, 31, 37(11)–(13), 50.)

NIS2 separately defines cloud computing to include an on-demand, scalable and elastic pool of shareable resources distributed across locations. A managed DePIN network can satisfy that definition. The usual size test, linked-enterprise rules and specified size-independent cases determine whether the provider is covered. If covered, the provider must check its security, significant-incident reporting, jurisdiction and representative duties under the selected Member State’s current implementing law. The cloud-provider technical and incident rules also apply under the implementing regulation. Decentralised equipment ownership does not resolve those elements. (Directive (EU) 2022/2555, arts. 2, 6(30), 21, 23, 26, Annex I, point 8; Commission Implementing Regulation (EU) 2024/2690, arts. 1–3, 7 and Annex.)

Reassess disclosures when trading, security or earnings change

Listing changes more than liquidity. A communicated EU listing intention can remove Article 4 exemptions; seeking admission engages Article 5, while actual admission ends the stated custody-transfer exception. Market-abuse provisions apply once admission has been requested or the asset is admitted, including relevant conduct outside the trading platform and outside the Union. The issuer needs a process for identifying inside information before that stage. (MiCA, arts. 4(4)–(5), 5, 86–88.)

A serious device vulnerability requires immediate assessment under the applicable product, contract and data rules. The manufacturer should preserve evidence, restrict unsafe deployment where necessary and prepare corrective measures. CRA reporting follows its actual exploitation or severe-incident triggers. For a personal-data breach, the processor informs its controller without undue delay; the controller’s authority-notification rule requires notification without undue delay and, where feasible, within 72 hours after the controller becomes aware of the breach, with the statutory risk exception. High-risk individual notification has a separate threshold. These duties can run concurrently. (Cyber Resilience Act, art. 14; GDPR, arts. 32–34.)

For a token within the relevant MiCA duties, a vulnerability or structural deterioration in service economics can also require disclosure. Article 12 requires correction of a significant new factor, material mistake or inaccuracy capable of affecting assessment during the offer or while the asset remains admitted. Article 88 separately requires prompt disclosure of qualifying inside information directly concerning the responsible issuer, offeror or admission seeker. The seven-working-day notification procedure for a modified white paper does not permit postponing an otherwise immediate market notice. Any delay must satisfy Article 88’s own conditions. (MiCA, arts. 12, 87–88.)

A token subject to the Thai public-offer regime also needs a continuing-disclosure process. Where planned issuer action would depart from the filed information by changing ready-token holder rights or materially affecting the token’s price or value, the issuer must submit the prescribed revised filing and notify holders at least 15 days before the change takes effect. Specified events, including serious loss, cessation of all or part of the business and material amendments to token terms, require reporting within three days of actual or constructive knowledge. These rules do not turn every disappointing earnings result into a reportable event. (Emergency Decree, s. 25; Notification Kor Jor. 15/2561, cls. 51/1–53.)

Operators earning less than their costs creates a different inquiry. Low demand, downtime or a falling token price does not by itself prove that a functioning device is defective. Liability depends on the promised service, reward calculation, accuracy of sales statements, material omissions and applicable remedies. The company should publish the inputs behind any earnings illustration: accepted work, utilisation assumptions, rate, electricity use and price, fees, hardware cost and any token conversion expense. It must distinguish estimates from binding minimums and discretionary incentives.

MiCA bars future-value assertions in the white paper apart from its prescribed risk statements, and requires fair, clear and non-misleading information. The prescribed sustainability disclosures concern the token’s consensus mechanism; customer-computing energy costs need their own evidence. A disclaimer cannot cure a misleading overall profitability claim. White-paper liability has its own infringement, loss and decision-related burden, and cannot be excluded by contract. Consumer marketing rules remain applicable where consumers are targeted. (MiCA, arts. 6(2), (4)–(5), 7, 14–15, Annex I; Commission Delegated Regulation (EU) 2025/422, arts. 2, 4, 6 and Annex; Directive 2005/29/EC, arts. 6–7.)

In the applicable Thai approved-offering setting, advertising must remain consistent with filed information, avoid materially misleading return claims and provide the required support and risk information for forecasts. Those requirements do not automatically govern every exempt credit or hardware advertisement. (Notification Kor Jor. 15/2561, cl. 30.)

Marketing review should compare the device order, operator calculator, token papers and public campaign against the same promises. Atlas marketing screening can assist an initial review of campaign materials. The issuer remains responsible for checking the legal classification, underlying figures and final claims before release.

Release each part only after its own launch conditions are met

The first release should identify the EU destination markets, responsible entities and device model, then complete the applicable product file and current conformity work. The manufacturer needs an operating CRA reporting process. Customer and operator contracts should implement the principal-supplier design, measurable acceptance criteria, fiat remuneration and usable exit rights. Workloads should remain within the access and processing controls that the project can enforce.

Customer credits should follow only when the promised service is actually available, technical transfer restrictions work, and Thai classification is resolved and any applicable ready-to-use conditions are met. A separate issuer, third-party acceptance, cash-value promise or transferable wrapper requires renewed analysis. Credits should not finance a future service while being described as immediate consumption rights.

A transferable reward or expansion sale should wait until the final rights, recipients, territory, listing communications and service-provider functions determine the applicable route. The responsible entities must complete the resulting offer, admission, permission and disclosure requirements before those activities begin. A public listing proposal, investment or stabilisation rights, hosted key control, additional trading services, new destination markets and material hardware or software changes should each trigger reassessment. The fiat service model remains available where token fundraising or tradeable rewards would add obligations the project is not yet ready to perform.