PORTAL DEVELOPERS FIRESIDE CHAT

DECEMBER 14th
Twitter Spaces Recording Unavailable

Participants

Terry Philipson (Portal Host)
Eric Martindale (Portal Co-Founder & CEO)
Kulpreet Singh (Portal Co-Host)
Casey Bowman (Portal DEV)
Anand Suresh (Portal DEV)
Pablo Artee (Portal Designer)
Manoj Duggirala (Portal Co-Founder)
Alexey Melnichenko (Portal Engineer)

Terry Philipson (Portal Host)

Excellent, We can hear you.

• Pablo Artee (Portal Designer)

Hello. What’s up?

• Terry Philipson (Portal Host)

Hey dude, we can hear you.

All right. So if you’re just tuning in, we are getting ready. This is our little green room before we start. It’ll be just a couple more minutes.

• Pablo Artee (Portal Designer)

Would be really cool if we could have some kind of waiting music or elevator kind of music as a lounge thing.

• Kulpreet Singh (Portal Co-Host)

Are you missing the slack music?

• Pablo Artee (Portal Designer)

Yes, it wasn’t that bad if you didn’t care that it was the same song like a lot of times. Maybe it sounds kind of weird but it fulfilled its purpose, I guess.

• Terry Philipson (Portal Host)

I’ve heard some very interesting elevator music remixes.

• Kulpreet Singh (Portal Co-Host)

Nice.

• Terry Philipson (Portal Host)

Now, before we get started I’m sure that everyone here has listened to some of our earlier fireside chats full of information and some very fairly lengthy introductions.

So we’re gonna keep the interest quick today so lets get started!

With us on this chat, we’ve got the legendary programmer Kulpreet Singh. He has a PhD in distributed systems from University of Illinois Urbana-Champaign. He will be our host.

We’ve also got Casey Bowman, senior Bitcoin engineer with engineering degrees from Princeton & Stanford.

Can’t forget Anand Suresh, another senior engineer here from portal taking time off from coding. He did his masters in computer science from Carnegie Mellon University. Later worked at Definity Labs.

And Pablo Artee, our lead designer. He was head of design at Optic Power.

Now if you are all ready then lets get started.

• Kulpreet Singh (Portal Co-Host)

Thanks a lot for that those intros, Ron.

So today we’re just going to dive in straight into the questions.

Like last time we had a bit more time to kind of talk to each other and figure out where we were. Today we’re going to start talking to Anand first.

Hey, Anand you around?

• Anand Suresh (Portal DEV)

Yes, I’m here and I should apologize in advance.

I’m a little bit under the weather, so if I have a coughing fit, I may just mute.

• Kulpreet Singh (Portal Co-Host)

OK, cool. Last time we talked about the Portal OS and you gave us a very quick overview of what and how the packets were being packaged and shipped to build the Portal OS.

Now this time we’re curious like what are the various components and services and maybe a set of daemons that kind of constitute the Portal OS.

Like what are the services running inside it?

If you could talk a bit more about that, that will help us a lot.

• Anand Suresh (Portal DEV)

Sure. Portal was essentially a a complete system image of what is needed to run the entire point software stack. So that includes the operating system, all drivers needed, any services and daemons that are running, everything sort of packaged into a single unit and as I mentioned last time, we’re using NixOS as our base operating system to help us build all of these systems which gives us some very good security guarantees in terms of being able to reproduce builds consistently.

So in terms of the the actual components that go into Portal right now what we have right now is we have a bitcoin daemon, we have lightning daemon, we have the ethereum daemon for L1 and then there is the what you call the “Portal Coordinator” or the Portal Server, that’s where all the business logic essentially sits and that’s the thing that ties in all these various third party networks and sort of helps them interoperate.

The current challenge is to get all of these working in a single environment but in production this may actually change. We may choose to not do everything packaged in there. We’d likely use a smaller set for example there may be some people who already run bitcoin full nodes and they don’t really see the value in having another Bitcoin full node running for them.

So there would be the means to sort of swap out the internal daemon with an external service or if there are other folks that wanna run something on like moderately hardware who don’t really want to spend all the money needed to run like a full enterprise level for example so the option to still have the option of moving out and and swapping these internal components out with with third party components. But at the core of it is still the portal software, the portal coordinator that sort of manages.

• Kulpreet Singh (Portal Co-Host)

Hmm.

• Anand Suresh (Portal DEV)

As of now, this is just a single daemon but as we start to make progress we will likely split these out into sort of a collection of daemons that will sort of interoperate each one providing sort of one particular service and dealing with its own internal state by itself.

• Kulpreet Singh (Portal Co-Host)

Yes, that’s fascinating.

I’m really excited about the idea that if someone has their own Bitcoin node, they can just point it towards it. So two questions are coming to my head.

I don’t know if I should follow up too much but of course the first question was; “how do you sync your Ethereum node and and how does that work”?

But let’s leave that aside. Let’s talk about like; “what are the minimum requirements that might be required to run all these services”?

Will it be something like a Raspberry pie, a beefy laptop, or even something more powerful?

• Anand Suresh (Portal DEV)

So we’re not really tying ourselves to one architecture so that’s an excellent question. By the way, there’s there’s a variety of people that will end up using this so that some of them will likely come from enterprise sections of the community where they’re looking at this from a perspective of an investment in a business. So they would like to get into the business of they basically use portal as a means to run an entire operation on top of it.

They would likely run their own Ethereum full nodes, their own Bitcoin full nodes, their own lightning nodes and all that. So in that case, yes, you would end up using something at the high end of of the service spectrum where you’re looking at something really beefy. On the on the other side of it is the the average hobbyist who just wants to get into this and sort of start playing around with it. A Raspberry Pi is not good enough for running it.

You may be able to get away with maybe a Bitcoin full node but Ethereum it’s unlikely we’ll ever run on Raspberry Pi. So in that case, like I said, it is feasible that the user may then swap out the Ethereum component for the Raspberry Pi with an inferior node, so that way, all the rest of the communication will still happen on the Pi itself. So you still have your Bitcoin running there with the portal software but all the Ethereum side of communication will likely happen over in FURA and that’s still fine. So we are not sort of tying ourselves to one particular architecture or one particular platform. We want to target as many platforms out there as possible.

• Kulpreet Singh (Portal Co-Host)

Yes, that makes a lot of sense. I think that that flexibility of pointing to various events that you might be in other places really opens up a lot of possibilities. So this is exciting. So I mean, another question is like, what about backups? Like if you’re running your node or are you thinking about, have you started to think about how you might back up the state so that if if bad things happen, you can reboot from where you are or restart from where you are?

• Anand Suresh (Portal DEV)

That is a an excellent question. As of now, we haven’t really delved too deep into that solution but we’re likely looking at options within not sort of doing something ourselves but sort-of offloading that to other system components like the file system. Like if you end up using something like ZFS, you can automatically have it take snapshots of the drive every minute, every 5 minutes, every 10 minutes and some regular cadence, and then ship that backup to a remote site.

