ok_uscuvilca · Transcript · · Updated
exchange STUFFF cheeeck – Transcript
Video by ok_uscuvilca · Watch the original on YouTube
Summary
AI-generated from the transcript. Verify details against the source video.
- The speaker explains that data analytics updates are online and moving toward full coverage.
- The team discusses fixing tickets related to zero-coupon calculations, V2 compiler SQL issues, and governance progress.
- The speakers review the exchange moonshot, replacing the corda node with an AWS Nitro Secure Enclave and using MCP for agent communication.
Use this video with Pro
Reading, copying and transcript downloads are free. Create saved AI results for this video with a signed-in Pro account ($9/month).
Transcript
Search ignores accents. All transcript text stays visible.
database and pull out the actual leis from those documents. But um I think this is probably a little bit out of scope for what we would do. But um just so you know, moving forward, we can get 100% coverage on these 144 days, right?
That remaining 11%. We'll just need to sort of build out that SEC extension. So, um for now, we're we're good, but we just got that stuff online last night. Um it kind of fixed up this morning. Um it's not thoroughly tested yet, but um that's kind of my update on data analytics. I'll pass it to you. Um intera before I get into the the other
two works. >> Yeah, sure. So I've been working on this ticket governance on ticket the perpetuals for instance is fixed already. It's in production. Uh so there's a question regarding the zero coupon tickets in real time. I think you put a comment random on the the ticket.
So what what we're doing is we're calculating zero coupon in EOD when we have null yield but for Y time we're we're getting null and we are not calculated. So the question is if we should and then I guess we should we should we should add it. Sorry that it's a SQL it's a sub procedure. No um dynamic table change is it's just a straightforward but I found out that we
are not calculating yield for real time for other types of of of products that we get null from from fing. So we have our filters like perpetuals or convertibles. We believe it normal but there are others that are coming correctly that we got yield but eligible for us to calculate their their yield.
So I have so I guess we have to also if we're doing it for EOD we have to do it also for real time. So whatever we do for EOD we will do it in real time as well. So that that's what I'm working right now.
Uh, another thing that I'm start working on is the ticket 27.99. Uh, reported by Kevin yesterday. So, the this is the the capped trades, the IG versus uh the 5 million and 1 million. I found out the issue. The issue is I think Kevin that's the that was V2 that you were checking
on. >> Which one again? Which one again? Which ticket was that? >> 2799. >> Oh yeah. >> Oh yeah, that's the October 28 one. >> Yeah, it was a >> What happens is that the data is correct, but the V2 I guess is the compiler. It created its own SQL and it created a bad condition. It created uh
gives me the data for anything any quantity above 5 million or if it is capped meaning the or include the 1 million. So it's is a bad SQL that that that's that's the whole thing. So the actual compiler created its own SQL and that SQL was not accurate.
So I'll put the details on the on the ticket and I guess probably I'll pass it to you random or because it's a compiler thing I guess it's a boom that needs to be changed with the details there. So it yeah so we need to update the ontology mapping so that um because the yeah because the compiler the free planner semantic whatever it just takes the anttology and says based on the intent right trigger this so if we can update
the ontology templates that'll basically >> okay perfect I'll I'll try to >> that's my work on today then I have a couple of um yeah and then I have another ticket for from uh Kevin he gave it yesterday so I will work on that today too
>> 2798 I'm guessing the volume par versus ocean question >> yes yes that they're two urgent tickets so I'm going to work on those today >> and the governance uh I'm you know progressing I'm working at the same time both the ticket while it's running the governance is doing its own stuff so that's an ongoing the governance I'm
creating ticket sub tickets so for I'm I'm checking the data quality I already the inventory the sensibility so yeah I have like at least four or five more tickets to go through to finish the mega ticket and then I'm going to document the whole thing after That's ongoing I think.
>> Yep. >> Okay. Um Kevin, any comments on data before we move on to the second work stream which is basically just UI UX1 work we've done set to sub per data >> would be pretty good as I went through.
Um, so I'll just keep adding stuff as I see it and we'll just dig into it. But it's more Yeah, I think we're pretty good. Yeah, we're good. >> I'm sure there's a little stuff that's wrong, but I think most of the issues are um not not data, although there are some data issues, but >> Yes, sir. Yeah, I think the issues you're talking about are more like the
second work stream which is really just the the V2 ontology. It's a map of like what customers and traders PMs like say doesn't map directly into the answer that they get correctly. So I saw the issues that you put in um there's I mean there's a lot but luckily like you only have to fix it in one place. So we're looping through that. Um there's like you know like you and I
showed before like we're pushing to production like five times a day, right? So this stuff is is taken care of um pretty quickly and and effectively.
So I'm happy about that. But um you know my hope is that every day we go in things get a little bit better. the one sort of um variable is we're adding in new data too specifically like the fundamentals the the issuer parent you know child's and whatnot. So it's slightly um a bit of a moving target if that makes sense. Um you know the product changes more data more more intelligence
etc. And it and that's just something we'll we'll iron out as we go through. Um so yeah That's that's not really the I mean that's important and I think that's a priority for the conference like we want this tool to be perfect in front of customers market access etc. That's our goal. Um, and so
the third uh item is really the moonshot we have with the exchange. And so I'll talk about that for a second um Kevin because I know there's like a lot of new stuff here. But um you know UBS talked about the pilot and we thought like hey maybe in the background we could do some research look at the exchange code see what's there see what's missing and you know
the moonshot that is it's like it's always nicer to show people than have to explain it. So I wanted to get this on on production um and it is with some caveats. So um the the code that we inherited was like half there. Um Yala Labs had you know
their own matching engine. Um there was the COA you know node and um you know the pricing you know feeds that they were buying from other venues and the risk engine and um that was not present. So we did go in and we did write our own version of it.
Luckily we have the specifications for Ledger Edge. So we know all about the reveal conditions. We can understand the intent behind it. Um and we can you know build it appropriately um based on that intent. And so the biggest change is we're really replacing the venue feeds that Ledger Edge was buying with our own directly from our
database, which is that's awesome. It's like free lunch for us. Um, some of the work that we did with the LE stuff and GLF is really important because this is an American exchange, right? And so we don't want to trade um anything that's weird, right? So having like the parent company, child company, being able to trace exactly where these prints come from, how they
match up with CGS is like kind of a deal breaker, right? And so getting that the missing piece that we had in um you know, yesterday today is is just like really really kind of massive and um an unforeseen thing. But hey, like we dealt with it as we kind of um had it come across our desks. um the
the cord of node that piece um really heavy, really ugly, really slow. Um and we're basically able to replace it with, you know, a fast normal exchange, right?
Like FTX, like ICE, market access, like big dogs, like this a technology that these guys use. So, um we wrote a lot of those bits in Rust, which is, you know, great language. You can prove it's, you know, correct. It's fast. Um, and just like the translation is it's like it's just it's just machine code, right? It's literally as close to the metal as
possible. And I did make one judgment call in sort of the rewrite and that was based on, you know, the ledger edge secure enclave of context. Um, so the idea in the past was to run a corner node. You know, your keys, you're safe, you run it, right? you don't have to worry about people messing with your um your book and looking into your reveal conditions looking into your portfolio,
right? That was a key selling point for the exchange. So, we just swapped it out with Amazon's AWS Nitro Secure Enclave, which is basically like you have a key um and then there's a piece of hardware, right, running on the the hardware is the enclave, right? And so customers take their key and then they can have access to their portfolio in the system.
It's provably correct. It's secure as the hardware. At this point, the only thing you have to worry about is a supply chain attack with, you know, something pumping out like, you know, dirty CPUs or or whatever. And I I'm confident AWS has a um under wraps, but um for your benefit, Kevin, is that does that seem like a trade-off, a fair trade-off? Blockchain, node, whatever stuff or just