A token project does not enter Turkish law through its white paper. It enters through the rights the code creates, the people who control those rights, the way value is sold or distributed, the market made around it, the custody offered to users and the claims used to promote it. Two products deployed from the same smart-contract template can therefore have entirely different legal profiles.

This English pillar is for foreign founders, protocols, investors, exchanges, technology companies and established businesses building a token, stablecoin, DeFi, DAO, custody, staking, NFT or other Web3 model with a Turkey connection. It addresses the substance of high-intent searches such as “launch a token in Turkey”, “stablecoin law Turkey”, “DeFi regulation Turkey”, “Web3 lawyer Istanbul”, “token sale to Turkish investors”, “DAO legal structure Turkey”, “crypto payment ban”, “smart contract enforceability” and “does a wallet need a Turkish licence?”

The useful starting point is not “Is crypto legal in Turkey?” Turkey has a regulated crypto-asset service-provider framework, a separate restriction on using crypto assets in payments, capital-markets rules that can apply to investment instruments and offerings, AML obligations, and ordinary laws concerning companies, contracts, data, consumers, tax and crime. The product must be decomposed into functions before the legal consequences can be assembled.

For legal advice on this matter, you may contact Av. Ahmet Karaca:

WhatsApp Email

Begin with a control-and-rights map

A project’s public language often emphasises decentralisation while its deployed reality includes concentrated controls. The first legal-technical deliverable should show:

who deploys and upgrades the contracts;
who holds administrator, pauser, minter, burner, blacklist or oracle roles;
which multisignature signers and thresholds govern those roles;
who can change fees, collateral, redemption, pools or governance parameters;
what a token holder can legally and technically demand;
which entity receives sale proceeds or protocol revenue;
who provides the interface, custody, exchange or fiat rail;
who markets to Turkish residents; and
what happens during insolvency, exploit, depeg or termination.

This map often changes the legal conclusion. A “non-custodial” wallet may have an operator-controlled recovery function. A “governance token” may promise profit participation. A “decentralised” protocol may be upgradeable by a small team. A “stablecoin” may be redeemable only by selected institutional customers. Legal advice that accepts the product label without reading the control plane is fragile.

The Turkish regulatory layers

Law No. 7518 amended Capital Markets Law No. 6362 in July 2024. It defined crypto assets and key service-provider concepts, brought crypto-asset service providers under the Capital Markets Board of Türkiye—the CMB or SPK—and gave the Board powers concerning regulated services, platforms, custody and crypto assets linked to capital-markets instruments.

Two communiqués effective from 13 March 2025 form the operational centre:

Communiqué III-35/B.1 on establishment, authorisation, shareholders, governance, internal systems, information technology, records and audits of crypto-asset service providers; and
Communiqué III-35/B.2 on services, trading, custody, transfers, listing and capital adequacy.

The CMB’s official release links to both texts. Separate rules include the Central Bank’s crypto-payments regulation and Law No. 6493 for payment services, MASAK’s AML framework, the Turkish Commercial Code, Code of Obligations, consumer law and data-protection legislation.

A token classification method based on substance

Classification should follow rights, economics and control rather than vocabulary. Use a matrix:

Dimension	Questions	Why it matters
Holder right	Payment, redemption, access, governance, profit, debt, ownership or no enforceable right?	Determines contractual and possible financial character.
Value source	Reserve, issuer promise, protocol cash flow, scarcity, utility or market expectation?	Reveals economic substance and disclosure needs.
Issuer dependence	Does value rely on a company’s performance or assets?	Can bring capital-markets and offering questions forward.
Control	Who mints, burns, upgrades, freezes or changes parameters?	Affects custody, liability, governance and “decentralised” claims.
Distribution	Sale, airdrop, mining, staking, employee grant, liquidity incentive?	Changes purchaser expectations, contracts, AML and tax analysis.
Market	Who lists, quotes, supplies liquidity and communicates price?	Engages platform, listing, advice and market-integrity rules.
Customer journey	Who takes fiat, creates the account, controls keys or executes?	Locates service-provider and payment perimeter.

The output is not merely a category name. It is a legal consequence map showing which feature creates which risk and what design change would alter it.

Tokenised securities and asset-referenced products