The beauty of using something like that like ZFS is you get a lot of advantages that that are traditionally that you’d have to build on your own. You just get that out-of-the-box for example, you get runtime compression of of your data, you get the option to do constant time snapshots encrypted or address encryption of data. So all these features which are really good from security standpoint already come on little bit something like DFS. So we might end up looking at something like that.

As a means to do backups. But like I said, we haven’t really delved too deep into that part just yet.

• Kulpreet Singh (Portal Co-Host)

Yes, I think I might have jumped the gun on that question too.

I was just curious if you had thought about that but in fact there are more basic questions like; “what is the process like when I get a device and say I want to run a portal node like from the cold hardware to a full running node to start earning fees right from a DevOps perspective”, what would the process look like?

• Anand Suresh (Portal DEV)

So let me sort of talk you through that step. I’m just going to consider the example but technically this could be any server.

Essentially the way we’re looking at it is you would go to a website or a web page where you will have access to the the build assets for the portal for the portal. So think of it as the same way that you would go to the the download space for Ubuntu and then choose from one of the variations over there which edition you want.

In this case there may not be an addition per se but it would be more of a Fill-in-a-form-sort-of-configure-your-node, right. So you can basically when when you open the page it’ll essentially be a web form that’s populated with a bunch of defaults and you can go in and change those defaults.

If you wanted to run your own node, you plug in your URL in there or if you already have like a Bitcoin node running somewhere you plug that value into you override those defaults and at the end of it you can use an ISO image just for your machine. So you can basically go all the way down to selecting format. So it could be an ISO, it could be a netboot image, it could be an Amazon disk image.

So if you want to run on AWS it could be a Raspberry Pi SD card image if you so choose to run this on a Raspberry pie.

Once that build process completes it would basically download that file to your machine which you can then burn onto your local media, whatever that is, an SD card, CD, or a USB stick and then you just take that plug it into your server and boot that thing from the USB drive and you’re off essentially once the system boots. It this is mostly like a we’re trying to sort of get this work working as a live image kind of like how you would run Ubuntu as a live image where you just plug in this thing and it gives you a fully booted ubuntu machine that’s running off the USB stick

• Kulpreet Singh (Portal Co-Host)

Hmm.

• Anand Suresh (Portal DEV)

Then you just take that, plug it into your server, and boot that thing from the USB drive and you’re off, essentially, once the system boots it. This is mostly like a we’re trying to sort of get this work working as a live a live image. Kind of like how you would run Ubuntu as a live image, where you just plug in this thing and it gives you a fully booted Ubuntu machine that’s running off the USB stick.

So there’s a couple of reasons why we do this one from a security perspective. It’s actually really good because there’s nothing to install or what you get is just something that’s burned to a USB stick which you just plug that and away you go. Secondly, when it comes to upgrades, it makes things a lot easier, especially if you have to do like a mass upgrade. Then in that case all you would do is spin down the system, pull out the old USB, plug in the new USB, boot it back up, and you’re and there you go.

Anyone should be able to run this with. Even if it’s someone that doesn’t have a lot of experience being a system administrator, they should still be able to follow a few basic steps and be able to manage their Portal on their own.

• Kulpreet Singh (Portal Co-Host)

That makes a lot of sense. I’m just curious about like what happens in server farms if you want to setup & run a portal node on.

They cannot on the cloud but say anywhere co-located or hosted anywhere how would you do that where you don’t have access to the peripherals?

• Anand Suresh (Portal DEV)

What do you mean you don’t have actually peripherals over there?

• Kulpreet Singh (Portal Co-Host)

As it as in you don’t have an access to let you put a USB stick there.

• Anand Suresh (Portal DEV)

Oh I see, so in that case like depending on you know what that is like if you’re running on AWS for example you could download this image instead of an ISO you would download an AMI which is the Amazon Machine Image format.

• Kulpreet Singh (Portal Co-Host)

I see, OK.

• Anand Suresh (Portal DEV)

Which you can then just import into your AWS console and say “cool, that’s that’s my machine image, go book that thing” and there you go.

• Kulpreet Singh (Portal Co-Host)

Wow, that’s amazing. Thanks Anand for doing some of those questions. I’m sure we will coming back for more questions soon, thanks again.

• Anand Suresh (Portal DEV)

All right. Thanks.

• Kulpreet Singh (Portal Co-Host)

That’s super cool. That’s amazing.

Thanks, Anand for doing some of those questions here. I mean, I’m sure we’ll keep coming back to more questions soon.

Thanks again.

So next we jump on to Casey.

Hi, Casey, you around?

• Casey Bowman (Portal DEV)

Hi, yes.

• Kulpreet Singh (Portal Co-Host)

Hey Casey, good to talk to you again man.

OK, so the number one question always that I have for you, which I keep asking you and we keep kind of getting confused about it...

I mean atomic swaps per se are are a bit of a complicated piece, right?

• Casey Bowman (Portal DEV)

Yes.

• Kulpreet Singh (Portal Co-Host)

So can you tell us what is the magic sauce there?

If you don’t mind.

• Casey Bowman (Portal DEV)

OK so first of all for everyone I’ve been working on the lightning side & Alexey has been working on the Ethereum side. I’ve been focusing on the Lightning swap and then bridging the two for now. That turned out to be pretty simple. I was thinking about doing something initially as I was sort of exploring things where I was replicating kind of what happens on chain to something that would be done off chain with similar types of transactions.

I sort of sort of imagined some stuff which actually there’s some random ideas there that we may use for other things, as it turned out, as I went through just trying to simplify and simplify it.

I realized there was something called the HODL Invoice which is available.

I believe it was pure swap that initially did some stuff customizing some of their nodes and anyway eventually an L&D model incorporated the HODL invoice into their code and so that was available and what that allows for is that instead of having an invoice which is automatically paid once someone pays it from one from the one end, it stops at the last point where the payee can accept the payment or not. So everything has been done except for that last acceptance by the payee.

There’s a state there with regard to the invoice, which is the held state. So that’s why they call it a hold invoice or for fun, they call it the HODL invoice. So that allows you to have a very simple setup. We have this swap which on one side it’s an asymmetric thing where one user has a secret and the other doesn’t then there’s a hash of that secret that’s used for for both the HODL invoice on one side and what effectively is a regular invoice on the other side which automatically pays once the payment is made.

What happens is you’ve got it all set up so that there is this state and once you’re assured of that state, you basically can have the person who’s seeking the secret, pay the regular invoice, and once that’s paid & accepted. You can immediately have that secret revealed & the secret can be used by that user to do that final step on the HODL invoice to accept the payment.

