Spiko is a regulated financial institution based in Paris, dedicated to building a cutting-edge tech infrastructure that enables the issuance and seamless 24/7 transfer of Internet-native financial instruments.
Our first two products are the world’s first fully-licensed Money Market Funds, issued on public blockchain networks and accessible to all types of investors. As of now, these funds have successfully attracted over a quarter of a billion dollars in assets under management.
In this post, we’d like to share some of the technical decisions behind our smart contract architecture. If you’re curious about the code, it’s fully open-source and available here.
Why We Chose to Build on Public Blockchains
From day one at Spiko, we’ve been driven by the belief that the future of payment systems and capital markets lies in open-source, decentralized infrastructure. The existing financial back-end is built on a siloed architecture, leading to persistent reconciliation challenges. In our view, it’s increasingly misaligned with the expectations of a digital-first world.
What once seemed like a bold idea is quickly becoming mainstream. Industry leaders are increasingly aligning with this vision. Larry Fink, CEO of BlackRock, has openly spoken about the transformative potential of tokenization. Stripe’s 2025 annual letter highlighted tokenization as a key pillar of modern finance. And we’ve written extensively about this ourselves on our blog.
Designing Our Token Contracts
At the core of Spiko’s products is our Token contract, which represent shares in open-ended European mutual funds — in the financial jargon referred to as UCITS (Undertakings for Collective Investment in Transferable Securities).
These are standard instruments in the financial world, and their fungibility made ERC-20 the obvious starting point for our on-chain representation.
Before building our own contracts, we explored existing frameworks like ERC-1400 and ERC-3643, which were designed with security tokens in mind. These standards provide extensive compliance and transfer control features, but we found them too heavyweight and overly complex for our specific use case. Instead, we opted to build something simpler and more focused.
Our token contracts are based on OpenZeppelin’s ERC-20 implementation, with some extensions to support additional functionality. We added the key features of ERC-1363, allowing for combined token transfers and function calls. We also support ERC-2612 for gasless approvals via signatures, and our contracts are ERC-2771 compliant to allow for meta-transactions.
Our smart contract architecture is fully upgradeable. We use OpenZeppelin’s UUPS proxy pattern to ensure our contracts can evolve securely over time without disrupting functionality.
Managing Permissions
As a regulated financial institution, investor onboarding and access control are critical. Only allowlisted addresses — those that have passed the required KYC checks — can hold Spiko tokens. To enforce this, we delegate access control to a dedicated smart contract we named the Permission Manager.
We had two key requirements when designing this smart contract.
- First, we knew we’d be issuing multiple tokens over time. USTBL and EUTBL, the shares of our first two funds, are just the beginning. We didn’t want to duplicate permission logic for each new token, so we needed a unique, reusable system.
- Second, we wanted to maintain the flexibility to define different investor classes or access policies in the future — such as a tokenized security restricted to accredited investors.
To address these goals, we created a system based on permission groups. Each address can belong to one or more groups, and each group is granted specific rights over the various smart contracts. When a contract needs to verify permissions, it checks whether the sender belongs to a group authorized to perform that action.
For performance reasons, we cap the number of groups at 256 and use bytes32 bitmasks to represent group membership and access rights efficiently. This avoids computationally expensive loops and keeps gas costs predictable.
Currently, we operate with seven permission groups:
- The super-admin group, controlled by our multisig wallet, has full access to upgrade contracts and manage permissions.
- The exceptional-operator group can pause and unpause token contracts in case of emergencies.
- The daily-operator is an in-house relayer responsible for minting tokens to investor addresses and handling redemptions.
- The oracle-operator is an internal relayer tasked with publishing daily NAV values on-chain.
- The burner role is assigned to the redemption contract and is the only entity authorized to burn tokens.
- The allowlister is an internal relayer used to onboard new investors.
- Finally, the allowlisted group includes all verified investor addresses permitted to hold Spiko tokens.
Net Asset Value
To support integration with financial protocols, a key requirement is ensuring the official price of our tokens is widely available. The price of a fund share, known as the Net Asset Value (NAV), is calculated daily by the fund’s official valuator, in compliance with regulatory standards. We’ve partnered with CACEIS Fund Administration, a subsidiary of Crédit Agricole and one of the world’s leading fund administrators, to ensure full compliance and pricing accuracy.
Once calculated, the NAV is submitted to the French Financial Markets Authority (AMF) and published on its official website, along with major financial data providers like Bloomberg and Morningstar. We also publish the NAV directly on-chain, allowing smart contracts to access an official, tamper-proof token price. Our Oracle contract follows a deliberately simple design, implementing Chainlink’s standard AggregatorInterfaceV3.
In addition, we recently announced an official partnership with Chainlink. Through this integration, Chainlink receives the NAV directly from CACEIS and publishes it on-chain - further strengthening the reliability and decentralisation of the data feed.
The Redemption Flow
When investors want to redeem their tokens, they interact with our Redemption Contract. This process starts with a call to transferAndCall, which transfers tokens and simultaneously logs a redemption request.
During the redemption process, investors specify whether they wish to receive fiat or stablecoins, with multiple currencies supported. These requests are batched and processed daily. At that point, the contract burns all tokens it holds, and the corresponding transfers are initiated.
Wrapping Up
To summarize, Spiko’s tokenization stack currently includes six key smart contracts that work in concert to support the lifecycle of tokenized financial instruments.
These contracts have been audited by Trail of Bits. You can find the full audit report here.
Questions or Feedback?
We’re always happy to connect with fellow builders, investors, and curious minds. If you have questions about our smart contracts, our architecture, or tokenized financial instruments in general—don’t hesitate to reach out.