Capital Markets Law No. 6362 permits the CMB to determine principles under which capital-markets instruments may be issued as crypto assets and recorded in electronic environments supplied by crypto-asset service providers, potentially with integration to the Central Securities Depository, MKK. That statutory power should not be confused with a general permission to issue any tokenised share, bond or fund interest immediately.

The CMB’s September 2024 principle decision stated, in substance, that before the Board issues the relevant framework under Article 13, crypto assets based on capital-markets instruments and specified indices, baskets, precious metals or other referenced assets could not be issued and listed in the described manner. A project should verify the current legislation and CMB decisions immediately before structuring an asset-backed token.

Putting a property, share, commodity or receivable into a special-purpose company and issuing a “utility token” does not remove the underlying economic claim. Analyse the holder’s contractual rights, insolvency position, transfer formalities, registry effects, offering, marketing and secondary market. A blockchain record does not replace a legally required title or registry unless legislation gives it that effect.

Token sales and marketing to Turkish residents

A token distribution may involve a direct issuer sale, launchpad, exchange initial distribution, private placement, airdrop, employee allocation or liquidity incentive. Each route should identify seller, purchaser, consideration, representations, eligibility, lock-up, governing law and dispute forum.

Marketing analysis should cover Turkish-language websites, paid search, influencers, local communities, events, affiliates and customer support. Disclaimers cannot contradict the commercial reality. “No guaranteed return” does not cure a campaign built around expected appreciation or a redemption promise the issuer cannot satisfy.

For each material statement, keep an evidence file:

the exact approved wording and language;
supporting technical or financial evidence;
the channel and audience;
compensation and conflict of the publisher;
publication and withdrawal dates;
linked risk disclosures; and
version of the product and code to which it refers.

White papers should describe legal rights separately from technical expectations. If governance can change supply or fees, say so. If redemption depends on an affiliate or reserve custodian, identify the dependency. If a smart contract is upgradeable, an absolute “immutable” claim is inaccurate.

Stablecoins: reserve, redemption and control

“Stablecoin” describes an objective, not a single legal structure. Models include fiat-backed issuer liabilities, commodity-referenced tokens, over-collateralised on-chain positions and algorithmic mechanisms. Each should be analysed across five layers.

1. The holder’s claim

Does every holder have a direct redemption right, or only verified customers? Against which entity? In which currency, jurisdiction and time frame? Are fees, minimums, suspensions and sanctions controls disclosed? A secondary-market expectation of one-to-one value is not the same as a legal claim against reserves.

2. The reserve

Identify asset composition, custody, segregation, valuation, liquidity, maturity, credit risk, reconciliation and attestations. On-chain supply must reconcile to off-chain liabilities and authorised mint/burn. A reserve statement should distinguish an audit, attestation and management assertion.

3. Smart-contract powers

Map mint, burn, freeze, blacklist, pause and upgrade functions. Record key holders, thresholds, locations, emergency process and audit trail. Bridged versions may add another issuer or bridge risk.

4. Distribution and regulated services

Who sells, lists, transfers, custodies or redeems the token for Turkish users? Even if the issuer is foreign, a Turkish-facing platform, wallet or broker may require separate perimeter analysis.

5. Failure and enforcement

Plan for depeg, reserve impairment, bank failure, chain halt, key compromise, sanctions action and mass redemption. The plan should define who decides, what can be paused, how customers are informed and which records are preserved.

The FATF’s 2026 targeted report highlights both legitimate uses and illicit-finance risks of stablecoins, including cross-chain and unhosted-wallet challenges. It supports technically capable, risk-based controls rather than a presumption that every stablecoin transfer is suspicious.

Crypto assets cannot be used for payments in Turkey

The Central Bank of the Republic of Turkey’s Regulation on the Disuse of Crypto Assets in Payments provides that crypto assets shall not be used directly or indirectly in payments and restricts payment-service and electronic-money business models involving them.

This rule must be considered separately from holding, trading or transferring crypto assets. Product teams should test merchant checkout, payroll, cards, gift codes, settlement, remittance, invoice netting and “instant conversion” structures. Converting at the edge does not necessarily solve the issue if the commercial arrangement uses crypto indirectly as the payment instrument.

