Hi, my name is Mark Zu. I'm a lead infrastructure engineer at Bottas Labs, an L two Bitcoin startup. I'm here today to speak about seeing beyond signatures and how we set up a federated motorcycle of mobility. So the first question is, what are multi six? A popular saying by Bitcoin MAL would be your keys, not your keys, your Bitcoin, not your Keys, not your Bitcoin. We ask ourselves, what is the true purpose of a multisig? The purpose of a multisig is spread out your tax surface by requiring things like visits between multiple locations to sign a transaction, possibly multiple states, multiple hardware vendors. Deployed across different validator sets across the globe. That is what multis seeds are expressed. The attack surface of that enhances the security of users funds, basically, that is what multis seeds are. The problem here is the invincible complexity when signatures are needed from 12. F. Once seven signatures are needed from 12 validators across four continents and only three show up, how do you even begin to monitor for that? How do you debug that? Or do you actually need to know what validators are online? Are they receiving the transaction? Is the man filled up? Are you under attack? These are the questions you ask yourself. Is there a network of prob problem? Is there a problem within the protocol? And you do not know the answers to this question if you do not have enhanced monitoring and observability. The multisig mage just details what basically happens with within the mo. It's three out of three mode sleep between Alex, Bob, and Charlie. To get the transaction signed. We see the transaction being initialized, the hash being generated, the signature collection process, the signature aggregation process, and the signature verification process before the transaction is being executed. That's what is actually happening and for all of this to happen, we need our operators to be active. We need unload to be healthy for these to actually, so we can actually have an IMO League up time. What do we actually monitor for? Currently, we monitor for transactions such as we monitor for signature accounts, wallet balances. What is the current state of the hot wallet? What is the current state of the core wallet? But the things that remain hidden across multiple network and protocols, as have seen is we do not actually know how we can monitor for the signature collection pattern. Who signs what and when. What node has been active? What node has signed the most blocks and pushed for the most transaction? What is the network topology held? What is the cryptographic performance and what bottlenecks currently exist in the proof generation process? These are things we need to monitor for and observe. These are very key indicators here. We discussed the Anto of Refrige signature. It just shows the two steps that dance nobody sees because basically users just. They have the idea that, yes, my funds are secured and protected, and yes, that's idea, but this just, those are the technical implementation across different networks and protocols. We just have the 12 step down that entails the verification process and transaction flow within a multi sleek operation. Now we ask ourselves a question, why does observability matter in federated networks? We've, we have the issue of fragmented systems across operators where node operators are, we have the ability to run isolated node in different environments. That act of decentralization where nodes are completely isolated. We have a, when operational silence equals slow recovery time. If you do no monitor for operational excellence and operational resilience, then you'll definitely have slow recovery time. You would not be able to get your network up and running. With failures that you do not track caused by timeout or slow signers result in slow block production as a result of block chain holds. These are things you need to observe for. These are things, this is why of Ability matter because of the stability of the network. Essentially the true, a true federated of ability. Would mean it operator maintains independence while contributing to a shared availability layer. What U utility can we can be used to enhance that shared availability layer where the goal is to ensure real time insights, identifi bottlenecks, and increasing the flexability without out sacrificing the true core of decentralization. We introduced Grafana Alloy. Here as the tool you being used, tested, and proven as the documentation suggests, Grafana Alloy combines the strength of leading collectors in one place, whether observing applications, infrastructure, or boots, Grafana Alloy can collect it process and export telemetry signals to skill and future proof your observability approach. This is picked up and referenced directly from your application, be it profiling your applications or knowing. The telemetry flow within the applications. Grafana Allo is the tool for this and this. It's vendor friendly. It's it can be used as open source. It can be loaded as a side card. This is basically the approach you would want to take in run when trying to get federated of ability. How can we utilize it? Grafana alloy with its features. Here we discuss the features of Grafana Alloy, where it comes to centralized logging with low key. Metrics. Getting the metrics which permits remote ability traces with open telemetry and also inbuilt profilers. So these show us deep visibility into our systems and show the visibility into our networks and can be configured to feed our specific use cases as we do not have control of these independent and isolated operators Essentially. What is the deployment architecture? As I earlier said, as we do not have control of these independent operators, each operator is allowed to dare own our, with its own configuration, fine tuned to it, to its infrastructure, whether it Kubernetes, dock bare metal or cloud native. The operator is fine tuned to run their own particular configuration. We have centralized loss of ability. Despite the local confi, all data flow shared are good, are shared, good shared endpoint. Basically, we have a centralized look key endpoint for getting all of the, and aggregating all of the logs for Loki, getting and aggregating all of the metrics for perimeters and also temp for tracing. We utilize security and autonomy well in, we use to cognize access to the secure endpoint of getting all of the logs and metrics. For or for the, for pure visibility and autonomy into the system, what can you see and do From this? We are able to get live operational insight from knowing who is the slower sign and. It. It's detecting the internal life of each participant. Each mo, each operator in the multi end Tories show how requests propagate that cross signer highlighting performance and pointing out failures in real time. With this, we're able to monitor for failures in real time with and fine tuning the rights alert system as service level indicators. Before the problem, we had blind spots in signature collection hours of debugging. Field transaction, trying to get individual logs sent over various form. The logs and are unstructured network issues are discovered too late and malicious notes are allowed to participate in the network while being unchecked. But with this we have full visibility. We have real time insights into the. Into the system we have, we are now proactive with our issues detection. We ensure complete transaction life cycle and we ensure security all of the network. Basically. Here we discuss the key benefits delivered the operational excellence, security, trust, and the federated approach. We just highlight a few feature a few key points on all of these key benefits of. Federated approach, monitoring and getting pure visibility into your systems. Basically, I'll let us discuss with questions and possible questions that can come up when setting up these, like what are the, what are our external big validators operational pain points? What are their biggest pain points? What more monitoring gaps do we have in our network? Because the net monitoring gaps are network specific. How do we analyze the monitoring gap within us, our federated network, and how can we customize this open source approach? To our infrastructure. I'll end it here and I would leave my email attached for any more questions you might have, and I'm always happy to discuss this further. Thank you very much.