 Welcome everybody, welcome to our second Firefly Community Call. For these first several calls, we're going through a some sort of technical topic in each call. Today's theme is tokens and I'll introduce Andrew here in a second. And we'll split up the time between a technical topic presented by one of the project maintainers, and also a time of open discussion and or q amp a. Today's topic, like I said is tokens and Andrew Richardson will be presenting on that and this is a proposed plan for how tokens will work in Firefly. Andrew will take us through that. I don't think so. Last time we split the call 5050 between you know 30 minutes of presentation 30 minutes of discussion. I don't know that we'll need that full time for the presentation but if you can please hold questions until after Andrew is done and then I will open it up for discussion either on the tokens topic or on anything that folks would like to discuss about Firefly. This is a public call, anyone is welcome to join. It is recorded and the recording will be posted online so it is public and open public record just to let people know. But thank you all for joining. And with no further ado, I will turn it over to Andrew. Andrew, we cannot hear you at the moment but you're we do see your screen. All right. Can you hear me now. That's better. Thanks. All right. All right. Thank you Nico for that introduction. As he said, we are talking a little bit about tokens and trades. And this is a little bit unlike the last architecture series which was more of a presentation of how the current Firefly code works this is definitely a presentation about how we would like it to work. And one of the biggest things that comes up when we start talking about Firefly or really anything blockchain. This juncture is where do tokens fit in. So we thought it would be good to take one of these early architecture calls and talk about how we see tokens fitting in. But this is definitely a call to the community to say what we're thinking and to get some feedback as this actually gets fleshed out and becomes code in the open source project. So, just to start off, when we start talking about tokens, we really see them falling into two buckets. The first thing that's interesting and that would be pretty common to talk about for any kind of token exchange on blockchain is when we're exchanging tokens for other tokens. This might be exchanging a fungible currency type token for an NFT or the non fungible type of token, or it could be any kind of combination of you know fungible fungible or net ease. But this is kind of the sort of classic blockchain problem right and it's very well defined, and you're going to want it to be atomic you're going to want to leverage the full power of the blockchain to make sure that two decentralized tokens exchange and ensure that they can both fulfill their end of the trade without necessarily fully trusting each other right this, this is an atomic swap there's well proven ways to do this such as hatch time locked contracts. So this is kind of an obvious thing that any kind of blockchain system like fireflies aiming to be needs to support this sort of token for token exchange right. Is a bucket that maybe is not as commonly discussed, but that we have actually seen is very commonly useful in the sort of enterprise multi party systems that we're trying to facilitate. And this is exchanging on chain tokens for some sort of off chain thing, whether that's a bit of data or a physical item in the real world. And this is actually not really possible to make it atomic. It's going to be a non atomic transaction where one piece happens before the other piece right either the on chain token gets sent first or the off chain data gets sent first. And you could choose to do it in either order to kind of give some protection to one party. It's never going to be totally atomic the way an on chain transaction would be. And this can kind of spawn a whole discussion in itself so I don't want to get too deep into it now, but happy to circle back on it at the end as one of the kind of further discussion topics. Because there's a lot of ways you can talk about how do we push this bucket into the left, you know, can we put more things on chain, etc, etc. So for now I'm just going to kind of assert that there is a bucket on the right and that this is a useful thing to enterprises and that some people do want to exchange on chain for off chain, and that non atomic is good enough. That if, if something did kind of fail to be fulfilled the way it should be, you always have the on chain record of what party a did what party B did, and you can fall back to having third parties get involved if you need to sort things out after the fact. And that's often good enough for an enterprise flow. So this is actually something we do want to support on the right as well. And I'm going to talk a little bit about how we support both of these are how we would see these fitting into the architecture of firefly, but just wanted to kind of intro that there are two distinct buckets and we want to make sure we support both. So diving into what we would see this looking like in firefly each of these boxes with a bold title is a logical construct in firefly, you know that would be part of the database and part of these logical data model. So the main item is a token pool on a token pool. Again, we're trying to keep everything agnostic to the blockchain and to the underlying contract on that blockchain. I've shown that this could be mapped in the case of Ethereum which is sort of our first proof of concept that we've been working on. It could be mapped to an ERC 1155, which is sort of you know the next generation token contract construct that it allows fungible and non fungible in different combinations. It could be mapped to a lot of different contracts and ERC 20s and ERC 721s. But each a token pool is basically going to be a set of tokens that are either fungible or non fungible, we propose that it's a Boolean either this pool is fungible or non fungible. It's tied to a specific contract somewhere on a blockchain and that the nature of that contract reference is going to depend on exactly what chain is underlying it. And then it has a generated pool ID right and that's sort of your core construct tied to that we have token accounts so every identity that can participate in these token exchanges is going to be mapped to a token account. They're per pool. So a pool may have token accounts for all the different parties that may be involved in transactions on that pool. A token account is mapped directly to an on chain identity, which is again, the exact format of that is going to depend on which chain you're using, maybe an Ethereum address or some other identifier. You're going to have some sort of roles right some people may be allowed to mint some people may be allowed to operate transactions on behalf of another party. So, some notion of roles, and then, depending on whether the given pool is a fungible pool or a set of non fungible assets. We either have each account container balance just telling how many of the fungible tokens they have out of this pool in their ownership, or a sort of mapping of if it's a non fungible asset class, which of the non fungible tokens are currently owned by this account. If you make the eyes associated with this you would have a post to create a new token pool, you would have gets to list the token pool and the tokens within a pool, and gets also to get the accounts tied to a particular. Then moving on and building kind of on this, the, the simplest thing you can do is a simple one way transfer just transfer a balance of one token from one token account to a different token account. We're going to result in some things at the firefly layer some of our, you know, database constructs, but it's also going to be directly mapped to on chain transactions. So we have the notion of a token transfer that is going to contain a reference to a from account reference to account, depending on whether you're transferring a amount of fungible tokens that may be an amount, or if it's non fungible tokens may be a listing of which tokens you're transferring. And then like with many things in the firefly architecture there's a sort of free form data item here. And I put a note at the bottom of the page here, the data is opaque to fire for core and this is a common thread that we've built into a lot of what we're proposing in firefly, and basically saying the application can decide what goes there. One suggestion would be that if this transfer is in exchange for some off chain data, right like I mentioned this bucket where you may be transferring tokens in order to receive some off chain data. Maybe this is a reference to that that right it could be a reference to the data ID within firefly, or some other identifier. But it's basically up to the application to decide how that data is used in reference. And then you have a token plugin in firefly. Similar to the other plugins that we talked about last week the base blockchain plugin and some others have a token plugin that's going to be specific to the contract being used you know so maybe there's a plugin that talks to an Ethereum ERC 1155 contract, and it knows how to create token pools within that contract it knows how to do transfers within that contract. So the token plugin is also going to decide what happens to that data that's attached to the transfer. Again ERC 1155 is a really nice fit for this because it kind of already has a built in data item that you can pin next to the actual transfer of the tokens themselves so that's recorded together. It's in the RC 20 and 721 and anything else to kind of provide that same functionality but it's up to whatever token plugins get added by the maintainers by the community to determine you know how this blockchain transfer gets pinned alongside the data that we have the record of what the transfer was for then going to kind of what the flow would look like. This is that flow that I was talking about right the on chain for off chain flow which we would argue is a very valuable and common thing for enterprises to want to need. On the left is kind of a sample Jason blog. Again, this is a proposal and this is not a thing that exists in Firefly yet so this is more of a sketch rather than a actual spec. You start member one is saying that they want to send a payment for some sort of data off chain, they make a post to this transfer API. That post includes the from the to the token pool that they're transferring within, depending on whether they're fungible and non fungible tokens they may pass an amount of tokens or a specific set of tokens that they are putting as input and that they're going to transfer to the blockchain. And then this data blog where in here I've put, you know, data one requested it's something that says this transfer is in relation to this piece of data, and I'm expecting to receive this piece of data and return to these tokens. That goes through the blockchain contract, it actually does the transfer so that these are transferred from the identity from river one to the identity from number two, and then the firefly note on the far side gets the event, and then member two would be expected to respond with a private message. All the constructs we talked about last time in the first architecture series. If you missed all that Peter did a great job going into a lot of detail about what public and private messages look like in Firefly. So this is just coming back, sending the private message pinning the proof on chain to say that this transfer was fulfilled and then delivering the private data off chain, and then member one can then retrieve that data. I included a slide here that's more of a prerequisite. Again, just kind of referencing back to last week. Assuming that member one is requesting a piece of data you would have had to advertise the data was there. I'm not going to dive too much into this, we can definitely come back to talk about it. This is kind of the prerequisite assuming member two put some data into the system. They advertise to member one that data was available. That's kind of how we decided that they wanted to send a transfer of tokens. Moving on to the next thing and getting a little bit more. If you call back to my original slide, a little bit more into the left bucket talking about supporting the world of atomic slots, atomic swaps. And the more advanced kind of block chain secure transactions. We have, in addition to the notion of tokens, we're proposing a first class object called a trade. Now a trade is something that's very plug and dependent in this case. I don't want to box it in too much and say that a firefly, you know, is built on hashtag lock contractor any other specific blockchain or protocol or system. It's really just saying that a trade is a thing that happens between two parties has a number of steps, and it's going to ultimately result in some transfer of tokens. Right. So it's a very, very generic construct as we've laid it out here. You can see that all I've put in the trade object itself is a generated ID, a status to say, you know, is it initiated is it in progress is it completed, and then this opaque data blog. A trade plug in could put lots of different things in that data block. If it is an HTLC, they're going to put a secret and a secret hash, you know, and those will get shared at different points of the transaction so one member may have the secret at one point they may not have it immediately on the other side, but as the trade moves along, you know, through these kind of well defined protocols, this data blog will be built up with the data about the trade. So the steps again, not a lot here they have a link, there's going to be a mini to one relation to a trade. They have a link to that trade ID. They have a initiating account that points to a token account, and then they have some data that's attached to them. So in the case of something like an HTLC that they'll be an initiator they'll be a participate from the other side, they'll be, you know, the secret exchange to redeem it on one side to redeem it on the other side. They'll be attached to a trade step, but it's generic and you can map it to any other kind of two party in party kind of atomic trade or anything else. The APIs that are attached to this would be of course, creating a trade, getting the details on a trade, creating a step getting the details on step. And this is kind of the more involved flow chart for what this would look like. And I'm specifically showing here an atomic swap using ERC 1155 as the backing. Remember one would create the trade and initiate the first step of that trade, which would trigger the underlying trade plugin to actually deposit some set of tokens into the contract. And these are going to be accompanied by a hash lock a time lock whatever your mechanism is there. That's going to result in an event coming out of the blockchain listener to Firefly to member two is notified that a trade was created that they are party to. And then initiate the next step of the trade. That would be of course, in this case, if we're looking at this atomic swap, depositing their side of the transaction into the contract that generates an event back to member one. And everything is flowing here through the trade plugin for the specific type of swap. But at this stage, member one would be able to claim the tokens redeem them actually receive them that implicitly shares the secret to member two variable to claim their side of the transaction. So you can kind of see here, this is almost entirely on chain. There are some off chain data pieces that follow the flow that we talked about last week, but this plugin is very, very closely tied to the actual operation of the smart contract. So that is everything for kind of the high level overview a bit of a whirlwind.