Law No. 6493 is another perimeter. A company that receives or transmits fiat or payment instructions for others may be providing a regulated payment service regardless of its token language. The CBRT’s official payment-services materials explain the authorisation system.

Wallets: custodial, non-custodial and not as simple as a toggle

A truly self-hosted wallet leaves the user in control of private keys and transfer decisions. But modern products may use MPC, account abstraction, recovery guardians, policy engines, embedded wallets or server-assisted signing. The legal analysis should follow actual ability to cause or prevent a transfer.

Ask:

Who generates key material and on which device?
Can the provider reconstruct, rotate or replace the signing authority?
Does the provider hold a key share or control an authentication factor?
Can it whitelist, freeze, rate-limit or redirect?
Who deploys and upgrades the smart account?
What happens if the provider’s server disappears?
Can the user export and use the wallet independently?
Does the interface execute swaps, orders, on-ramps or transfers beyond wallet software?

A product can be non-custodial for keys and still conduct another regulated activity. An on-ramp embedded in a wallet may involve a platform and payment provider. The contracting entity, customer instruction, fiat flow, pricing and settlement must be mapped.

DeFi: protocol, interface and control plane

Decentralised finance includes trading pools, lending markets, derivatives, vaults, liquid staking, bridges and aggregators. “The protocol is on-chain” does not answer who offers the service. Separate:

the immutable or upgradeable contracts;
the development and governance group;
the interface and domain operator;
the treasury and fee recipient;
the oracle, keeper, relayer or sequencer;
the liquidity and market-making participants; and
the user-facing entity handling fiat, custody or support.

Then map each function: order execution, custody, advice, leverage, payments, issuance, marketing and AML. A decentralised component can coexist with a centralised service at another layer. Geoblocking only the website may not resolve Turkish targeting if the same group actively markets an alternative interface to Turkish residents.

Liquidity pools and automated market makers

Providing one’s own assets to an autonomous pool is not factually identical to operating a customer exchange. Yet the pool creator, interface operator, fee controller and active liquidity manager may have additional roles. Examine who chooses pairs, seeds markets, adjusts fees, routes orders, controls upgrades and markets expected yield.

Impermanent loss, oracle manipulation, toxic flow and contract risk should be described accurately. “Liquidity mining reward” may represent token distribution, compensation or an incentive with tax and marketing consequences. Our Turkish guides to crypto liquidity provision and market making address the regulatory boundary in operational terms.

Lending, yield and leveraged positions

Identify lender, borrower, collateral holder, liquidation controller, interest or reward source, maturity, priority and insolvency treatment. “Earn” can describe genuine protocol fees, borrower interest, treasury subsidy or issuance of a new token. The legal and risk disclosure should reflect the source rather than the interface label.

Promises of principal protection, guaranteed yield or discretionary portfolio management can introduce additional capital-markets, consumer and misrepresentation concerns. The CMB framework restricts products and services that platforms may offer; a Turkish-regulated platform cannot assume that any globally available yield feature can be localised unchanged.

DAOs and governance

A DAO is a governance method, not automatically a legal person. Token votes do not answer who signs contracts, employs developers, owns intellectual property, receives revenue, owes taxes, responds to a court order or bears liability after an exploit.

Governance documentation should identify:

legal wrappers and their functions;
proposal and quorum rules;
delegation and concentration of voting power;
multisignature execution and emergency council;
timelocks, vetoes and upgrade powers;
treasury ownership and payment authority;
service agreements with developers and contributors;
conflicts and compensation; and
dispute, fork, dissolution and asset-distribution rules.

If a foundation or company can disregard token votes, marketing should not portray governance as fully binding. If token holders have no legal claim to the treasury, the documents should say so. Conversely, a legal wrapper should not pretend the DAO has no control when the same founders control delegates, interface, multisignature and upgrade keys.

Smart contracts and enforceability

A smart contract can execute a transaction; it does not necessarily contain the entire legal agreement. Turkish contract law asks about consent, parties, subject, form, interpretation, mandatory rules and remedies. Code may implement performance while off-chain terms govern representations, errors, governing law, risk allocation and dispute resolution.

A robust contract stack aligns:

