Name: Fireblocks Demo and Platform Overview
Uploaded: 2024-09-03T09:17:17.465Z
Duration: 1 h
Description: Fireblocks Demo and Platform Overview

Transcript for "Fireblocks Demo and Platform Overview": Good afternoon, everybody, and good morning. Let's give it a few minutes whilst, whilst we wait for everyone to join. Welcome to, to the September edition of the Fireblocks demo webinar. We look forward to, spending some time with you today to to go through our platform and to to really talk about the use cases that you can unlock, with Fireblocks, with, our director of sales engineering, Ben Wilton. He'll be joining us to to run through, run through the platform, ask answer any questions that you might have. We have a q and a function. Please feel free to drop in any questions that you have along the way. We will save some time towards the end of the webinar to address them. And just another PSA that this session is being recorded. So, you will receive a recording of this, via the same link after the session. So, yeah, I would like to invite Ben to join us and to, to talk through the, the demo. Ben, I'm not sure if we can hear you. Sorry. Just need to get you on stage, Ben. Here we go. There seemed to be a small technical difficulty. Now we can hear you. Wonderful. Thank you very much. So, welcome, everyone, and thank you for joining today. My name's Ben Wilton. I'm the director of sales engineering. I'm based out of Singapore, looking after the APAC region. And here today to present to you, a really sort of brief look into the capabilities of the Fireblocks platform and what we offer as part of your digital assets management and orchestration. What we're going to be covering off today is a view into the Fireblocks wallet infrastructure. We're going to also be talking about some of the other functionalities such as Fireblocks network, tokenization engine, and some of the additional transfer management features that are available as part of our platform. Now what I'll first want to do is to, as as I go through, if you have any questions, as Artie mentioned, please use the q and a. Be very, very happy at the end of the session to answer any questions that you may have. So first and foremost, I want to introduce you to a Fireblocks Workspace. So a Fireblocks Workspace is effectively your own console into the management of your digital assets. And this is, effectively a unique set of private keys to manage all of your self custody wallets within the platform. What you see on the screen in front of you here is the view of all of your accounts and all of the different venues in which I hold assets. 1st and foremost is our vaults, where I have effectively a set of private keys that are managing different wallets. I have connectivity to exchanges where I have different assets which are held across different venues, their amounts. And then lastly, I have fiat connectivity. What I want to do first is take you through some of the other features, which we will then lead into as part of how you can use your assets held within these venues across different features, such as NFTs, having NFT libraries of associated NFT objects that are held within those wallets, the ability to stake assets to different providers such as Figment and Killam, the ability to swap assets through dApps using web 3 connectivity, tokenization of assets, so the ability for you to deploy contracts, mint, burn, and do other contract operations through the Fireblocks console, white listing of addresses and security management around the destinations, the Fireblocks network, which allows you to conduct a secure way of connecting to your counterparties through Fireblocks. We have payments and automation that allows you to set up automated flows between different counterparties, web 3 access, which allows you to interact with various DApps across the web ecosystem, and then, of course, some other administrative features. First up today, I want to dig into the custodial wallets. So Fireblocks is an MPC wallet infrastructure. MPC stands for multi party computation, where Fireblocks helps you manage a distributed key set that ensures the security and reduction of single point of compromise for your digital asset infrastructure. As part of the Fireblocks Vault, you'll be able to create segregation of your assets based on private keys. Now, this is often used for singular operations where a business may have Treasury Vaults, they may have a deposits, they may have client accounts. And creating a new vault is effectively creating accounting segregation, which is governed by those private keys. Within each vault, I'm able to click in and see the different wallets that I'm maintaining there and their associated balances. Example here, USDC, Ethereum, USDT, my associated balances, and then I can see the wallets associated with that. So I can click in here and look at the address in which those deposits can be taken to. I can copy that address. I could even share that address via a QR code. Additionally, I can create activities such as creating a deposit function into those wallets or create a a withdrawal to withdraw those assets out. Moving on to exchanges. This is where you're able to, look at any exchanges that you maintain any balances of by connecting them to your Fireworks workspace. In the case here, I've got 5 different exchanges which are connected, and I can see out of all of those exchanges, I've got a balance of $792 And if I click into Bitso, I'm able to see the breakdown of those balances. I can see that I have, a series of balances across USD, so fiat balances, as well as Ethereum, Beryl, TRX, etcetera. If I wanted to create a movement of those assets, I'm able to withdraw or deposit into those vaults. So an example is I want to move some assets off an exchange. So example here, I've got 0.03 Ethereum, which I would like to take into my internal custodial wallets. So I want to move that into maybe my deposit operations account, and I'm able to specify the amount which I'd like to sweep and then create that transfer. Additionally, if I wanted to rebalance across exchanges and I wanted to move assets to another exchange within my ecosystem, I could quite easily move that Ethereum, choose another exchange, and move those funds to Bitstamp. This is where Fireblocks creates a new paradigm of digital asset operations, where you can move assets between different venues and it acts as the operational window with policy. Lastly is the integration with fiat providers. Fireblocks allows you to integrate and manage fiat balances with any of the approved banks within your region. This also, very similar to digital assets, allows you to create movements of funds between venues. I can withdraw funds from this particular account. I can choose the destination for any destinations that are set up that can take inputs or fares. Quite often, this is used for funding of trading accounts on exchanges. So for example, I want to move my funds to Kraken. I'm able to then fund my trading account directly through Fireblocks. Now moving on to how a transfer actually occurs, I'll do a little bit of a demo of that shortly. Next up, what I want to do is, share with you a little bit about, NFT libraries. So not only do we support over 70 different protocols and thousands of different asset types, we also support NFTs. NFTs are able to be bought from a majority of the popular chains, and listed within the NFT library. So this means if you're dealing with NFTs from a pure custody perspective or providing custody services to your customers, you're able to provide NFT support as well. Within the Fireblocks NFT library, I can see all of the NFTs that are in my wallets that I manage within my Fireblocks workspace. If I have any NFTs which I think are potentially marked as suspicious, for example, this one here, I can mark this one as spam and hide it from my interface and also from my end user. Here as well, I can also withdraw this NFT asset and move this to a destination. So this could be one of my other vaults. So move it into a custodial or omnibus vault, for example. Or if I wanted to move it to somebody who is an external counterparty, a whitelisted account, somebody on my Fireblocks network, I'll also be able to send that NFT as well. Additionally, you can look on the, PolygonScan, OpenSea, etcetera, to go and have a look at the source of that NFT and the broader collection around that. Next feature down here is staking. So staking allows you to connect to different providers on the Fireblocks network to earn yields on your assets. In the case here, we've simplified the user operation where you can simply click to add, your, staking of assets to a provider. In this particular example here, we're supporting Ethereum, Solana, and Polygon Matic. And I'm gonna choose some Solana here. I can choose from which vault I would like to send those funds. So choosing one here that has funds associated. Key in the appropriate amount of, Solana that I'm wishing to stake. So Daisy, it has to be a bit more than that. 0.11. And then I can choose the validator in which I'm going to stake those assets to. In the case of Killen, 7% fee, Figma with a 7% fee. Or do we choose the validator, accept the terms and conditions and click on stake and immediately stake those assets. Next here, we have swaps facility. So currently we support Uniswap for this feature, but we're adding other commonly used d apps, for swaps into this platform. This allows for a secure methodology for your end customers or our end customers to connect through to these d apps, without any any risk of being pointed to insecure contracts or insecure d apps online. This is where you can select the particular vault you would like to select the asset from, choose the asset type, and then choose the, destination asset. So what you're gonna swap into, where I can select and say I want to swap maybe 30 USDC, which will then go to Uniswap and provide me with an equivalent spot in Binance USD. This will then provide me with more information around fees, slippage, and tolerance, and I can then approve and swap and sign that transaction. The next feature down as well is tokenization. This is where you're able to, build your own assets within the Fireblocks ecosystem and manage these contracts. I'll step into this a little bit later on because there's a lot of features involved here. Next is around whitelisting, which allows you to whitelist your external wallets, ensuring that you have a trust system of your trusted external parties and the appropriate addresses that are allocated to those counterparties. Next is the Fireblocks network, which allows you to, connect to over 1800 different providers on the on the Fireblocks network that, you can set up 1 to 1 counterparty connections. So the Fireblocks network is quite unique in the way that, you do not need to manage deposit addresses. You can set up a trusted network, not too dissimilar to adding a connection on LinkedIn. And once that approval has happened within between yourself and the counterparty, you now have a secure deposit account to send funds to. Next, we have payments and automation. This allows you to build payment flows. So end to end, payment functions where you can bring in, for example, crypto pay ins and fiat payouts. This is really sort of an automation suite allowing you to build the different functionalities of Fireblocks where we have the exchanges and fiat providers and create the flows of exchange of assets between those different venues through to payments out to the, the desired destination in the desired format or currency. Lastly, on this suite of products is the Fireblocks web 3 access, which allows you to connect to Dapps using WalletConnect. This gives you the ability to, interact with different, Dapps via web stores. You can scan the QR code, connect via WalletConnect, and then that will allow you to interact with that, contract and then sign the transaction associated with that dApp. Okay. Start. Taking a pause there. I'm going to switch gears a little bit, and I'm going to move to a different Fireblocks Workspace to show you some of the administrative functions that we have available using the Fireblocks platform today. So within the Fireblocks platform, security is, absolutely paramount. Not only are we using MPCCMP to secure your private keys, we've also implemented a number of features on top of white listing that allow you to have a much tighter control of the movements of your assets. From this particular cog up here, I can go into my administrative environment and manage the settings for the Fireblocks workspace. Now each Fireblocks workspace has a unique set of rules, settings, users, and administrators. This each workspace can be built within your business to have different usages. Say, you may have a workspace for your treasury team, and you may have a set of users for treasury and a different set of rules to potentially, a custodial wallets service that you're providing to your end users that may have a different operations team, a different set of managers. So the first level of security segregation would be choosing a Fireblocks workspace or having additional workspaces for the use case. Now within each workspace, you can define the users. So it's very, very easy to manage the roles and users within the Fireblocks platform by clicking on add a user, where you can select somebody who's a workspace user, which I'm interfacing with in the console at the moment, or an API user, which can, enact most of the features within the Fireblocks console just via API calls. Once you've got users added, you can then add them into groups. So I'm able to create groups and add those particular users to then use role based access control around those particular groups based on Quorum and policies. Within the quorums tab, I'm able to see all of the different securities and thresholds, security settings and thresholds associated with it to manage changes in my workspace and manage changes on some of the settings and my policies. I've got a default admin quorum, which controls which changes can be made out of the settings area. So I can change to say, I've got one admin that needs to approve this out of 2 users here. I can change that threshold and put it to the maximum of 2 of the 2 current users at the moment. However, I can get much more granular with my security compliance, user management, Firefox network, and external accounts. Example is for white listing of addresses, do I want to use my admin quorum, or would I prefer to use a specific group and say my treasury management team or my operations team needs 2 of the eligible members in order to approve a white listing address? Additionally, things like user management, you can now apply those roles through to your specific security teams that would manage those features. Now, as far as authentication for these users, we also support single sign on and 2 factor authentication. So Fireblocks has its own built in password control mechanism using very high security standards and 2 factor authentication. However, for a lot of enterprise customers, they may wish to incorporate their own IDP, SSO, or SAML based authentication method, keeping it consistent with your enterprise grade security management for your firm. Good to know that those both are available. So outside of users, groups, and quorums, we have a couple of other very important features that are around securing your transactions. Firstly, is our one time address transactions. By default, you will not be able to send funds out to a single address unless it has been either whitelisted or it is part of your Fireblocks network's approved connections. This ensures that, your funds do not transactions cannot be created to any addresses that are not part of your preapproved list. This is a great feature and generally default, which majority of our customers will keep set, ensuring that no one can just key in an address and start sending funds. Additional to this, and our white listing, is our transaction authorization policy, or commonly known as TAP. The transaction authorization policy allows you to build a set of rules that governs the usage of your assets. Now within this policy, I've got a set of rules that are in a hierarchical order that act very similar to what would be a firewall. By default, when you start with a Firebox workspace, there'll only be one rule, which will be block everything. So as a new user, as a new setup, you would not be able to move any assets. From that point on, you would gradually add more roles sorry. Add more rules into your transaction authorization policy to build up your security layer. So effectively starting off with a zero access level and incrementally adding rules as required for your organization. Within this policy, you're able to create rules based on the initiator, who initiated that transaction, what type of transaction it was. So this could be a transfer contract call, mint, burn operation, variance, the source of that transaction. So this could be from within your own custodial wallets. This could also be from your exchanges or fare providers as well. The destination into which you are gonna be sending those assets. So this is either an internal wallet, external wallet, whitelisting, etcetera. Who is permitted to sign for this transaction, the amounts, so minimum amounts, maximum amounts, the asset types, and then the action. So for an example here, if anyone tries to transfer from my omnibus vault to this particular white listed address anything more than $0, that is immediately going to be blocked. So, effectively, I've set a policy that no one is permitted to send any funds into this account. I'm going to click on edit policy here to show you how flexible this tool actually is in creating your own policy engine. Under here, I can click on add a new rule. And within the rule types, I can see all the different options available to me. So transfer, approve, mint, burn, raw signing transactions, and also staking. So in the case of I want to set a transfer policy to say that, from AnyVault to any let's say, all of my Bitfinex exchange accounts, that's only a specific user is able to initiate that, or it can only be initiated from the operations team. The signer is going to be the initial area as well. And I'm going to limit only to a certain type of asset. Say, for example, I'm only going to allow for BTC test to be sent through that. And as part of that, I'm gonna require that somebody needs to approve that transaction. So I'm gonna say that one person from the treasury management team needs to approve that before that, transaction can be serialized and then signed. So with this framework, examples that I've got built here is around weemix tokens. So I've got a rule here, rule number 3, that says any weemix test tokens that are sent to, sent out of my treasury vault to any destination, it will be allowed and that will be able to be automatically signed by my communal cosigner. Anything more than 2 wemix token is going to require the approval of 1 group. That is, 3 of the operations team. Let's see this in action. So if I go to my assets view and look for WEMIX tokens, I'm able to see my treasury vault, which the rule applies to. I'm gonna create a withdrawal. I'm gonna select my mint vault as the destination. I'm gonna select the amount to be under 1 WEMIX and say small transfer and click on transfer. Now what this is going to do is going to run that transaction through that rules engine. It's going to find that this transaction type matches rule 3, which does not require any approvals. So we'll see that it's now moved on to pending signature. That signature will then be completed by my API cosigner, and that is now broadcasting on chain. So this is an example of a high velocity, low value transaction that we deem as part of our standard business operations. Now using the same example, this could be, an example where we do not see that any more than 2 WEMIX being as part of a normal operation. So this would be an aberration that maybe, hey. This is unusual. I would like to have somebody within my operations team approve this. I can select another deposit to the mint vault, and I'm gonna try and move the maximum amount within that vault into another one. Click on transfer. And what we're going to see now is that it's going to try and move all of those funds out of that vault, and behavior has changed. It is now pending the authorization of the team here. So I can see that this is now pending approval. 3 of the operations team. And I see the 3 users there that need to approve this on the Fireblocks mobile application. So within the Fireblocks mobile application, I would then receive a notification. It's probably pretty hard to see on the screen here, but I will now have a transaction asking me to approve this through as one of the quorum. Once all of the approvals have been obtained, that transaction will then move through to the signing phase. Now this is just an example of one of the types of rules that you could create using the Fireblocks transaction authorization policy. But it's a very, very flexible tool. So you can incrementally add your add your rules, including, up to levels of transactions per day. An example would be that if you're moving more than, say, $250,000 worth of BTC out of your treasury vault within one day, then you may wish to block anything greater than that. That ensures that if somebody was to somehow obtain any credentials in order to move assets, that you can very quickly stop that by putting a upper limit on transaction volumes outbound. What else do we provide you to secure your funds? Well, security of your assets is one part of it, but there's also, very importantly, compliance. This is part of your KYT and KYC capabilities that often, as a institution, you will need to think about. This is where Fireblocks has integrations with companies like Notte Bene, Elliptic and Chainalysis that provide different services that allow you to inspect both inbound and outbound transactions into your Fireblocks wallets. An example is you're wanting to create a transaction to an external wallet. Once you've created that transaction, it is then gonna be scanned by Chainalysis to see if maybe this wallet is on a sanction list. It will then define that transaction as a high risk score. And then by the setup of your compliance engine, you can choose to have that transaction blocked or require additional approvals. Now conversely, if you were to receive funds into your Fireblocks wallets as a deposit, Chainalysis Elliptic would be able to scan that transaction as it comes into your vaults. And if that funds if those funds are deemed to be coming from a tainted source, you can actually have that automatically freeze that transaction within your vaults and appear as a frozen asset. What this means is that you would not be able to your administrators, your operators would not be able to move those assets unless they are unfrozen by your operations team or your administrators, allowing for them to then access those funds. This is very important for any sort of tainted funds and the, I guess, the view of not wanting to touch them if they're coming from an untrusted source. The next, area which I want to sort of cover off on is a little bit more into the tokenization engine. So as we're seeing, a lot of use cases come across the market for digitization of securities, real world assets, etcetera, and and, stable coins. Firebox has built a very, very rich tokenization capability within our platform. This allows for you to manage your tokenized assets, manage the contracts associated with those tokens, and then also, perform administrative functions without having to code those operations on chain. From within the tokenization engine, I'm able to view any tokens which I have, deployed. I'm able to see any balance of tokens which I'm holding, and I can see the total supply that is available for the contract and also the contract address as well. If I wanted to create my own token with Fireblocks, I can simply click on create. And this will show me a template or a library of different token standards that I can deploy on chain for EVM compatible tokens and also, non EVM tokens such as Stellar and Ripple. Under the scenario here, I've got a series of different tokens here from Bitbong, CMTA, Fireblocks, opinionated contracts and TOKANI. I can select an ERC 20. I can review the token type, the description of what it's used for, stub coins, CBDCs, bonds, etcetera. I can look at the audit report from OpenZeppelin. I can see a brief description of what that contract is actually available, token is available for. I can see extensions available and then I can see the different functions that are associated with this particular token as well. What read functions I have, what write functions I have as part of this. And then if this is the token which I'm really keen on deploying, I can use this contract today. I can enter the token information, put in the, name of the token. So webinar token, wbt. I can choose the admin account which is permitted to oopsie daisy. Sorry. I need to select a chain. Testnet. I'm just going to select, Ethereum here. I can choose a admin account who is permitted to administrate that chain. Sorry. I'm just having a little bit of an issue here. Let's try pulling on testnet. Yes. I can select the vault that is permitted to administrate this token. So I'm just gonna choose my minter vault here. The minting vault as well. So who's permitted to mint that token? And then maybe I'm gonna say my distribution team or my distribution vault is able to pause that token. I can review, which issuer vault is going to do this. I'm gonna select a vault which has the appropriate amount of Polygon assets, MATIC assets to deploy, review the details, look at the different contract addresses, look at the different wallet addresses that will manage this, and simply create token. This is where I can, very quickly create a transaction. And I can see that this is now pending authorization and go through the approval process. Once the token is actually deployed, and I'm just gonna use this example here, my Constellation Euro stable, I can then go and look at this on the Explorer. I can go and manage the contract. I can create smart transfer instructions to send this to my counterparties, and I can unlink this token. So, importantly, I can mint and burn new tokens. By clicking on mint, I can select a vault to choose to mint from where I want to mint to. So this could be to an internal vault, or it could be somebody on my network or an exchange. I want to mint a certain value, 4,000 of the token, and click on the mint button. This will then create a transaction for me to authorize. So depending on your transaction authorization policy, you will have the appropriate approvers to in order to mint that. And then once all the approvals have been obtained, it would then flow to the signing process, and those tokens will be, minted from the contract and then sent to the appropriate destination. Management of contracts is also a very unique feature with Fireblocks. Generally, this would be a, so highly coded, or involve a lot of developers to manage this contract. Within Fireblocks, we actually allow you to do this in a very, low code, no code manner. For example, if I wanted to do, oops. There's a write contracts. So if I wanted to read any functions or write any functions against that contract, I'm actually able to do this within the Fireblocks console. So things like, creating new owners, adding new roles, adding new administrators to this contract, I can do this within the Fireblocks interface without having to build or run a develop environment. And lastly, what I want to share with you as well is a little bit more about the Fireblocks network and how those connections work and if how and how, the transfer of assets is used by a lot of Fireblocks customers to really sort of secure, not only the communication of, deposit addresses, but to create automation for settlement flows. Under the Fireblocks network tab, what I'm showing you here is my profile on the Fireblocks network. Currently, I have 2 profiles. 1 is my employee test, my basic sort of profile here. I can see my profile settings that I am discoverable so people can search me on the Fireblocks network. I've got a network ID which I can share with people. So if I want to basically give them a handle that they can say, please connect with me on Fireblocks, they can take that unique identifier to connect. And then I've also got a setting for deposit routing. So this basically says, if I was to receive any deposits from an end customer, where would I want those deposits to go? I can set a default for this so that, by default, all of my funds will go into my omnibus role role. Now, as part of this, I may want to connect to counterparties on the network. So currently, I've got one connection to Valero's affair. If I wanted to add additional connections, I'm able to click on add connection and I'm able to search for counterparties on my network. For an example, I'm going to select QCP Capital. I'm able to have a look and say connect with QCP Capital. I can see their ID here. And then I can choose to use my default routing for any deposit from QCP. Or maybe my relationship with QCP is slightly different and I've got a different vault that I'd want this to be sent to. So for example, I may have a client identify very specific for QCP and then I can put a QCP connection and add that connection here. Now importantly, for these operations such as adding a firebox network connection, white listing of addresses, you will be able to set a quorum of administrators to approve the appropriate connections or the additions to your secure network of connectivity with Fireblocks. As I can see here, I've now got a connection request, QCP Capital, pending admin approval. Once that admin approval has been obtained, that message will then get sent to QCP Capital for their administrators to then approve the connection on their side. Once completed, I will be able to see a counterparty within my Fireblocks network. Once I have a counterparty with somebody on the Fireblocks network, it's now very easy for me to create transactions. So I can create very quickly a transfer of assets through to from my treasury vault to Filio. Notice here that I'm not dealing with any deposit addresses. These are part of the Fireblocks network where we're using unique identifiers for the destinations. This way, there's no mix up on where those funds are actually being sent to. You know and you get confidence that you are sending all of those funds to the destination that you have already arranged. I can set up the net amount of transaction value, send a note, and then send those transactions on the way. For a more structured way of sending funds to your OTC counterparts on the Fireblocks network, Fireblocks has built the smart transfers feature. This allows you to create a instruction to your counterpart, which is effectively a settlement ticket. So creating a ticket, I can select either a one way or a two way smart transfer, which is really an instruction on I would like to be paid, or we're gonna set up a two way payment between each other, for different assets. So under this particular profile here, I'm gonna select my counterparty. I'm going to select my counterparty Valeria. I'm going to choose what asset I'm going to be sending to Valeria. So I'm going to send her 0.05 BTC and potentially 1 eighth. Oops. 1 eighth test 5. And then an exchange, I'm expecting to receive from Valeria maybe 4,000 XRP. I can put an expiration on this settlement ticket, say that this is valid for maybe 6 hours and any sort of notes. So this is often used in sort of like OTC trading where counterparties have already already had a negotiation on what they're going to settle on, but this then puts a structure around the on chain transaction. So I can then put in a particular reference number, message to the counterpart, review the ticket, double check my values here, and then validate and send. Now, of course, these operations can be done from the Fireblocks console, but they can also be done through the Fireblocks APIs. Okay. So that pretty much rounds out all of the features that I wanted to share today of the Fireblocks platform. I would like to now open it up to any q and a that, the attendees may have, on anything that's been shown today or if there's any other remaining questions about the Fireblocks platform you'd like to know. Chrissy. Hi, Ben. Jumping in for Arty here. I'll go ahead and ask some of the q and a that's come in. And we've gotten a number of questions, and so I'll just start from what came in first and and go in chronological order. So the first question was, can we say in the context of the banking use case, a vault represents a specific customer? Yes. Yep. That's a that's a really good question. So, yes, quite often what we, our customers are doing is we they're using vault accounts as the segregation between each customers. So for example, I've got a list of clients here. These would be, unique identifiers associated with the bank's own customer records. And within each of these, accounts, as we call them segregated accounts, that customer would then have all of their assets segregated away from other clients or other customers. Great. Moving on to the next question. This is a 7 part question. So in the interest of time, I'm going to summarize them and paraphrase the questions. And, Soumya, who asked the question, happy to follow-up afterwards with more details. But the first part is around integrations into CRMs, specifically Salesforce. So let's say you have, a wealth management company as a client or a high net worth individual. Can you see the Fireblocks wallets of those customers in integrated in your CRM? That's the first part. Mhmm. So the short answer is yes. So we've got the, Fireblocks, developer environment. So as I sort of mentioned, every single, feature that you see within the Fireblocks environment, is able to be accessed via APIs as well. So we have a series of APIs and SDKs that could allow you to integrate into Salesforce and pull any appropriate data associated with your Firebox environment. So, in the case of you may be using a Firebox Vault as the identifier from Salesforce. So the unique ID you are you you UID from Salesforce as the vault identifier in Firebox and you are able to use the APIs to match those and pull information into, your your Salesforce pipeline. Great. And now the second part of this question is around CBDC support. Do we support CBDCs? Can we help with minting of, creating new, crypto asset backed by CBDCs or gold, stable coins in other words? And then is it possible to connect to Enbridge or the bank the BRICS countries payment systems with CBDCs? Sure. So so talking about CBDCs or centralized bank digital currencies, we are working with, numerous territories around CBDCs and their tokenization and across different types of chains. Quite often, the use case that we're seeing from a, I guess, a financial markets retail perspective is using CBDCs to back bank owned stablecoins or regionally based stablecoins. The 5 blocks tokenization engine is suitable for this. We also have a, strategy support or business support around the tokenization as well, where we have a team of engineers that help to build and extend on our ERC 20, protocols, to allow for different use cases as well. Very, very specific to stable coins. Now, going further backwards in the chain where, you know, you've got CBDCs relating to Fiat markets and, sort of the the governance or or, you know, country governance around those assets. Maybe that's worth a different conversation. I'd I wouldn't I wouldn't post myself to be the expert on this, so I would, love to follow on that conversation after the call. Great. Our next question is about fiat integrations. For fiat accounts, can we link to an IBAN account? Is it possible to open a channel between a specific bank and Fireblocks to swap fiat to crypto or crypto to fiat? Another very good question. So Fireblocks has a product called fiat network link. So within the fiat platform, we have, different banks who have integrated here. So I've only got one which is shown here. So BCB blank have integrated with the Fireblocks APIs to provide their services. Now the services that they provide as part of this are defined by the bank itself. So the first step is the institution would have needed to register and integrate with the Fireblocks open API stack. Once that's completed, they then have a menu of different features that they can offer their clients as well. Say for example, if this was a bank and they also have a stable coin, you may be able to, within the Fireblocks console, convert your fiat balances into a stable through instructions through that API. So it's really down to the bank that you're working with and whether or not they've integrated with Fireblocks, Fairlink. Great. The next question is, a follow-up around our integrations with Chainalysis and Nota Bene. Can you tell us how Chainalysis and Nota Bene are integrated to Fireblocks? Is it automatic, or do we need a specific call via API? Really good question as well. So from setting up your compliance integration, there is actually a wizard to get things started within the Fireblocks console. So first of all, is you would need to have, a license with, your Chainalysis or. Chainalysis is a very simple integration, like, effectively, you're able to configure your Chainalysis license with your Fireblocks workspace. The setup of this is done very, very quickly so you can get running within a day and have your base sort of policy set up. The Notor Bene integration is a little bit more of a step in the way that, there is probably a 70% of the integration is done already between, NotToBeNA and Fireblocks. The remaining 30% is where you would deploy your own NotToBeN8 service within your organization in order to integrate with the, your Fireblocks account. And the reason why this additional integration step is undertaken is because the NotToBeN8 service does deal with KYC data. We as a, as a asset management platform do not want to deal with any PII. So this is where the PII would be stored within NotToBene and cryptographically secured within your own premise. Great. Our next question is just a clarification of the the network. The Fireblocks network, is it like a private chain in Fireblocks just like in base for Coinbase? So the Fireblocks network is what we would say is a web 2 construct which sits across the web 3 environment. So the Firefox network is effectively a service that runs between, as part of, I guess, the the Firefox SaaS layer that has, a series of secured address constructs associated with workspaces and entities. Now, that is effectively a, a construct where you can advertise your profile within that network, and then people can subscribe and connect to you. Now this is not an on chain network whatsoever, but this Firefox network purely allows for the secure exchange of information between other Fireblocks counterparties on the network. And what I mean by secure is that we're using zero trust architecture. We're securing all, all of the components of the Fireblocks network, I. E. Addresses with Intel SGX, so cryptographically secure enclaves. And then all network connectivity is, SSL, TLS 1.2, TLS 1.3 secured. So effectively, the what we're solving for is where, institutions or individuals are tricked into, adding deposit addresses which are not part of the organization. So avoiding those spoofing attacks. So basically, what you're dealing with is a series of communications of network addresses where nobody can go and intercept and change those. So no man in the middle attacks, no spoofing. It creates a protected trusted repository of deposit addresses. Great. Hope that answers your question. Our next thanks for the that detailed response. The next one is around DeFi and staking applications. For staking or any DeFi application, can we easily integrate a homemade smart contract to be used via Fireblocks? Yes. Most definitely. So, the the one click staking capability that we've demoed today is around the really sort of easily accessible, staking providers. So this is where we've got a, predefined staking methodology with Killam and Figment. However, if you wanted to use Firebox wallets to create staking activities against other venues such as, you know, you may wanna do self-service staking with 1 of your wallets. Say, for example, if if I've got 32 ETH and I wanna stake it directly to a valid end, we do have the facility for you to do that. So we've got, development capabilities. So we've got some SDKs for different, different protocols such as Polkadot, is is one of them. So you do have the capability of choosing your own adventure, like going down the route where you want to develop your own staking strategy. However, we found that having the click through staking is for the, I guess, the less technical customers to be able to provide a yield service is, also a great feature. Great. The the next question is a bit of a a a broad question. Can you tell us something about key management? How is Fireblocks handling that? Yeah. It's, it's a very important question. So Fireblocks uses multi party computation as part of the key management philosophy. We we have, well, MPC keys, and you can also choose to have Fireblocks KeyLink for HSM, key management as well. The latter is more of a sort of enterprise regulatory use case often used by banks and government institutions that have a preference for HSMs. But for the majority of our customers, they're using multi party computation. And how multi party computation works with Fireblocks is that, there's 2 different deployment models. Most companies will be using a SaaS deployment model where you will generate your MPC key share yourself. So the initiation of Fireblocks Workspace, you'll go through a process of generating, your first MPC key share within a cryptographic enclave that you own, run, and manage yourself. Now that MPC key share will always remain with you, and it would never go to Fireblocks. Once that MPC key share is created, Fireblocks will then create 2 other MPC key shares on distributed architecture and the cloud. So using Microsoft Azure and Intel SGX in 2 different data centers, we would then, in isolated components, create very, very unique key shares based on, cryptographically generated secrets from hardware. Now those 3 key shares are all generated independently of each other. And importantly, they never come together. And then by virtue of the MPC algorithm, any transaction that you create within your Fireblocks workspace will first then need to be signed by your MPC key share and will then subsequently be signed by the other MPC key shares in sequence. As a result of that computation, you will then end up with a completed signed hash, which Fireblocks will then be able to broadcast on the network on your behalf. Great. We got a question about pricing, and I shared the link to our pricing page. So I'm going to skip over that question, but you can find that in the q and a section. Our next question is, can Fireblocks, connect to any web 3 project? Yes. Another very good question. So part of our web 3 access is allowing you to use wallet connect, to connect through web three access. We also have a MetaMask plug in, which I can't actually demo at the moment because, it doesn't set up with this demo environment. But, I'm able to, connect using a Fireblocks extension to, other d apps. So say, for example, I was to go to PancakeSwap, I'd be able to click on connect wallet. I would either be able to, use my Fireblocks application to scan the QR code or use the Fireblocks extension to link through and then connect my wallet. It happens in very similar way that you'll connect your MetaMask account to a, a d app. Once that connection, that connection creation request is is found, You may have a policy that requires your administrators to approve this. But then once that is approved, you will then see what I've got here is my PancakeSwap web 3 connectivity. My vault account treasury for Ethereum, Chestnut, Goliri is now connected to PancakeSwap. And then I can use that connection until I choose to disconnect it. Great. I'm going to combine 2 questions because I think they're related. First is, how do we add a new EVM blockchain? And then if we're working on a different chain that isn't supported by Fireblocks as of now, what would be the procedure for that change test nut and mainnet onboarded into Fireblocks? Very, very good question. So, Fireblocks today, we we support over 70 public blockchains, and we also support support a number of private blockchains, like Hyperledger Besu, for example. Now, our Firefox team have done, research on a number of different private chains. So zkEBNs, Besus, Quorum Nodes, etcetera. We do have a process in order to onboard the chain. And we, generally, it is a, part of a sales consultative process where we will look at your project size, your timelines. And quite often, we're able to actually add those chains in within a few weeks. As far as, like, the ease of then using those chains within Fireblocks, we've tried to make things as easy as possible for the, management of assets. So for example, if I was to create a new vault account and say, you know, new chain asset account and, for example, I have created added a new chain within the environment, I would then be able to add assets quite quickly. I'm just going to share you with you an example. If I want to create a wallet for a new asset type, say this is h k d r. Oopsie daisy. I've already got this asset listed. But I can put in a contract address and list an asset. So I can choose the type of chain alternative Guerrilla, for example, put in the contract address, click on continue. It will then go out and find the particular asset, which I've now added on that unique EBM. So the first thing is being able to add a private EBM, and the second thing is to be able to very quickly add the contracts of the associated assets with that chain as well. Great. The next question following up on the fiat conversation. Looking at stablecoins to fiat and fiat to stablecoins, are we able to link to an off ramp like Circle? Indeed. So we do have, a integration with Circle as well. So as part of the Fireblocks payments, capability, we introduced different functionalities where, for example, the exchange of fear to stablecoins is possible with the Fireblocks API. So it's really just down to the, integration of the provider with our open API stack, whether or not they're gonna provide those, exchange services directly within the Fireblocks, console. So, I might have the opportunity to share with you I'll just have to make sure I'm looking at the right workspace. But we do have a capability as far as Fireblocks is concerned, and I do believe that Circle are currently offering some functionality similar to that where funds can be, converted. But it's definitely possible with the Firefox platform. I will probably just skip trying to demo this just in case it's not, available right now. Our next question is a fall is a is another follow-up on the fiat conversation. So, if the banking institution doesn't allow a connection to Fireblocks, a workaround would be to transfer via API the funds to a Kraken late account in Fireblocks, for example, and buy it directly in Kraken. But in this case, it's only managed by Kraken APIs. Or once the funds are available in Kraken, can we buy it via fake Fireblocks API? So we don't currently have, this is a good question. So as part of our, as part of our Fireblocks network, network link for exchanges, we have the APIs available to expose trading peers to customers. We are currently working through this with a number of exchanges, and some exchanges have enabled this functionality. Now this would be something we would have to discuss with the the person who's asking this a little bit further, because this now falls into the Fireman's payments engine product. So the Fireman's Fireblocks payments engine is a workflow management where you may want to create a cross border transaction where you're moving, for example, United States dollars into Mexican peso, and you're using different avenues to then convert things to, you know, funds to USDC, etcetera. So there are a few different ways that we're working on this, and we do have different exchanges for different rails. So, long story short, we'd love to hear from you and we'd love to, work through what you're trying to achieve because we may have built it already. And we have a a a couple more questions, but I know we're running really low on time. I'm gonna ask this last question, and then, again, this is recorded. We'll send it via email afterwards and, happy to answer any additional questions so you can just reply to the email that you get. But this last question, let's end on this one. If we create different wallets for our clients on Fireblocks, I want to trust that they won't transfer funds without permission. If we use tap to manage withdrawals from client wallets, ensuring that any withdrawals must be approved by the client. How can we make the client trust that we won't remove this TAP rule? Yeah. So, so this is around the TAP rule management and governance around that. So I guess there's there's a few different ways that, you may be providing your services to the customer. So in the case of if you're a custody operator and you're providing custody services to a very specific, smaller number of customers, you may have them as part of your quorum for tap management. So you may sort of say that they actually need to approve the change for that tap, or you may have a separate workspace for that customer that they are actually part of the administrative quorum. So you can actually in the case here, you could actually potentially have a workspace that is dedicated for that particular customer that gives them the ability to have some sort of vote in that quorum to control that tap. Another part of this is transaction policy is that when linking the transaction policy with your APIs, you can actually provide a what is effectively a versioning proof to show that the policy hasn't changed or there was no unauthorized changes within a particular time. Obviously, this this particular use case could be quite nuanced, and I may have not understood exactly what the client would be asking for. But there are many different ways that you could coordinate this, and I think, we would have a solution for you to to engineer to satisfy the client's requirements. Great. I think that's coming up just on time. I'm sorry we didn't get to every single question. Again, we'll be sending a follow-up with the recording of the session. And any questions, feel free to to ask, just reply with email. Thank you, Ben, for presenting this.