$1B across 7 blockchains: deep dive into the tech architecture of Europe’s largest RWA issuer

Transcript

Hello everyone. I'm really happy to be to be today at ITC. My name is Nicolas and I'm a software engineer at Spiko. And today I will talk about how we manage over 1 billion dollar of real world assets on seven different blockchain. So, first of all, what is Spiko? So, Spiko is a new regulated investment firm licensed by the AMF in France.

So, we manage tokenize financial product on public blockchain. Our smart contract are open source and the audit report are are available online. Um, basically our financial product that that are are tokenizing are the our flagship today. It's uh money market fund money market fund product. It's T-bills. Uh, and as of today we have practically 1.5 billion dollar asset under management which makes us the third uh biggest actor of tokenize

T-bills globally. So, I told you that we are live on seven blockchain. Here they are. So, we we are live on five EVM compatible blockchain, namely Ethereum, Polygon, Arbitrum, Base and Italia, but we are also live on StarkNet and we live on Stellar. We plan to be live on many more blockchain and there are several coming coming up this year.

But, this setup brings us a very technical engineering challenge. How we can safely operate on seven blockchain in a consistent manner uh without relying too much on uh blockchain specific implementation. To answer this this question, uh I need to talk to you to to a little bit about our goal and our vision.

For us, blockchain, it's at first it's a concept more than an implementation or a technology. We want to rely on core blockchain property such as transparency, auditability, security, and traceability. So, that's the main principle on which we want to build Spiko and that we rely on this principle. The blockchain is really our core technology. Everything in Spiko is derived from the blockchain. The blockchain is really our single source of truth.

So, in order to to be able to to uh um uh to design such a infrastructure, we need to to have standard blockchain agnostic smart contract architecture uh which have the same uh separation of concerns, the same role, the same workflow, the same life cycle. Uh that's for the on-chain part, but there is also the off-chain software component that also need to be blockchain agnostic and generic.

The idea at the end it's to be able to be able to add a new network not in months, not in weeks, but in days. And it should be as simple as knowing and implementing smart contract in a given technology for given new blockchain and implementing a bunch of uh of software component for all our off-chain interaction. So, here it is, our smart contract architecture. So, as you can see, it's it's we aim it to be quite simple. It's composed of four of four main smart contract. The most

important one is the token smart contract. So, the token smart contract represents the one financial product on our platform. So, we have one smart contract token deployed per financial product. For example, I talked about money market fund. We have euro money market fund which is called UETBL. It's a smart contract of token smart contract and we have a dollar uh money market fund and it's also a token smart contract deployed on chain per network.

If you're familiar with the EVM ecosystem, it can be seen and it's actually the implementation for the EVM implementation as ERC-20 permission token. But, really that's the EVM implementation and we want to see it as a generic token implementation. So, there is an instance of the token smart contract and then we have the three other smart contract, the minter, the redemption, and the permission manager smart contract which are uh singletons. So, there is only one instance of each of these smart contract per network.

And they are all the they are the smart contract that handle the security and the operation of the fund on chain. So, that's that's the these smart contract uh ensure us that we are operating the fund properly and securely on chain. And they are only each of them are only their their own flow, so the minting flow, the redemption flow, and the permission flow. So, we will look a little bit deeper on each of these smart contract to give you an idea of of how it works and what guarantees it gives us.

So, to begin with the permission manager contract, it's the one of the most important actually. It gives us it's it's really the the central permission authority. It can be seen as as an access control manager for all the other smart contract, but also address as I said our token our permission token. So, we need to white list and all the the investors that want to that have wallets and want to invest on Spiko. So um it's not a complete list of all the role that can be that can be granted in our setup.

But, there are some of them here. And as you can see there are several persona in in in our setup. You have the the multi-sig, some smart contract, the relay wallet, and the investor wallet. So, the multi-sig it's really our team operational wallet. So, that's really the admin. It's human operated wallet, so it's not programmable and it's the wallet that can grant the sensitive role to the other part of the system.

It can grant the role for the smart contract different smart contract which have dedicated role which allows them to to to efficiently um uh go through the the different flows, redemption flows and minting flows. But, there are also the relay relay wallets. The relay wallets, they are operational wallets, but which are managed programmatically by Spiko app. So, this wallet the relay relay wallets are initiating all the operation of our fund.

For example, they are dealing with the white listing operation, so they have the white list role, but also they are initiating all the operation that that will then interact with the other smart contract and by with the mint initiator role. And then we have the investor wallet of course which has the which are have the white list role. It's quite important to to have it in mind because we are our setup is hybrid, so we are we we handle on the same time custodial wallet, so investors that delegates the custody of their wallet to us and self custodial.

So, our system should work efficiently with both case. So, the minter the minter smart contract, so to to follow the all the this this role this role setup, let's have a look at the minter smart contract which is using this this permission setup to effectively control how we can mint token in our system. So, the minter smart contract it should be seen as our safeguard again against infinite mint problem, bugs, or attacks.

So, internally, the minter smart contract holds a daily limit for each token. So, basically, each day you can only mint fixed amount of of token automatically. And then it needs to go through a two-phase approval. So, basically, our operational wallet as we've seen before which have the mint initiator role can interact with the minter smart contract. It will try to initiate a mint.