user-facing terms and interface;
white paper and technical documentation;
deployed bytecode and verified source;
administrator and upgrade powers;
oracle and dependency assumptions;
fees, slippage and execution logic;
governance and emergency procedures; and
choice of law, forum and enforcement route.

“Code is law” is not a complete defence where the interface deceived the user, a key was misused, mandatory law applies or the code did not express the parties’ agreement. Equally, a claimant should not ignore an explicit on-chain action and rely only on expectations created by an unofficial community message.

Staking and validator services

Staking models range from a user delegating directly to a validator to a custodian pooling assets and issuing a liquid receipt token. Analyse custody, slashing, validator selection, reward calculation, liquidity, unbonding, governance rights, concentration and smart-contract risk.

The service-provider perimeter depends on who controls the assets and provides the customer service. A regulated platform’s ability to offer particular activities must be checked under the CMB framework. Disclosures should distinguish protocol rewards from a provider-promised return and state who bears slashing or technical loss.

NFTs, gaming assets and intellectual property

The current operational reference is Communiqué III-35/B.2, Article 49, which addresses separate-market treatment and required disclosures for the specified unique non-fungible and virtual-game assets. The CMB’s 2025/15 bulletin records repeal of the relevant older points. Classification remains functional: a collection marketed as fungible investment units or tied to revenue is not resolved merely by unique token IDs.

Buying an NFT does not automatically transfer copyright, trademark or commercial exploitation rights. The token, media file, metadata, licence and hosting are separate. Project terms should specify what is owned, how media persists, which rights are licensed, whether commercial use is permitted, and what occurs if the server or marketplace disappears.

Gaming projects should also consider consumer terms, virtual-item economies, chance-based mechanics, minors, advertising, payment restrictions and transferability. Converting game assets to external markets can change a closed entertainment feature into a broader financial or payment interaction.

AML, sanctions and on-chain risk

Whether a project is itself an obliged entity depends on its activities and structure. Regulated crypto-asset service providers have detailed MASAK duties. Other businesses still face criminal-law, sanctions, banking and counterparty expectations.

A risk-based architecture can include:

customer and beneficial-owner identification where required;
jurisdiction and sanctions screening;
wallet and transaction monitoring with contextual review;
Travel Rule processes for covered transfers;
self-hosted-wallet and counterparty classification;
source-of-funds escalation;
preservation and authority-response procedures; and
controls for bridges, mixers, privacy tools and cross-chain exposure.

The MASAK crypto-asset service-provider guide addresses the Turkish duties. Risk scores should not be treated as guilt. A label must be reviewed for attribution source, directness, distance, amount, time and plausible economic explanation.

Global groups may also be affected by foreign sanctions rules through entities, personnel, technology and financial relationships. Nationality alone is not designation. The relevant list, person, transaction and jurisdictional nexus must be identified.

Personal data in a supposedly pseudonymous system

A wallet address can become personal data when linked to an identifiable user. Web3 products may combine addresses with IP data, device identifiers, analytics, identity documents, social profiles, transaction histories and risk labels. Public availability of the blockchain does not eliminate data-protection duties concerning the enriched profile.

Design should address purpose, legal basis, transparency, minimisation, retention, security, vendor access, cross-border transfers and rights requests. Immutable storage creates particular difficulty: avoid placing unnecessary personal data directly on-chain. Use off-chain references, selective disclosure and revocation-aware architectures where the product permits.

Risk labels deserve governance because a false attribution can restrict a user across several services. Record model or vendor version, input, decision, reviewer and appeal or correction pathway.

Tax and accounting: build the facts before applying labels

Token issuance, treasury sales, employee grants, staking rewards, protocol fees, swaps and asset disposals can create different accounting and tax questions. The answer depends on entity, residence, transaction character, timing, valuation and applicable Turkish rules. A project should coordinate specialist tax advice with the legal and technical design.

Maintain a transaction taxonomy and valuation policy from launch. Preserve token quantities, contract addresses, wallet ownership, fiat price source, timestamps, vesting, restrictions, fees and related parties. If legal documentation describes a token as prepaid access while accounting treats sale proceeds as an immediate financing return, the inconsistency requires examination.

Incident response for a Web3 project