All right, so this is how the Lightning swap works now. This is all sort of invoice based so the idea I think we want to have the Ethereum side also using that same approach with regard to invoices. This is something that basically is what we see this as sort of where he’s at with regard to Lightning & things in the future, I think in the future too there might be some opportunities with regard to Taproot & they’ll be using invoices as well.

So we’re really trying to keep it simple & use that sort of approach generally.

• Kulpreet Singh (Portal Co-Host)

OK. So essentially I could I get the swaps on the Lightning to Lightning right? So the question my head is how are you envisioning the Ethereum side to be as black box that it just works with your solution?

• Casey Bowman (Portal DEV)

Well here is where we you’ll need to direct those questions to Alexey because I’ve been focusing more on the lighting side.

I’ve been working on documentation to make sure that there’s a lot of good documentation on what I’ve done so far and and to foster communication too within our company. I'm using something called antora and I think there’s a there’s a great advantage to having a documentation system like this to be open to the public and also to be able to communicate with between members of our own company. It’s a nice documentation system and the diversions it’s sort of like documentation as code and really very attractive and that’s something I think that will be very positive.

• Kulpreet Singh (Portal Co-Host)

Is that something similar to what’s that called, literate programming?

Or are you talking that the documentation is sitting somewhere else outside the code?

• Casey Bowman (Portal DEV)

Well basically you put in a repository and you can have it spread out amongst multiple repositories and it will bring in the information and modularize it in such a way so you can have a full documentation where you need it and it’s versioned as well so you can go through the documents and really bring it all together as you need it from various repos.

It’s just a very nice system when you’re working with GitHub and it’s all using ASCII doc.

That’s something I’m currently enamored with and I just wanted to share.

• Kulpreet Singh (Portal Co-Host)

Now I just looked it up. That sounds very interesting. I might actually start using it to at least read up about it. Essentially you can self host it.

It’s another repo that just gets rendered as documentation.

• Casey Bowman (Portal DEV)

I’m just including it in our current repo the and so it can be a subtree of a repo and then it could be included as a sub tree and other basically all the different components are consist of a route to the repository plus a path where you start from so the starting document can be anywhere within the repo and there can be multiple starting paths for anyone anywhere within the repo and there can be multiple starting paths for any one repo. So you have different components of your documentation in one repository or multiple repositories and it’s just a really nice way of organizing it you know very sort of component oriented sort of way of doing documentation.

• Kulpreet Singh (Portal Co-Host)

Sounds lovely. I mean, if you if you already have it in the Portal repo, it would be great if you can drop the link on on the space below.

People might actually appreciate it if it’s ready for for public usage.

• Casey Bowman (Portal DEV)

Not yet. It’s in the mono repo right now.

• Kulpreet Singh (Portal Co-Host)

OK, that's understandable.

• Casey Bowman (Portal DEV)

It also includes a nice facility for bringing diagrams and all that sort of thing.

• Kulpreet Singh (Portal Co-Host)

I’m definitely going to be looking at it. Thanks for the tip.

So I mean this is interesting, right. Talking about knowledge sharing and learning from each other. I’ve heard that you are a big fan of of learning on in peer groups and the kind of trying to find your own little niche where you can learn a few more things. What is your. I mean we’re very curious about your thoughts on if there is a new engineer who wants the knowledge; is there any particular courses or universities; what’s your thoughts there?

• Casey Bowman (Portal DEV)

OK. So I have two main strands of thought on that.

I went to Stanford and I think that there’s some great nooks & crannies at Stanford where there’s good stuff being done. I was in a department which now is known as Management Science & Engineering where there is a lot of focus on microeconomics, game theory, probability, price theory in general.

I think it’s very important for people to understand this who are involved with Bitcoin and related issues. It’s really going to become more and more important to understand where prices come from, how they work, and just the basics of this sort of stuff and so I really highly encourage people who are going to be involved with software to to get a good understanding of of of the of microeconomics and game theory and that sort of thing. It’s not too highly politicized and where they’re really sticking to principles at least in my experience when I was there.

There are still places where people are sticking to things that are concrete & substantial but it’s hard because there’s a lot of politicization that’s happened in the universities. I think there’s also an important piece which I’ve discovered through actually going to the Stanford Bitcoin Club in 2018 and what they did was every week we came together and going through Bitcoin and cryptocurrency technology book, the one that’s published by Princeton.

Anyway, we were going through that and what what they did was every week we’d come together, each person would take responsibility for a section of a chapter, and then present it to the other members of the group just through that articulation of those ideas to one another, you learn much more profoundly. Peer-to-peer learning experience is going to be very powerful in the future.

I’ve used it to explore a lot of books on programming, Bitcoin, and Lightning while learning myself & I feel like there’s a really powerful way to go about doing things. One thing that’s amazing too is it’s sort of like, “if you build it, they will come”. What was that movie with Kevin Costner anyway?

You know I felt like I just announced in a meet up, “hey, we’re going to do this and start talking about it” then I mean I found that there’s really an amazing high caliber of people that come and again I’m used to you know I mean you know relatively high caliber at Stanford and Princeton so you know I just felt like it’s really neat to see how people would come together in in these peer-to-peer groups and and do some really challenging stuff.

I’m really am excited about my experience with reading groups and I think that’s a great way to learn. I attended a Bitcoin programming class with Jimmy Song before his book was published and some of the alums and I, we got together afterwards to kind of go through the material on our own as a reading group and we applied those same ideas that I’d seen in the Stanford Bitcoin Club to our going through the material. It just started you know we just went from we’ve done like I don’t know some 20–30 books or something total but I think it’s just a great way to to learn a new field, particularly one that’s very novel. There are some courses at Stanford right now. I know Don Barnett has a course which might be good to look at, look into with some material online as well.

• Kulpreet Singh (Portal Co-Host)

This is fascinating. What you’re saying is more grassroots. It’s very different.

• Casey Bowman (Portal DEV)

What I say is there’s really high caliber people involved and it’s just that human-to-human interaction. I think that’s really important too.

• Kulpreet Singh (Portal Co-Host)

That’s it. I like the way that you’re talking about it. There is no expert there. Nobody there is the teacher. People are coming along and learning as a group. I’ve got to try that for something. Maybe I should try to be gardening.

• Casey Bowman (Portal DEV)

Right, why not?

• Kulpreet Singh (Portal Co-Host)

Awesome. Thanks guys. It was amazing to listening to your thoughts there.

Manoj, I hear you. So I I’m pretty sure you’re here. Hello again.

• Manoj Duggirala (Portal Co-Founder)

Hi Kulpreet.

• Kulpreet Singh (Portal Co-Host)

The first question and on the top of the mind is like people have been talking about why Portal is focusing on iOS and Mac OS. The logical question that comes to mind is also like why didn’t we just build something in windows and a in-browser application like Metamask?

Could you share your thoughts on that?

• Manoj Duggirala (Portal Co-Founder)

