Good evening. Here is how I’m personally building with $KAS covenants on Testnet-10. Sorry for the long videos but it’s simply impossible to show the beauty of this architecture in a 30s video. *All of this is on testnet and not ready for final release. First video shows a vault being funded with a covenant-enforced delay of 30 days. Any unauthorized attempts to move $KAS other than to pre-approved addresses will trigger this delay (which more accurately is enforced by a specific future DAA score, not a set time). I then choose to cancel the withdrawal and fall back to the pre-approved recovery address. Think of it like this. An attacker gets access to your private keys and imports them into a new wallet. They try to move the coins to one of their addresses (which is not a convent-approved address), so the security delay begins. When I’m notified of this unauthorized withdrawal, I would then cancel the attacker initiated withdrawal and send the coins to my recovery address. Second video shows the same set up of a vault being funded, but with a Security Delay of 60s. I wait the full 60s and then am able to withdrawal to the “unauthorized address”. In practice this delay would be a very long time, weeks or months or years. So if the attacker imported your stolen keys, waited the full security delay, they would hypothetically be able to steal your coins. However, there are two problems. The wallet they would use wouldn’t clearly show those coins that are locked in the vault. And even if it did, they wouldn’t see a security delay in the app, the transaction would just fail (I think). Limitations: no support yet for change so all selected UTXOs are consumed by the vault, no audits, few UI bugs, unclear buttons, etc.