A protocol exploit is simultaneously a security event, evidence event, governance decision and potential legal dispute. The response plan should not begin after deployment.

Before launch, define:

monitoring for privileged and anomalous transactions;
who may pause, upgrade or communicate;
multisignature and emergency thresholds;
preservation of logs, repositories, devices and communications;
relationships with exchanges, custodians and stablecoin issuers;
authority, insurer, auditor and user-notification decisions;
conflicts where insiders or related pools are affected;
criteria for white-hat negotiation or recovery;
post-mortem governance; and
safe handling of private keys and evidence.

During an incident, preserve the deployed state and relevant block ranges before upgrades. Record the data and reasoning behind emergency actions. A rushed public accusation based on an address label can target an innocent service or compromise recovery. Our blockchain-forensics pillar explains how technical findings should be preserved and expressed.

Market entry: when Turkey is part of the product

A foreign project should assess Turkey before translating its website. Relevant facts include local-language marketing, Turkish communities, affiliates, resident users, TRY rails, local employees, group entities, token listing, customer support and events. For regulated platform services, the law identifies specific Turkey-targeting indicators for foreign providers.

Use a route-to-market memorandum:

map features and controlling entities;
classify token rights and distribution;
identify CMB, payment and AML perimeters;
decide whether to establish, partner, restrict or redesign;
review marketing and language;
design custody and data flows;
perform sanctions and banking feasibility;
align contracts, code and governance; and
test an incident and exit scenario.

For businesses operating a trading or custody venue, see our detailed guide to crypto exchange licensing and compliance in Turkey.

Listing a project token on a Turkish platform

For a project, admission to a Turkish platform is not simply a commercial negotiation with the listing team. The platform must operate a listing committee and apply the criteria and processes under Communiqué III-35/B.2. The project should expect requests that join legal, technical, market and financial information.

A disciplined listing package explains corporate and beneficial ownership; token rights; supply and allocation; issuer and foundation relationships; vesting; treasury holdings; administrator powers; smart-contract audits; network and bridge dependencies; market makers; related-party transactions; litigation; sanctions; and material incidents. If there is no issuer or contractual obligor, state that accurately and identify the persons who still control development, interface, treasury and upgrades.

Tokenomics should reconcile to on-chain reality. Total and circulating supply, locked allocations, mint capability, burns and treasury movements should be reproducible. A vesting schedule in a presentation is not evidence if the controlling wallet can transfer freely. Related wallets and market-making inventory should be identified under controlled confidentiality so the platform can monitor concentration and abusive trading.

The project should also plan for continuing monitoring. Events that may require immediate disclosure or renewed platform assessment include an administrator-key compromise, unexpected mint, bridge exploit, material governance change, core-team departure, legal proceeding, sanctions designation, reserve issue, depeg, loss of an essential oracle or misleading public statement. Delisting rules and migration procedures should be understood before admission, not after a crisis.

Commercial payments to a platform, affiliate, adviser, promoter or market maker require conflict analysis. A listing committee’s regulatory responsibility cannot be replaced by an issuer warranty. Likewise, an exchange listing does not amount to CMB approval of the token or a guarantee of value.

Consumer-facing design and unfair certainty

Retail Web3 interfaces compress technical complexity into simple buttons. That design can improve access, but it can also hide the moment at which custody changes, an irreversible approval is signed, a bridge substitutes an asset or a yield position becomes illiquid. Legal review should follow the user journey screen by screen.

Material information should appear before the consequential action, not only in long terms linked from the footer. Examples include: whether the user is granting an unlimited token allowance; whether the received asset is a bridged representation; who can upgrade the contract; whether redemption is available to that user; which fees and slippage apply; whether the provider or an external protocol controls execution; and what happens during a chain halt.

Risk disclosure is not a catalogue of every imaginable danger. It should be specific enough to explain the product’s central dependencies and balanced against promotional claims. A page that describes double-digit yield as passive income and buries loss of principal in generic technical risk language creates a distorted impression even if every sentence is literally present somewhere.

Support scripts also matter. Agents should not promise that a transaction can be reversed, that a platform is “government approved”, or that a frozen token will certainly be released. Complaints can expose repeated design or control failures; they should feed product, security, listing and compliance governance rather than be treated solely as customer-service metrics.