Sure, we’re not really excluding any platform. That’s not our strategy.

For people who might not be familiar with us, we actually had a multi asset value in the Mac App Store back in 2019 for a brief period of time and it was the first app that had an exchange integration and was approved by the Apple App Store.

We chose the iOS back then because it offered the best tools in terms of security like Secure Enclave which helps you build a very secure software. We also didn’t like the idea that back then Slack was one of the premier apps and most of these apps were built with electron and they were pretty bloated in terms of performance, so we went with the native apps for performance reasons and we wanted to offer the safest wallet in the market.

In hindsight, it might have been easy to just go with JavaScript like everyone else and now there’s a ton of ecosystem around this. Given the legacy and the developer resources we had, we are initially launching with iOS and Mac App and it’s also very easy to do a test rollout for alpha and beta testing.

So we’re starting with that but in parallel we’re also building so none of the platforms will be excluded, then all the learnings from our testing will be transferred to other platforms.

• Kulpreet Singh (Portal Co-Host)

OK, that sounds awesome. Outside of Mac OS though like not talking about iOS, if you were to target users on Windows and on other platforms, you would go with native?

• Manoj Duggirala (Portal Co-Founder)

We will use tools like flutter. We’re not going to build using native because right now the ecosystem is sufficiently advanced and there’s a lot of libraries that you can tap into. So we’ll do that moving forward.

• Kulpreet Singh (Portal Co-Host)

Ok, No need to reinvent the whole wheel. That makes a lot of sense

• Manoj Duggirala (Portal Co-Founder)

To add to that, I mean we’re also developing a Metamask like browser extension. So that all of these dApps can interact with them so people don’t have to trust a website with their keys. That’s also in the works.

• Kulpreet Singh (Portal Co-Host)

That would give you kind of a segue or leeway into going to different platforms right once you once you have something at least a small way to interact with portal as a browser extension then at least you can do a few things.

OK that sounds awesome. I mean the the next question then probably is not that meaningful but I’m curious about it anyway.

What if you know given how Apple can you know block applications for whatever reasons?

Like you said, a backup plan for a distribution channel. I think you’ve kind of addressed this question, but just wanted to explicitly ask that.

• Manoj Duggirala (Portal Co-Founder)

Yes, I mean that’s a good question because you’re always at the risk of these gatekeepers and when you build around wall gardens like Apple and Google. They can censor you and we’re trying to build something which is uncensorable.

In terms of our strategic plans, we’ll have a Portal desktop app like we talked about and we’ll release these in succession and we won’t post these on our DNS, its a liability if we host it on our website. If you look at Uniswap, that’s one of the lawsuits that they’re facing and also you can get kicked off by the likes of DNS providers but truly trying to go towards the path of decentralization, where anyone can download the app and run their own exchange and connect to the network and the magic of the swapping apps happens.

But you know it won’t happen overnight.

That’s our goal. We’ll start slow with iOS, Mac, and Android apps but the path is quite clear. We are moving towards decentralized things where we don’t have the central point of attacks.

• Kulpreet Singh (Portal Co-Host)

Yes, I mean and also like this leads to the question on you know, building taps on Portal Defi. I think in the last Fireside chat you were also mentioning how you can build different dApps on top of Portal like we’re curious about if you’d be willing to or open to other developers building it and what kind of SDK plans do you have around it?

• Manoj Duggirala (Portal Co-Founder)

Yes, that is the plan we want others to build on top of our dex. It can start with the basic simple contracts like building derivatives on Bitcoin to more complex ones like what you’re building at braidpool, right?

The hash rate, derivatives and mining and stuff.

If you have these things, you know you can tap into the network which generates the liquidity.

We’ll also initially bootstrap the ecosystem with our own apps on top. So you know there’s already one that we’re planning to which is a simple price prediction service on top of the dex which where you can subscribe to get alerts on when to buy or sell a specific asset based on models but in terms of the SDK, it’s still a work in progress.

We’re not quite sure what components will be useful for developers but we’ll make it as simple and as easy for developers with robust documentation and supporting languages that benefit the ecosystem.

It’ll be sometime in Q1 2024, the early adopters will actually help us shape it. We’re looking for design partners in that sense.

• Kulpreet Singh (Portal Co-Host)

Yes, building an API that talks to a dex so you’re already your mind starts exploring what about the possibilities and the challenges as well.

So we definitely are very interested in listening to more about it.

These fireside chats are going to help the community keep up to speed with what’s happening.

• Manoj Duggirala (Portal Co-Founder)

Right.

• Kulpreet Singh (Portal Co-Host)

Thanks. Maybe next time we we dig into some more details around those those concepts. Thank you again so now we jump on to Eric.

Eric, do you hear us?

• Eric Martindale (Portal Co-Founder & CEO)

Loud and clear.

• Kulpreet Singh (Portal Co-Host)

Excellent. I hope you’re not watching the semifinal today when you made the time to talk to us.

• Eric Martindale (Portal Co-Founder & CEO)

Yes, I stepped out to just to join you guys.

• Kulpreet Singh (Portal Co-Host)

Excellent, so I mean very curious about what is the lineage of Portal and all the products that are being built by by the team here.

Manoj mentioned that back in 2019 something was happening and I’ve heard that you’ve been working on some projects even before that. So if you could talk through the history of where you started off, where you are, and where you might see you might go.

It’s a kind of a generic question to satisfy the curiosity of knowing how deep the depth of knowledge is in this team.

• Eric Martindale (Portal Co-Founder & CEO)

Sure, the initial idea for Portal I believe came in around the same time as I started working on Fabric itself and the original idea was to initially have a portfolio manager be able to be able to swap your cryptocurrencies but really have a comprehensive view for the more sophisticated investor who is buying some cryptocurrencies and moving in positions from one to the other. There was an initial prototype built back around that time, 2018 and 2019. We took it down from the store because the first implementation just wasn’t fully up to the security thresholds that we were looking for and we wanted to take the product in a slightly different direction.

So we did I believe it was sort of towards the end of last year we began to work on a secondary code base kind of building it from the ground up with all of the learnings that we had had from the Fabric side as well as from building out the initial.

Apple focused economic application and we’ve come pretty far but at this point it’s just trying to get it over the finish line and getting everything implemented. Some new libraries have come out since then and we’ve really refined our approach. So you know it’s coming along fairly well.

I think that’s a fairly good history.

• Kulpreet Singh (Portal Co-Host)

Yes, that’s fascinating. So now we’re with the MVP for the purposes of this conversation, right. So in your mind, in your vision, what is the product there that the user is downloading and making money essentially running a node & earning fees? Like how does that work?

• Eric Martindale (Portal Co-Founder & CEO)

Because what we’re building is aiming for two things.

First. We want something to be strictly peer-to-peer and so in a traditional exchange, you typically deposit your funds into the exchange and the exchange will take a slice of executed orders or even just charge up front for issuing orders on that platform.