For example, when when we received money in in the fund and we want to issue token that are related to related to this to to this subscription to the fund. And the Minter look at the at its internal state and look if if it's under the daily limit. If it's under the limit, it pass through and it invokes directly the the mint function of the token and that's it. But it's if it's over the daily limit, it's blocked and it's logged inside the internal state of the Minter smart contract. Then it needs human intervention from the multi-sig that is the only one which have the mint

approval role which is really the the safe the safe guard of all the of all this setup and which is the only one who can approve or cancel a mint operation that is that has been blocked. How do we know when a mint is blocked or not? The Minter smart contract like all our smart contract have a standard set of blockchain events that can be logged inside the inside the blockchain. It's it's event in in in EVM and it's the and it's a standard component of all the blockchain that we are operating on. And so we monitor for for the mint initiated

event. There is a mint blocked event and with all these event we know when when we should when we should intervene with human operation to unblock the situation. The other piece of the puzzle is the redemption contract. So the redemption contract it's quite similar to the Minter contract and but it's serve another purpose to help us to mimic the how the our fund is working because at the end we working we working with real world assets. So we so we have real world obligation and and constraints.

So and basically we working with wallets of investors that are custodial that we own and wallets that are self-custodial that we don't hold. So we want an experience that is that is fluid and simple for for investor. So we want them to be able to to redeem with one operation and then that don't should not care when the when the fund is really doing and executing the redemption depending on the on how the fund is is working. For us for example, nowadays we have one fund execution per day. So we have we have one time each day where we can execute the redemption.

So to tackle this problem, we have also two-phase workflow. First of all, the investor will transfer his token to the redemption contract. And at this phase we can see the redemption contract as some kind of vault segregation account where the fund are segregated and waiting to be redeemed effectively. And so it's stored in the internal in the internal state of the redemption contract and it's waiting for from the operator to execute it effectively. And then when we effectively with the fund process the different redemption and to

leave the blockchain to to go to the real world our operational wallet call and interact with the redemption contract to execute the the redemption effectively with with the proper ID to to call the the burn function of the token. So there is really two flows to two main flows, the minting flows and the redemption flows. And these contract are the only ones that can interact with the token sensitive function directly, namely the mint and the burn function.

So that's for the on-chain architecture. What about the off-chain story? So for our off-chain architecture, we wanted to to to follow the same philosophy. So the idea is really was to to to implement a stack and an application that is the most standard web3 application that could that we could think of. So the the component are what every blockchain application should should have, namely the relaying infrastructure and indexing infrastructure. But what we wanted to to to focus on is that

as I said, blockchain is our core a core infrastructure. We rely entirely on the blockchain. So it's really a core business core business technology for us and so we need to own all the core logic of the interaction with the blockchain. So we wanted to limit as much as possible our exposition to third-party provider. So basically we have two third-party providers that are really thin layer.

The first one is our wallets provider which nowadays is defense and which can be seen really as a key management system. Basically it's our blockchain primitive provider. We call it to sign transaction and that's it. So that's really a sign signing function provider. And the other third-party provider is the RPC provider. It's mainly a node of the network and that's it. All the rest is in-house. The relay and the and and indexer are have been developed in-house

to to own really the broadcasting logic which which is which is different from every blockchain with different different way to ensure unicity to ensure uh repeatability etc. And to own completely the indexing the indexing part which also is very blockchain specific. Uh Also the idea was to was to be able to have as as much traceability as possible. So every time we can do it, we try to match all the the event we get back from the

from the blockchain to to the transaction we we sending. That making really a loop that that allows to know perfectly everything that is that is going on-chain and everything that has been initiated by us very easily. So the Spiko app the Spiko system broadcast transaction through the relay. So all the blockchain is abstracted from all the other part of Spiko system. And the relay talk to the blockchain and send the transaction and then the event come back come back through the indexer and then hydrate all the Spiko service. Spiko for from the point of view of Spiko service

it's really only events that that exist. The rest of the blockchain does not really exist. So to conclude what we've learned when we implemented this this cross-blockchain design is that really blockchain it's a concept. You do really don't want to rely on specific implementation or specific technology that change the standard change and there are new blockchain that can pop every time.

But if you rely on the concept of blockchain you can redesign an application that is that that can grows and scales through time to to the current technology but to the to the next technology that are to come. Thank you very much. If you want to deep dive a little bit, all our smart contract are open source. So you can find them on GitHub organization. We have also quite active tech blog and we post quite often all the news about the lastest the lastest smart contract development or other cool computer

science stuff. So do not hesitate. And by the way, we are hiring. So if you're up to the adventure of real world real world assets, let's talk. Thank you very much and I'll be happy to answer all the question. What led to the decision to roll out into seven blockchains? Was it demand driven? And the second question small question is how much of your clients are self-custodial at the moment?

So um to to to answer to the second to the second question, I would say that uh most of our client at uh that's really one of the strengths of Spiko is that we're bringing uh web two people to web three environments. So, a lot of our clients are self-custodial because they're from this environment. So, I would say most mainly like five five to 10% are self-custodial and the rest are uh are custodial uh are custodial customer.

And what drives us to integrate new network? I mean, with this architecture, uh it's mainly a uh an ecosystem and an an advantage for us. I mean, it's like Microsoft. We can be everywhere if we if we want because for us it's not hard to integrate a new network. Uh what drives us for at the moment, it's demand, it's collaboration, it's integration in uh DeFi environment. So that's all these criteria that can that have drove driven us to to integrate with with new network. But, basically, it's should be and it and it is now effortless for us to

to to go and to integrate with a a new network. Thank you very much.