Contracts among founders, developers and infrastructure providers

Many Web3 disputes begin because the token documents are detailed while the working relationships are not. Founder, developer, foundation, laboratory, market maker, validator, oracle, custodian and interface operator should have contracts that match actual control.

Key provisions include intellectual-property ownership and licences; responsibility for repositories and deployment keys; acceptance testing; audit and remediation; service levels; incident cooperation; confidentiality; personal data; regulatory access; sanctions; token compensation and vesting; conflict rules; liability; termination; transition assistance; and return or destruction of credentials. “Open source” does not decide ownership of trademarks, interfaces, datasets, confidential code or the duty to maintain a deployment.

Token compensation should state quantity, contract, vesting, conditions, valuation approach where relevant and treatment after termination. If a contributor receives governance power or administrator access, that authority should be documented separately from economic compensation. A departing developer must not retain an undocumented production key merely because access was convenient during launch.

Infrastructure dependencies deserve exit planning. If a project relies on one cloud, RPC provider, bridge, oracle, sequencer, custody vendor or front-end domain, the contract should support continuity, data export, audit and emergency transition. The legal allocation should be tested against what the code can actually do; a contract cannot restore an upgrade key that was never backed up.

A launch dossier that can survive diligence

Investors, banks, exchanges and regulators will test whether the product story matches the evidence. A useful dossier contains:

legal-entity and beneficial-ownership chart;
service, fund and data-flow diagrams;
token-rights and regulatory classification memorandum;
contract inventory and user terms;
deployed contract addresses, source, audits and upgrade map;
key, multisignature and administrator-control register;
distribution, vesting, treasury and related-party schedules;
reserve and redemption framework where applicable;
AML, sanctions and monitoring design;
privacy and cross-border data map;
marketing substantiation file;
tax and accounting policy;
incident and continuity playbooks; and
change log connecting every material product change to renewed legal review.

Experience across exchanges, banks, crypto projects and contested transactions shows why the change log matters. A legal opinion can be correct for a non-custodial beta and wrong after the team adds embedded key recovery, fiat conversion and managed routing. Compliance must follow the deployed product, not the product remembered at launch.

Common structural mistakes

Classifying by name. “Utility”, “governance” and “NFT” are not exemptions.
Ignoring administrator powers. Technical control can contradict decentralisation and non-custody claims.
Using a foreign entity as the entire Turkey strategy. Targeting and local functions still matter.
Treating the payment ban as a trading ban—or ignoring it entirely. The product flow must be characterised accurately.
Confusing a CMB list entry with authorisation. Verify current status and activity scope.
Promising stable value without defining redemption. Market price and legal claim are different.
Copying global terms. Local service, remedies, restrictions and contracting entity may differ.
Putting personal data on-chain unnecessarily. Immutability makes correction and minimisation difficult.
Leaving incident authority ambiguous. During an exploit, unclear powers consume the time needed for preservation.
Freezing the legal review while code changes. Product drift is regulatory drift.

Questions that should be answered before launch

Who is the customer contracting with? What enforceable right does the token confer? Who controls the contract today and after an emergency? Does any Turkish-resident journey involve an order, custody, initial distribution, investment advice or payment service? Can the user pay for goods directly or indirectly with the asset? How do fiat and crypto move? Which entity receives fees? What happens on insolvency? Can each public claim be proved? Can a disputed transaction be reconstructed? Can the team preserve evidence without exposing keys? What changes require renewed advice?

If those answers exist only across a founder’s memory, a developer chat and an old white paper, the project is not ready for Turkish legal review or serious diligence. The aim is not documentation for its own sake. It is to make the allocation of value, control and responsibility visible before a regulator, bank, user or incident forces the question.

Related Pega Hukuk analysis

Official sources

İlgili çalışma alanı: Token İhracı, DeFi ve Blockchain Projeleri Hukuku — Blockchain girişimleri, token ihraç eden projeler, DeFi ve GameFi ekipleri, yatırımcılar.

Related English guides on Turkish P2P law

Use these guides for the transaction-specific questions:

Token, Stablecoin, DeFi and Web3 Law in Turkey: Project Guide