They can do that because they are still that central party or intermediary.

Because we’re going to peer-to-peer, there’s really not as much of an opportunity for Portal the company to really step in and take a slice of that of that trade. So what we’ve modeled ourselves after is much more like what you see in say for example Lightning where by participating in a route or participating in storing messages for relay onto other people or perhaps even finding peers for the traders whether you’re a maker or taker.

It is strictly for the facilitation, it’s the the ASK for the participation in helping those users find one another within the peer-to-peer network.

Obviously you know there’s us as a company we were looking at other value added services on top of the exchange. I mean by design we’re sort of almost cutting ourselves out of the picture. So you know we’re looking at a number of other things including you know price predictions & access to liquidity.

For example, you might think about a submarine swap where instead of your swap, instead of swapping between two different cryptocurrencies, you’re swapping between the two different layers, Layer 1 & Layer 2.

So you can look at Portal and the individual’s opportunity to earn money in much the same capacity as you would earn in Lightning which is by either helping move the funds along in the route or by storing & relaying messages on for other peers, which helps a maker find a taker for his order or helps a taker find a maker for his order.

So it’s really in in just sort of the whole order matching aspect.

Obviously there is you know other things that we could do as a company internally for us, but as far as the funds that a user can earn. We’re strictly looking at this sort of peer-to-peer model in helping the funds move along.

• Kulpreet Singh (Portal Co-Host)

So it’s again very much as you said as well as the Lightning node operator fees that they charge for forwarding the Lightning transactions right here.

The users nodes are essentially acting as matchmakers or are just facilitating the the trade by forwarding it.

• Eric Martindale (Portal Co-Founder & CEO)

It’s actually both right now and we’re trying to figure out where there are other opportunities but there’s sort of an abstraction there. it doesn’t particularly matter what the message is.

The idea is that there are it’s just a message right. Whether that message is of type you know order or messages of type of some other type as long as you’re participating in helping move that that message along to its intended destination. In finding a potential destination, you’re going to be able to take a slice of it as a as a node operator.

• Kulpreet Singh (Portal Co-Host)

OK, got it.

Then it’ll come down to the nodes having the network connectivity similar to Lightning like having the right number of channels with connectivity to be able to get more fees because you’re forwarding more traffic, would it come down to that as well?

• Eric Martindale (Portal Co-Founder & CEO)

Yes, it’s about that and the reliability of your node right like just how long you’re online. If you can stay online consistently then you can see more of the messages and if you can see more of the messages then you can match more of the orders. If you have good connectivity with the appropriate peers then it’s going to be very likely that your node is going to be involved in the order matching or message.

Passing that is for a specific trade or specific activity on the network.

• Kulpreet Singh (Portal Co-Host)

Right. That makes a lot of sense. So then I mean this continuing with this parallels between Lightning and the Portal dex. In the world of Lightning, there is this thing about the problem of having the Watchtowers, right?

There are some solutions but they require some changes to Bitcoin as I understand. Is there something similar like if a user goes offline, is there any element of that happening that the other party could take away their funds or close the channels?

Or is the user safe if they go offline?

If they don’t go offline, any reason that might happen?

• Eric Martindale (Portal Co-Founder & CEO)

We do still follow the model where you in order to be fully secure, fully self sovereign, you do need to run at least your own node. That’s basically what a watchtower is, you have a a reliable full node that notifies the downstream clients of any activity on the chain, on the main blockchain if any particular condition of the contract has been triggered or for example that maybe the node also holds existing signed and unsigned transactions, whether they be settlements or channel closures. So we do still kind of have that limitation of you really do want a reliable always online full node. But we’ve talked a little bit about this this message passing idea and the the inheriting from Fabric.

The idea of having these message mailboxes or queues really improves the resiliency and reduces that risk significantly because there are multiple pathways. Every node in the network has the opportunity to store these messages for when the intended user or intended recipient comes online.

So based on the time lock, you know there is a expiration for the contract, at which point you can check the last time that you were online, it is possible. In the same way that it’s possible in Lightning, it’s possible that you may lose some part, some portion of of accumulated balances but as long as you have good connectivity to a set of peers that are hosting your mailboxes then those peers have the ability in the event of a channel closure or a force close, those peers can also broadcast and potentially earn a fee as a result for “saving your ass” in the event that you went offline.

• Kulpreet Singh (Portal Co-Host)

Yes, that’s a really neat idea. I didn’t know about the mailboxes ideas in Fabric. I think we’re going over this in the next Fireside chats. I’ve never heard of that in a peer-to-peer network that there is a message box which is kind of holding on to your messages for you till when you come back if I understood it correctly right?

• Eric Martindale (Portal Co-Founder & CEO)

It’s just like a message queue. So we’ll definitely cover that in more detail when we can get a screen share demo going so that we can start to show that to everybody.

• Terry Philipson (Portal Host)

Speaking of offline per our last fireside chat. I wanted to ask this last time but what are your thoughts again on some of the real world use cases of tokenization like say tokenizing concert tickets or tickets in general?

To me the concept of a ticket is in essence just a rights holder document.

• Eric Martindale (Portal Co-Founder & CEO)

Yes, so tickets are an interesting case. I mean there is the single issuer in the case of like a concert ticket or an event ticket. You have an issuer and the other interesting property about those types of assets or those types of contracts is that they’re almost one they’re one time use really. So when the issuer issues one of these tokens you know it can be held by the user in the same way that cryptocurrency.

Can be held on the device or you know, whether it be on cold storage or on an actual device. Then when you show up to the venue, you show that you have the asset and it gets consumed. It’s almost like a redeemable.

So this is quite a bit unlike you know all the other cryptocurrencies out there which unless you burn them explicitly they can be traded and moved along the path but in the case of a concert ticket, it’s it’s a redeemable asset. So the asset in essence, I don’t want to say burn because that’s not the technical thing that happened. It actually just gets consumed. But in this model you know, you have some issuer which is either the venue, the event organizer or maybe even down the line. You know, you could have a partnership with say Ticketmaster or someone like that who is the actual issuer of the asset and then the venue, whether they’re operating this themselves or they’re with a partner like Ticketmaster. They’re the ones who kind of maintain this Ledger. It’s not particularly a great use case for distributed systems and blockchains.

While the idea of the ticket being transferable and sort of kind of cutting into that ticket scalping / black market, you could show up in an event at a venue and a lot of times there’s tickets for sale outside. You do want to preserve this ability for users to kind of kind of transfer these tickets.

But the unique property here again is that it’s redeemable. So I mean this is something that we want to get into with P.A.T.H. I mean while we are a little bit more focused on redeemable assets such that are focused around energy and stranded energy, mineral rights, property rights, etc. The idea of tickets / concert tickets kind of fits in there in the same capacity because if you can imagine a mineral then you know that too is also redeemable.

