Switzerland has long positioned itself as a leading jurisdiction for digital-asset business, and its legal treatment of smart contracts is more developed than most. Under FINMA's token taxonomy and Swiss contract law, a self-executing piece of on-chain code can constitute a binding legal instrument – but that proposition only holds when the review is done before deployment, not after a dispute surfaces.
A smart-contract legal review in Switzerland examines whether the on-chain logic is consistent with the applicable legal regime, correctly classifies the token or instrument the contract governs, and maps the liability exposure for each party interacting with it. The review draws on FINMA guidance, the Swiss Code of Obligations, and – for tokenized securities – the DLT Act framework, which introduced distributed-ledger securities as a recognized asset class. One misstep on token classification can convert a product launch into an unregistered securities offering under Swiss law; the same mis-step can trigger parallel exposure in the EU, the UK or the US if the token is accessible to users in those jurisdictions.
This guide sets out the review process step by step, explains where cross-border exposure intensifies, and identifies the decisions that a founder, general counsel or CTO must take before the contracts go live.
Why Switzerland is the starting point for smart-contract legal analysis
Switzerland offers the most explicit statutory recognition of on-chain instruments among major financial centers, and that specificity makes it the right jurisdiction to anchor a review for any business with Swiss operations, a Swiss foundation, or a DAO structured under Swiss law.
FINMA's token taxonomy – distinguishing payment tokens, utility tokens, and asset tokens, with hybrid variants – is the foundational classification framework. The DLT Act, which entered into force in 2021, introduced DLT securities (ledger-based securities registered on a distributed ledger) as a recognized form of uncertificated securities under Swiss civil law. That recognition matters: it means a tokenized bond or tokenized equity right has a defined legal home. It also means the classification question is high-stakes, because asset tokens and DLT securities engage the full weight of Swiss financial market law, including licensing obligations that may require a FINMA-authorized intermediary in the transaction chain.
For a DeFi protocol or a tokenization project, the Swiss environment is permissive in design but demanding in execution. FINMA expects operators to engage with classification early and to document that engagement. We regularly advise clients that self-certification as a "utility token" is not a substitute for the legal analysis; it is the beginning of it.
Step 1: Token classification against substance, not label
The classification of the token or instrument the smart contract governs is the first and most consequential step in any Swiss legal review.
FINMA applies a substance-over-label approach. The rights conferred by the token – economic returns, voting rights, redemption claims, access to a service, or some combination – determine the classification, not the name given in the whitepaper. A token marketed as a utility token that also carries a profit-participation right will generally be analyzed as a hybrid asset token, engaging the securities and collective-investment-scheme perimeter.
The practical checklist at this step covers four questions. First: does the token represent a claim against an issuer, or is it purely a medium of exchange or access right? Second: are the rights conferred legally enforceable under Swiss law, and against whom? Third: does the smart contract create any form of pooled investment structure, even informally? Fourth: is there a secondary market expectation built into the token design – and if so, does that expectation trigger the investment-instruments perimeter?
The answers drive everything downstream. A payment token in Switzerland sits closest to a cash equivalent under Swiss AML law, requiring SRO affiliation rather than a full financial-market licence. A utility token with no economic-return element may operate with lighter-touch compliance. An asset token or DLT security engages the securities dealer or fund-management perimeter and requires a licensed counterparty in the issuance or distribution chain.
A common mistake at this step is deferring classification until the whitepaper is drafted. By then, the economic architecture is fixed. We see this pattern repeatedly: the legal team is brought in to review the whitepaper, but the token mechanics – the ones that determine classification – were set by the product team six months earlier. Reversing them after the fact is costly and sometimes impossible without rebuilding the contract.
Classification should be the first legal instruction, not the last compliance check. In our practice, we typically begin a Swiss smart-contract review with a one-day classification workshop involving the technical, product and legal leads before a line of contract code is written.
If you are finalizing your token design and the classification question is still open, contact OBOLUS at info@oboluslaw.com for a scoped classification assessment before the architecture is locked.
Step 2: Does the smart contract constitute an enforceable agreement under Swiss law?
A smart contract is enforceable under Swiss law when it satisfies the conditions of the Swiss Code of Obligations – offer, acceptance, and a sufficiently defined subject matter – and does not conflict with mandatory law or public policy.
That framing sounds straightforward. In practice, four issues recur. First, the question of offer and acceptance: on-chain interactions can constitute binding acceptance in Switzerland, but the interface through which a user reaches the contract (the front end, the wallet interaction, the transaction signature) must clearly evidence the required mutual assent. Where that interface is designed by a third party or is effectively anonymous, the analysis becomes more complex.
Second, the parties: a smart contract that executes against any wallet address raises the question of who the counterparty is. Under Swiss law, a legal obligation must attach to a legal or natural person. A DAO that has not adopted a legal wrapper has no standing to sue or be sued, no capacity to enter a contract, and no ability to hold property. The contract may execute flawlessly on-chain while being legally incoherent off-chain.
Third, mandatory consumer protections: if the contract is accessible to retail users in Switzerland (or in EU member states, the UK, or other consumer-protection jurisdictions), mandatory terms cannot be excluded by on-chain logic alone. The fact that code executes automatically does not override statutory protections that the parties cannot waive by agreement.
Fourth, the governing law and jurisdiction clause: a well-drafted legal review will specify the governing law, identify the dispute resolution mechanism (Swiss courts, SCAI arbitration, or an on-chain/hybrid mechanism), and ensure that clause is accessible and readable before the user interacts with the contract. For cross-border protocols, the governing law choice must be defensible in the jurisdictions where the protocol's users are located.
Step 3: What legal wrapper does the DAO or protocol need in Switzerland?
A DAO without a legal wrapper is not a legal entity; it is a general partnership by default under Swiss law, with unlimited joint and several liability for each participant.
That default outcome is rarely what founders intend. The review at this step maps the available Swiss structures against the protocol's governance model, risk profile and cross-border footprint. The principal options in Switzerland are the association (Verein), the foundation (Stiftung) and the stock company (Aktiengesellschaft). Each has a distinct liability profile, governance structure and tax treatment.
The association is the most common vehicle for non-profit protocol governance in Switzerland. It has legal personality, can hold assets and enter contracts, and does not require a minimum capital. Its governance structure – membership voting – maps reasonably well onto token-based governance if the rules are carefully drafted. The limitation is that the association structure is not designed for profit distribution; a protocol with a treasury that generates returns for token holders will generally need a different or supplementary structure.
The foundation is suited to protocol deployment where ongoing governance is meant to be insulated from any single stakeholder. Its rigidity – Swiss foundations cannot be easily dissolved or restructured – is a feature for some projects and a constraint for others. The foundation cannot distribute profits, making it unsuitable as a standalone structure where token holders expect economic returns.
The stock company is used where the entity needs to raise capital, issue equity, or enter commercial contracts at scale. It is the appropriate choice for a tokenization platform or a Swiss VASP applicant. It is not inherently suited to DAO governance unless combined with a secondary association or foundation layer.
The cross-border question matters here. A Swiss legal wrapper provides Swiss legal certainty; it does not immunize the protocol from regulatory analysis in the jurisdictions where users or liquidity providers are located. A Swiss association operating a DeFi protocol accessed primarily by EU users will face MiCA analysis regardless of its domicile. We work through these layered structures with allied counsel in the relevant jurisdictions where the Swiss perimeter meets foreign regulatory regimes.
Step 4: When does a Swiss smart contract require FINMA licensing?
A smart contract does not require a FINMA licence by virtue of being a smart contract. The licence obligation turns on the regulated activity the contract facilitates.
Under the Swiss financial market regime, the relevant licence categories for digital-asset business are the fintech licence, the banking licence, and affiliation with a self-regulatory organization for AML purposes. The fintech licence, introduced to accommodate deposit-taking business at a lower threshold than a full banking licence, is available to entities accepting public funds below a defined threshold; operators above that threshold need a banking licence. The SRO affiliation requirement applies to any business operating in the payment-token environment.
For a DeFi protocol or tokenization project, the licensing question turns on three factors: whether the smart contract takes custody of user funds, whether it issues a security or a collective investment scheme instrument, and whether it matches buyers and sellers in a way that constitutes operating a trading facility. Any one of these can trigger a licensing obligation independently.
The review maps each contract function against these triggers. A liquidity pool contract, for example, may take custody of funds (custody perimeter), may issue LP tokens that represent a pro-rata claim on pooled assets (securities perimeter if the rights are sufficiently investment-like), and may execute automated trades on behalf of depositors (trading facility perimeter). These are not mutually exclusive. A single contract can touch multiple perimeters simultaneously.
Where FINMA licensing is triggered, the review identifies the licence category, the minimum capital requirement (which varies by category and is a [VERIFY] figure not stated here as a hard number), and the interaction with AML/SRO obligations. The process typically involves a pre-application engagement with FINMA – an informal query letter or a formal no-action request – before the licence application is filed.
If your protocol is approaching a deployment decision and the FINMA licensing question remains open, contact OBOLUS at info@oboluslaw.com. A prior stalled interaction with FINMA or an inconclusive self-assessment is not the end of the road; a second structural read often surfaces a path forward.
Step 5: Mapping the cross-border exposure – EU, UK and US layers
Swiss regulatory compliance does not end at the Swiss border. For any protocol with users, liquidity or infrastructure outside Switzerland, a multi-layer cross-border analysis is mandatory.
The EU layer is the most immediately pressing for Swiss-domiciled projects. Under MiCA, managed by ESMA and national competent authorities, a CASP (crypto-asset service provider) offering services to EU users must hold a MiCA authorisation in an EU member state, regardless of where the entity is incorporated. A Swiss company is not a MiCA passport holder and cannot operate in the EU market on the basis of Swiss authorisation alone. The review must therefore identify whether the protocol has EU user exposure and, if so, model the options: a separate EU entity, a partnership with an EU-licensed operator, or a geographic restriction on access.
The UK layer is distinct post-Brexit. The FCA's cryptoasset registration under the Money Laundering Regulations is the minimum threshold for UK-accessible crypto business; the financial-promotion regime adds a further layer for any marketing reaching UK retail users. For Swiss operators, the UK is a third country and no equivalence bridge exists. Allied counsel in the relevant UK jurisdiction is required for any substantive UK-facing activity.
The US layer is typically the most complex. The SEC and CFTC maintain extraterritorial jurisdiction claims over digital-asset activities with US nexus. The analysis of whether a token constitutes a security under US federal law is independent of and does not align with the FINMA classification. A payment token under Swiss law may nonetheless be analyzed as a security by the SEC if the economic substance – the Howey test factors – is present. For any protocol accessible to US persons, US legal analysis is not optional.
The AML/Travel Rule dimension runs across all three layers. FATF Recommendation 15 and the Travel Rule (the obligation to transmit originator and beneficiary information alongside a virtual-asset transfer) applies in Switzerland through FINMA guidance and the SRO framework. The threshold and de-minimis figures are subject to FINMA's current published guidance; we write qualitatively here because those figures are subject to change and should be confirmed against the current applicable regime. The same obligation applies in the EU under MiCA and TFR, and in the UK under its own Travel Rule framework. A cross-border deployment must therefore implement a Travel Rule compliance solution that is interoperable across the jurisdictions in play.
Step 6: Liability allocation and the governance map
When a smart contract fails – whether through a code exploit, an oracle failure, a governance attack, or a legal interpretation that differs from the developer's intent – the question of who bears the loss is resolved by the legal structure, not the code.
Swiss law does not provide a special liability regime for smart contracts. Liability analysis applies the standard tort and contract principles of the Code of Obligations to the on-chain facts. The review at this step identifies each potential loss scenario, maps it to the parties who could be held liable, and assesses whether the legal wrapper insulates those parties or exposes them.
The most common gaps we see are three. First, a developer entity that has no contractual relationship with the end user but has deployed a contract that the user relies upon. Under Swiss law, a developer who makes representations – in documentation, a whitepaper, or interface text – about the contract's behavior may incur liability in delict if those representations are false and a user suffers loss. This is not a remote risk; it has materialized in multiple jurisdictions. Second, a DAO governance process that results in a parameter change triggering a loss – who authorized that change, and was that authorization legally valid? Third, an audit scope that is narrower than the deployed code – a security audit that covers one version of a contract but not a subsequent upgrade, creating a liability gap between the audited and the live logic.
The governance map produced at this step defines who can amend the contract, under what conditions, with what authorization threshold, and subject to what legal constraints. It also defines the dispute resolution path: if a user suffers a loss attributable to the contract, what forum has jurisdiction, under what governing law, and what remedies are available?
In a recent tokenization matter, a European project deploying a Swiss-law DLT securities issuance engaged us to review the smart-contract governance framework before the first tranche was issued. The initial draft gave a single multisig holder unilateral amendment rights over core economic parameters. We restructured the governance into a two-layer model – a time-locked technical upgrade path with a separate legal amendment process requiring notarial authorization for any change to the investor-rights parameters. The structure was accepted by the Swiss-based custodian and the issuing agent without renegotiation.
Self-assessment checklist before your smart contract goes live in Switzerland
Before deployment, a Swiss smart-contract legal review should confirm the following at minimum.
On classification: the token or instrument has been classified against the FINMA token taxonomy; the classification analysis is documented and signed off; hybrid characteristics have been identified and their regulatory implications assessed.
On enforceability: the offer, acceptance and subject-matter elements are legally coherent; the governing law and jurisdiction clause is accessible and readable; mandatory consumer-protection provisions have been checked against every jurisdiction where retail users may access the contract.
On legal wrapper: the operating entity has legal personality in Switzerland; the DAO governance rules are consistent with the wrapper's constitutional documents; the liability exposure of founders and token holders has been mapped.
On licensing: the FINMA licence perimeter has been assessed for each contract function; SRO affiliation obligations have been confirmed; any cross-border licensing requirement (MiCA, FCA, US) has been identified and is being addressed separately.
On cross-border: the EU, UK and US user exposure has been quantified; a Travel Rule compliance solution has been identified and is compatible with the deployment jurisdictions; allied counsel has been engaged for any material foreign regulatory exposure.
On liability and governance: the governance map is complete; the dispute resolution clause is valid and enforceable; the developer's liability exposure has been capped or allocated contractually where Swiss law permits.
No checklist replaces a tailored legal review. The questions above are the minimum scope; the analysis behind each is where the work sits.
Related at OBOLUS
- DeFi, tokenization and smart-contract law for digital-asset businesses – how OBOLUS structures DeFi, tokenization and on-chain legal analysis for operators worldwide.
- DeFi protocol legal structuring in South Korea – the equivalent review process for protocols with Korean market exposure or domicile.
- Crypto exchange licensing for established operators – FINMA and multi-jurisdiction licensing strategy for exchange operators seeking Swiss or EU authorisation.
FAQ
Can a DeFi protocol be regulated?
Yes. Whether a DeFi protocol is regulated turns on what it does, not how it is labeled. If the protocol takes custody of user funds, operates an automated trading facility, issues instruments with investment characteristics, or otherwise conducts an activity that requires a licence under Swiss financial market law or MiCA, the regulatory perimeter applies regardless of the degree of decentralization. FINMA and ESMA both apply substance-over-form analysis. A protocol that is sufficiently decentralized to have no identifiable operator may escape some obligations, but that threshold is demanding and not met by most live DeFi deployments.
What legal wrapper suits a DAO?
In Switzerland, the association (Verein) is the most common legal wrapper for a non-profit DAO because it has legal personality, flexible governance and no minimum capital requirement. A foundation suits projects where governance insulation and permanence are priorities, but it prohibits profit distribution. A stock company is appropriate where the DAO needs to raise capital or issue equity. In practice, complex projects often use a combination – a foundation for the protocol layer and an operating company for commercial activity. The right choice depends on the DAO's economic model, its user base and its cross-border regulatory exposure.
Who is liable when a smart contract fails?
Swiss law applies standard tort and contract principles: the party whose act or omission caused the loss bears the liability. In a smart-contract context, that may be the developer (for misrepresentation or negligent code), the DAO governance body (for a parameter change that caused harm), or the deploying entity (for failing to disclose a known risk). Liability cannot be contracted away where statutory protections apply. The legal structure around the contract – the wrapper, the governance rules, the governing law clause – determines how loss is allocated and what forum has jurisdiction. A pre-deployment liability review is the most cost-effective intervention.
OBOLUS is an independent digital-asset law boutique acting only for businesses. We assess token classification against the substance of rights, not the marketing label – because a utility label on a whitepaper does not settle the legal classification. We advise DeFi protocols, tokenization platforms and DAO operators on licensing across 70+ jurisdictions, on cross-border structuring and on on-chain liability analysis across 25+ forums. Digital assets are the entirety of our practice. To discuss your smart-contract review in Switzerland or across borders, contact info@oboluslaw.com.
By Roman Levitt, Technology & DeFi Counsel – specializes in smart-contract legal review, DAO structuring and DeFi protocol compliance across Swiss and cross-border digital-asset regimes.
This publication is general information about the law and does not constitute legal advice. It is not a substitute for advice tailored to your circumstances. OBOLUS accepts no liability for action taken or not taken on the basis of this material. For advice on your situation, contact info@oboluslaw.com.