So there is absolutely a path forward for us to kind of break into that market.

Although we’re kind of focused on the the mineral rights and property property titles etcetera at this time. It is very analogous. They’re very analogous and very much a similar type of structure. So we can use a lot of the same code on each of those.

• Terry Philipson (Portal Host)

Thank you for that, Eric. I’ll leave it back to Kulpreet.

• Kulpreet Singh (Portal Co-Host)

Thanks, Ron. Eric, there’s a few questions we have here for you but I’ve been mindful of time. So what if we jump to Artee or Alexey, what do you guys think?

• Eric Martindale (Portal Co-Founder & CEO)

Yes. I mean, it sounds good, sounds good for me. I mean we may have a little bit of time at the end to to cover any of the dangling questions. Let’s move it along and then maybe at the end we can cover some of the questions that we skip.

• Kulpreet Singh (Portal Co-Host)

Yes. Because I’m very, very curious what Alexey has to say about Ethereum.

Alexey, are you back? Can you hear us?

• Alexey Melnichenko (Portal Engineer)

Everything should be

• Kulpreet Singh (Portal Co-Host)

Excellent, we hear you.

• Terry Philipson (Portal Host)

Yes, we can hear you.

• Kulpreet Singh (Portal Co-Host)

Awesome. So when we were talking to Casey the idea was, “OK, how do the Layer 2 swaps work between something like Bitcoin and Ethereum?”, and he painted a nice picture of what’s happening on the Bitcoin side. We are very curious about what happens on the Ethereum side. Before we go there, if you don’t mind maybe just giving us a bit of a primer on how the Layer 2 works on Ethereum just generally from first principles, so that people who are not so aware of innovations on the Ethereum side of things.

If you could kind of give us a quick intro, what do you think?

• Alexey Melnichenko (Portal Engineer)

So it’s essentially works as a yield farm when you open a channel. You just deposit some tokens into a contract and they count as your Layer 2 tokens.
Then you’re able to take those and open channels with any other user of the Layer 2. When you do that, you take some of those Layer 2 tokens and deposit them into the layer 2 channel with that other user and then you’re able to send payments.

The good thing about this for the swap is when you send the payment, that’s actually locked initially with the secret and the payment has essentially an ID based on the hash of the secret and then the receiver of the payment can’t actually get the payment until they know the secret in some way, and there’s multiple ways they can know the secret here.

• Kulpreet Singh (Portal Co-Host)

Hmm.

• Alexey Melnichenko (Portal Engineer)

Essentially these transfers are instant and free.

• Kulpreet Singh (Portal Co-Host)

Awesome.

• Alexey Melnichenko (Portal Engineer)

Yes, there’s a peer-to-peer messaging protocol which basically lets users discover each other and then a separate one where they talk to each other directly when the actual swap is happening.

• Kulpreet Singh (Portal Co-Host)

So the secret reveal happens over this Peer-to-peer channel or are they listening / watching for the transactions?

I can understand on Layer 1 what would happen is the the secret would end up being revealed through a transaction that is on-chain. How does that happen in the Layer 2 world?

• Alexey Melnichenko (Portal Engineer)

Actually on the Layer 2 it’s quite different whenever anyone with the matching payment hash reveals a secret. That actually clears all payments on the whole network. So even if you have like 10 payments going at the same time with the same exact hash, whenever any of those parties reveals the secret, all those payments instantly go through. So that’s quite convenient for tarmac swaps compared to having to take a bunch of steps to unlock all payments individually.

• Kulpreet Singh (Portal Co-Host)

So the secret reveal also works across multiple hops, right?

How do the multiple hop payments work in this situation, say for example I have a node on Lightning network or on the portal side / Lightning side of things and you have a node on the Ethereum side of things, right?

But we are not directly connected to each other.

• Alexey Melnichenko (Portal Engineer)

Right.

• Kulpreet Singh (Portal Co-Host)

Can we send the payments?

Can they be routed to through the respective networks and then somehow discover each other? How does that work?

• Alexey Melnichenko (Portal Engineer)

Initially I would just describe the Ethereum Layer 2 swap without the Bitcoin so both of the nodes just connect.

The simplistic version is they both connect to one Mediator node.

So they’re both open channels to the same node essentially.

• Kulpreet Singh (Portal Co-Host)

Ok.

• Alexey Melnichenko (Portal Engineer)

There’s a path from user one to user two through that mediator, so they’re able to send multi hop payments through the mediator to user two and when that happens, they send it to the mediator.

Then the mediator sees that that they received the payment and that it’s eventually going to user two, and they send another payment to the user two and the user two sees they have an incoming payment with that hash that matches in order book trade and they send the correct amount back to user one through the mediator and once again.

• Kulpreet Singh (Portal Co-Host)

Hmm.

• Alexey Melnichenko (Portal Engineer)

And they send the correct amount back to user one through the mediator and once again the mediator sees that incoming payment to the same hash and sends it back again to user one but that same hash now.

• Kulpreet Singh (Portal Co-Host)

Nice.

• Alexey Melnichenko (Portal Engineer)

Now user one sees that they received the payment with the correct amount back for their initial payment with the matching hash and when that happens, they simply reveal the secret by unlocking the payments on the whole network and this triggers both of the payments to go through across the whole network.

• Kulpreet Singh (Portal Co-Host)

So essentially it comes down to the nodes finding a route to each other through a mediator and they could choose a mediator or they might not want to choose the mediator if by accident the trades are matched by the mediator that they’re both connected to, is that right?

• Alexey Melnichenko (Portal Engineer)

Well you want to be very careful with which mediators you’re using especially because each time you open a channel currently you lock up some amount of tokens, so we’re working on a service to essentially make this efficient and make it so that people are through some sort of network connected to the the same network of mediators who also have channels open to each other.

• Kulpreet Singh (Portal Co-Host)

I see. it’s at that much more tightly connected network that it’s easy to discover things.

• Alexey Melnichenko (Portal Engineer)

Yes in the simplistic scenario, it’s very simple. I mean the path is literally user one to mediator to user two and as long as the sender of the payment knows that path, they’re able to send that without having reliance on any other parties.

• Kulpreet Singh (Portal Co-Host)

Gotcha.

• Alexey Melnichenko (Portal Engineer)

When we get the more complicated, the network will be more complicated and users will need to either track all the open channels between all the Mediator nodes and leaf nodes or rely on some service. Someone might be running like federations or something like that.

• Kulpreet Singh (Portal Co-Host)

The hope that model that complexity would also need to manage the idea that nodes are using different blockchains.

• Alexey Melnichenko (Portal Engineer)

Right. So it would be fairly simple if you have multiple layer Ethereum Layer 2 on like Polygon and Ethereum mainnet for example.

But for Bitcoin to Ethereum Layer 2 swap will be essentially the same because both of the users still run Ethereum nodes and Bitcoin nodes, so there isn’t much of a difference because user two would see the incoming payment with the correct hash on their Ethereum node and then simply send the payment back through their lightning node.

• Kulpreet Singh (Portal Co-Host)

OK, that’s really clever. I forgot all about the idea that the next node was running both the blockchain nodes. That’s interesting, Alexey.

I think we’ll have much more questions once we wrap our head around what you’re doing a bit. So hopefully we’ll come back to this in the next fireside.

Maybe we move on to Artee now.

Artee, do you hear us?

• Pablo Artee (Portal Designer)

Yes, what’s up?

• Kulpreet Singh (Portal Co-Host)

Good to talk to you again man. So how does the self sovereignty or self custody impact UX?

That’s the biggest question right as I was asking earlier.

Is how do you how do you keep your funds safe if you go offline?

Is there is there issues that that you have to deal at the UX layer?

I’m sure there are and what do you what what are you thinking about Portal could could do to achieve this?

• Pablo Artee (Portal Designer)

We’ve mentioned part of this in the past fireside which is the difference between centralized and decentralized services.

People are going through this decentralized route.

There’s a lot that the users need to be aware of they need to be connected to the Bitcoin node, the Lightning node, all the nodes that want to swap then the Portal node which will be making that coordinator. Maybe in the future while we’re adding other functionality, there’s a Fabric node, or if we are pushing for complete censorship resistant, we might encourage them to get connected so instead of just depositing your funds in a centralized entity and then doing everything there without having the the custody, the user will be will need to be aware of the status of all these nodes that are needed for these to be really self sovereign and not just not your keys, not your coins kind of thing. It’s not just about the funds, it’s also about awareness of the network status and trusting your own node.

So the final user interface will have this kind of client that we will start in iOS first and we need to show the user the status of all these services that they call them dependencies. The service had to be able to do a successful swap, so we will need to show the user the status, allow them to maybe change their own node, or troubleshoot if there’s some some of these dependencies that are not working correctly and this might be trivial for tech savvy users but to get to the mainstream we might need to educate them as to what all these dependencies, what to do about them, and maybe we’re still thinking about this but maybe it’s some kind of progressive road to being completely self sovereign. Maybe at the beginning they could use the node of a friend or a trusted pilot node and then upgrade to this real sovereign thing.

We will allow them to connect to wherever they want to but I guess that’s the biggest issue regarding UX, giving them the tools to be able to to handle all of these, to manage this, to be aware of that status, and teaching them what each of these dependencies are & how to handle them.

There is some education in all that’s actually pretty interesting point as well as to how do you get users to learn about not just not just Bitcoin & Ethereum that they might want to wrap their heads around but also the complications of the fact that there will be a lot of in-app kind of training or education that you might need to think a lot about. It sounds like not an easy challenge.

Yes and the Pareto tree principle holds true always everywhere. So I’m imagining that maybe only 20% of the people will really be completely sovereign because of all the hurdles that the user needs to go to.

The other 80% will make some trade off and inside that 80%, maybe only 20% will be self custody and the other, I don’t know exactly that but institution of it. But what we should do in my opinion is just give them the tool like this client can work even if our server goes down and they can point to their own services so they can choose this level of self-custody of this level of sovereignty, even if sovereignty is not really like it’s binary.

You’re sovereign or you’re not, right?

But we’re imagining this kind of spectrum. So I’m trying to put users to get to the final destination.

• Kulpreet Singh (Portal Co-Host)

It’s not as equal to one step and it’s not easy for a lot of users and it’s very easy to kind of step back and take one shortcut and certainly you lost the sovereignty that you had. It’s not easy.

It is a zero to one step and it’s not easy for a lot of users. I mean and it’s very easy to kind of step back. You kind of take one shortcut and certainly you lost the sovereignty that you had it. It’s not easy. It’s not easy for sure.

• Pablo Artee (Portal Designer)

True . When we’re talking about the developers, tech savvy people, it seems like trivial to do all this. But in the minds of a lot of people even the idea of holding Bitcoin in central exchanges may just be overwhelming for users.

We need to deal with that.

• Kulpreet Singh (Portal Co-Host)

Thank god we got people like you to take care of that.

So on that note; Do you think there will be a vision in the future where there could be other wallets interacting with Portal dex?

I mean what are the challenges, what are the steps required to get to such a feature if such a feature is in our road map?

• Pablo Artee (Portal Designer)

Yes, it’d be great like that. That’d be a really a goal to just provide the services that we’re talking about in a modular way. Imagine that maybe we have this decentralized exchange. It would be really cool if any wallet could interact with it.

Why?

Maybe having a wallet is really an inconvenience like we’re maintaining this other piece of software that is taking care of user funds. There’s a lot of people and a lot of other wallets that are making already this work.

So it would be really good if anybody could interact with it the same as two marketplaces in general. If our sub technology is really cool, I’ll be delighted if a lot of exchanges or other marketplaces could interact with it and just use us as a rail which we provided for the native app who earned the fees and we could like tap in more liquidity like everything that we’re building. Everybody should be able to take advantage of those as a way to onboard users onto the dex. If you allow a lot more gateways in right then why should you be limited to our wallet to kind of get started with the dex.

I like that idea. It’s a long term dream like utopia.

• Kulpreet Singh (Portal Co-Host)

Yes, absolutely.

• Pablo Artee (Portal Designer)

The first version will be a completely integrated thing where we will be ironed out all the bugs and cases that that would appear right. And interoperability is if it’s certain issue. There’s a lot of different working groups that are trying to get to certain standards and it’s not easy to get to standards and it’s really good to have multiple implementations of stuff but not monopolize it.

It allows for innovation.

We needed a way to kind of start interacting with the system and then once you had it matured enough, you could let other wallet providers do the hard work.

• Kulpreet Singh (Portal Co-Host)

Cool, that sounds awesome. But for but for the current plan, when the open data is available, where would people download the app from? Would they have to go to the iOS marketplace or how do you plan to ship it?

• Pablo Artee (Portal Designer)

The first very first public version will be to the Apple marketplace.

So we’re just testing out like that the whole ecosystem and there’s no point in maintaining a lot of other variations of this client until we know it’s really working internally. The first public will be on the iOS App Store.

• Kulpreet Singh (Portal Co-Host)

Yes that makes sense. So I mean within the app.

• Pablo Artee (Portal Designer)

We’re talking about the wallet. There will be a lot of applications on the Portal OS which has mentioned it will be part of our website and you’ll be able to configure or download. So it depends on the actual product.

I’m just focused on the wallet at this time.

• Kulpreet Singh (Portal Co-Host)

The question was for the wallet so thanks for clarifying that.

Do you think you’ll be providing ways for people to give feedback within the iOS app itself or what is your plan on providing support for users?

• Pablo Artee (Portal Designer)

Yes not just in the app but also on the website. Wherever the user wants to give us information, we’ll be happy to take it.

• Kulpreet Singh (Portal Co-Host)

Hmm.

• Pablo Artee (Portal Designer)

It’s really rare that a user really gives you feedback. Most people will just use the app, find a reason to get angry at your app and just delete it.

We will try to make it as accessible as possible for them to tell us anything.

Even if they want to tell us that they hate us, that’s fine.

Hopefully they tell us why so we can do something about it.

• Kulpreet Singh (Portal Co-Host)

Yes.

• Pablo Artee (Portal Designer)

Whatever channel they want to talk with us, we’ll be happy to get information.

• Kulpreet Singh (Portal Co-Host)

Yes, user feedback is paramount. Spoken like a true person who’s obsessing about the UX.

• Pablo Artee (Portal Designer)

Yes.

• Kulpreet Singh (Portal Co-Host)

Good, awesome. Thanks Artee.

Thanks for your time again.

We probably have more questions for you in the next Fireside chat.

I was wondering if Eric is still around, if we could ask you at least one more question before we go.

• Eric Martindale (Portal Co-Founder & CEO)

Yes, for sure.

• Kulpreet Singh (Portal Co-Host)

OK awesome.

When I was talking to people about what the portal OS looks like; how would the node run? What are the various components?

How does the swap work so.

The question that comes to our mind is how long would it take for a user, say they have Bitcoin already somewhere and they decide, I’m going to run the Portal dex and then start doing swaps on that.

What is the time frame there like? Do you have to wait for a certain number of confirmations on Bitcoin or on maybe on Ethereum?

How long does it take for a user to start actually trading from the moment they download the dApps?

If not, what do you think would be the timeline?

• Eric Martindale (Portal Co-Founder & CEO)

Yes. We do take a couple of shortcuts and in the application we’re going to probably introduce Watchtower functionality, the opportunity for once you have funds in the wallet itself, meaning at least one confirmation that is absolutely sort of the the beginning layer for when you can start trading.

There may be other opportunities for us to even accelerate past that but it’s not necessarily advisable.

Because, again, you’re reintroducing trust to the whole whole situation which is exactly what we’re trying to eliminate. That you now have a third party you know having control of your funds et cetera.

But you know on the safer side, I mean you can basically look at it as if it were a Lightning channel. So as long as you have a balance in a Lightning channel then the ability once you’ve downloaded the app then you should have almost immediate transferability. But again I but on the safer side, I mean just like the White Paper kind of recommends.

I mean one confirmation is kind of the minimum. 6 confirmations is really the ideal, the gold standard. We talked a little bit earlier about submarine swaps. It’s entirely possible through some of these shortcuts that I’m talking about that but you may be able to with a Layer 1 balance from an external wallet. You’ve just downloaded the app, you set up your new keys, you instead of depositing / transferring into that, it may be entirely possible to get access to that faster liquidity, faster trade ability by using submarine swaps if you have a Layer 1 balance somewhere.

You’re purchasing a Layer 2 balance, and you’re basically swapping the Layer 1 balance for the Layer 2 balance but again, while we could possibly enable 0 confirmations, the absolute minimum that we look at from security threshold is 1 confirmation.

So you are still limited by by at least that.

Again, there’s some shortcuts that we can take and we’re looking at that but we don’t want to compromise user safety in any way.

• Kulpreet Singh (Portal Co-Host)

Yes, I mean that would be that makes a lot of sense at least for security purposes. If you need to provide a certain level of security, you need at least 2 or 3 confirmations, if not 6. It’s still an improvement.

• Terry Philipson (Portal Host)

ohh, absolutely.

• Kulpreet Singh (Portal Co-Host)

Yes. So what should we do?

Should we ask another question or are we over time?

• Terry Philipson (Portal Host)

I think we’ve got time for at least one more.

This actually came from our telegram channel. I think we touched a little bit on this earlier. See who’d like this question?

Could you explain what payment channel solution will be used for the VM?

• Eric Martindale (Portal Co-Founder & CEO)

I mean, I think that’s really an Alexey question but I will say that it’s probably Raiden.

Raiden is the most likely candidate & what will possibly become our own solution where we deploy our own contracts and have manage our own payment network but Alexey, feel free to to chime in here.

• Terry Philipson (Portal Host)

Ain’t nothing wrong with redundant avenues.

• Alexey Melnichenko (Portal Engineer)

Yes. So the prototype was built with Raiden essentially but there’s some things that have to be changed on the client side.

The state did not allow for multiple payments with the same hash so there’s quite a bit of work that had to be done to get this working but that’s still compatible with the Raiden network itself.

The only thing that has changed is the the node client code for the actual local storage of the transfers.

• Terry Philipson (Portal Host)

Keeping compatibility. I like the sound of that.

• Alexey Melnichenko (Portal Engineer)

Yes. It was like without having to create their whole separate network, we’re able to do swaps and read them currently, so I find that to be quite convenient because we can take advantage of all existing mediator nodes that can read them and all that stuff. All the liquidity that exists already.

• Terry Philipson (Portal Host)

Absolutely having that instant access.

• Alexey Melnichenko (Portal Engineer)

Gas for us as far as a custom solution, we’re looking into that as well.

• Terry Philipson (Portal Host)

alright

• Alexey Melnichenko (Portal Engineer)

Yes, we could potentially make it optimized for swapping as opposed to just sending payments, so there’s possibility with that as well.

• Terry Philipson (Portal Host)

Excellent and that’s looking like all the time we’ve got.

Thank you everyone for joining and hope to see you at the very next one and actually before we go, if you’re interested in joining the product waitlist.

Make sure to e-mail testinglab@portaldefi.com for our early investors if you have already invested with us.

Until next time, folks.

• Eric Martindale (Portal Co-Founder & CEO)

Thanks, everybody.

• Kulpreet Singh (Portal Co-Host)

Thanks everyone.

• Pablo Artee (Portal Designer)

Thanks. See you later.

• Kulpreet Singh (Portal Co-Host)

Thanks. Bye.

• Terry Philipson (Portal Host)

Hey, thanks for listening to us when the World Cup is on.

• Kulpreet Singh (Portal Co-Host)

Bye.

About Portal

The Portal project is a peer-to-peer, trust-minimized application running on top of Bitcoin. It allows users to access a decentralized network right from their wallets. In addition, users can now manage multiple blockchain assets and financial services from within their wallets. With Portal, DeFi becomes a service that anyone can provide, maintaining anonymity for a competitive fee within open, transparent markets, with a security model as robust as Bitcoin mining. And because it is built on Fabric, it comes with privacy, speed, and security.

A Financial Internet Built on Bitcoin ✈️

Join Our Socials!

Telegram | Announcement | Twitter | Medium | Discord | Website | Instagram