Just putting this announcement out on all our platforms, and I think we have a couple more
people that we need to get up on stage.
All right, so now some speaker invites. Let's see if they're able to get up on stage.
Sorry about that. Just waiting on a couple more people to get on stage.
All right, let's go ahead and kick things off, and I'll work on getting them on stage
in the meantime. Thanks for coming to Secret Spaces, everybody. Welcome. This is a weekly
Twitter space featuring contributors, secret network, and news from around the ecosystem.
And today we have a very exciting partner with us. We have the Hackin team. We just recently
announced a partnership with them, and they're going to be a great contribution to the secret
network ecosystem. It's going to be a great resource for developers to tap into and make
the best possible secret dap that they can. I'm sure they're going to be a huge help in
that. So let's go ahead and get them introduced if you guys want to give a brief introduction
Cool. Thanks, Patrick. It's Vladiv from Hackin partnership speaking. I'm in touch with various
people on Secret Network since early 2023. And my goal here is to find synergies and strengthen
the ecosystem, make it more reliable and overall prone for projects and retail investors
to migrate to secret network. So Hackin services and expertise is our service, and I'm excited
to be here. Thanks, Patrick. Thanks, Alex.
Awesome. It looks like we have Alex on stage now. Alex, you want to do a mic check?
Yeah, yeah, sure. So also happy to be here. Thanks, Vladiv. I actually have some history
of working with Hackin before my previous journey, so I'm really excited that we are joining
courses together also around this very important issue of privacy and confidentiality. So let's
go. Let's have this great conversation. Thank you.
Well, Alex, let's start off with you, if you don't mind, if you want to just speak to the
importance of security and secret networks ecosystem. Why is it something that developers
need to keep in mind? And maybe is it something that sometimes gets forgotten and not prioritized
Well, security is, of course, of paramount importance in all of our all of our blockchain
ecosystem, be it Ethereum, Solana, Cosmos, Secret or anything else. It may be even more
important in a way, in a confidential computing ecosystem, where not everything is
immediately visible on the blockchain or not directly visible. So in a way, there is even
more room for potential issues. So yeah, so the security is in secret is even I guess it's
even more and more important than on open blockchain ecosystem. And for us, especially now
is we are driving also towards servicing other blockchain and being this confidential
computing layer for Web3. We really need to be top notch, because we will be scrutinized
not just by our own community, which is great in building, but also by the outside
communities. And that's why it's also it's it's important for us to have tier one partners
doing doing the audits and helping us with the security for the ecosystem as a whole. So yeah,
security is important. Testing and auditing is important. And it's even more important for us
now, both because we're confidential, and also because we're going outside to the outside
world. Yeah, that's a good point. Obviously, it's important on a transparent chain as well,
you know, when you're dealing with asset security and making sure that for example,
bridges or applications that have tokens locked into a contract, you want that to be secure,
so that funds can't be stolen. But also, it kind of adds an additional layer with secret
network because we're dealing with confidential computation and potentially sensitive data being
stored in these contracts. So something that a developer on a public transparent chain might
not typically run into, but it's even more important on secret because of that.
Yeah, I think that's a great point, Patrick, and I wish I had thought about that as well. So yeah,
there is like kind of another additional dimension in confidential computing contracts,
and it's the keeping the data confidential, right? You don't have that attack factor on EDM ecosystems
or any other transparent ecosystem there. One of the only thing you care is that the contract does
what it's supposed to do and that there's no way to trick it or to steal money from it.
So with our technology, you need to care about all of that, plus about making sure that no
information is being divulged directly or indirectly. So yeah, that's a great point.
So it's even more complex, in a way, and more challenging security in the secret and
transparent networks. Yeah, and so I think, obviously, it's of huge importance to the
secret ecosystem. And if we're talking about like, sustainable growth in our ecosystem expansion,
new apps coming in, a key part of providing the tools that they need to succeed is this
security layer and hacking coming on board as a partner, offering their services to secret apps,
dedicated support. This is a big piece of the puzzle, I guess you could say,
for our sustainable growth. So definitely important for secret network as a whole.
And Vladie, maybe we can shift over to you to talk about from a bigger picture,
just like the current state of security and web3 today.
Sure, sure. So speaking of the previous topic about comparison with the more public protocols,
public blockchains, it's indeed a new answer for secrets. On one hand, privacy keeps more data
closed. So there is less chances of someone manipulating the Oracle prices or things like
that. At the same time, products like automated threat prevention and monitoring tools that are
more easily developed and deployed on public blockchains become less effective on
confidential computing protocols. That's why a bit more of responsibility lays on each project
to protect its funds, its assets, its keys and other sensitive data. So things like that, we've
basically prepared in our report that's soon to be published. And I'm feeling really honored
to present this information to you before it's available to the public eye. But more on that
later, we have a special part for our web3 security insights later on. I would like to take this
opportunity to have a brief intro to Hacken, what we do, who we are, why we're here,
and probably share some stats for those who haven't encountered us in the past,
and briefly switch to how we can enhance secret networks overall ecosystem security.
So Hacken's mission is to make web3 more secure. That's our motto. We do it by working as a service
company and all different projects, all different source code for smart contracts, for web2 components.
We also take care of penetration testing, which is an established, to say so, web2 security norm.
Basically, it's a simulation of a hacker attack in a controlled environment, really useful for
any product and interface that interacts with user funds or otherwise sensitive data.
We have a bug bounty platform, which is another layer of protection.
Eventually, it's the way to put price for any bug found by anyone. And to incentivize those people,
those really smart people, to do not take advantage of this vulnerability or otherwise issue,
but to submit this bug to a project and to get a reward for that. So it's a win-win situation.
We also, as a company, run several, I would say, pro boner projects, like
Suri.live, which is a security ranking platform for cryptocurrencies, centralized exchanges,
wallets, and decentralized apps. So our trust score is used by CoinGecko as part of their
overall rating for any centralized exchange or cryptocurrency. So we have some level of
honor and pride in being a partner for CoinGecko to basically increase awareness and provide quality
and up-to-date data. And I would say the last but not least in the tops of priority
is our industry responsibility. So we believe that web3 is going to be way more friendly
to beginners if it's really secured to attract the people. Here we're talking about things like
proof of reserves for centralized exchanges, or better UX improved to security measures for
all the wallets and stuff like that. So as a company, we're here not only to
provide services, but also to take responsibility for the industry's future.
Speaking of stats, we again cover all services and ranges for your project security.
Basically, it's review of source code of smart contract, doing penetration tests. We also do
review of web2 components, meaning like frontend, backend of the wallet, anything that interacts
with the smart contract and on-chain itself. And recently we launched the tokenomics service.
Eventually, it's a service that allows you to either audit your existing tokenomics and
compare how well they stand compared to your business objectives and aims. And we can also
design tokenomics for you, together with economic modeling, how token will behave after launch,
what other I would say conditions may come to play that may easily be foreshadowed or neglected.
So we have it covered from day one for any project, and we really push the standard of
doing regular penetration tests, do a smart contract audits every time you make any changes
or plan to release a new feature, everything to basically keep the funds as secure as possible.
We, during this like seven, eight years, we've worked with many, many companies. So we take with
pride in being trusted by secret ecosystem, as well as famous data aggregators like CoinMarketCap,
CoinGeeko, centralized exchanges like Binance, Kucoin, OKX, HDX, like previously who will be
gate.io, and various DeFi protocols like Aurora, OneInch. We also work with multiple accelerators
and incubators, whom we can easily connect with anyone working with us. So taking advantage of
our partner network from VCs to, again, accelerators, incubators, centralized exchanges, market makers,
we aim to provide even a startup project with all the needed connections that will make their growth
easier. So that's pretty much it about hacking. I don't want to spend much time
highlighting things that are available to the public, but I would be happy to share with you
some insights on what our research and development team has accumulated about a
2023 outlook later on in this AMA. Yeah, that's awesome. So you guys really provide
a pretty wide range of services. I think some people might think
hacking only provides like contract auditing, specifically like penetration testing, but
I wasn't aware that you also did tokenometry reviews and design, that's really cool.
That's another big piece of the puzzle when it comes to building a successful DAP, if you're
going to be launching a token along with it, that's an important service and something to
consider. So I think we'll definitely be connecting some secret DAPs with you guys for that.
So maybe we want to talk a little bit about the specific things that this partnership offers to
people developing on secret. We talked about all the different things that hacking provides
for the public, but this partnership comes with some perks that secret developers can
take advantage of specifically. Do you want to dive into that?
Yeah, for sure. So one of the main goals for us is to make audits more accessible,
but at the same time, audits cost money. So any auditor, especially tier one,
spends a lot of resources, money on training and hiring the best talents possible to
basically put the reputation on the project report. And one audit costs money, taking multiple audits
from several vendors, which is a really recommended way to move forward for any project, doing
regular penetration tests and also checking your front end and web two components. It costs even
more. So I get it. But at the same time, being reactive to an issue may come with higher price
than running one or two audits. So we want to incentivize you and again, take on the proactive
measure, proactive approach, and just dedicate time to proper review of all your resources,
all your systems before going to public. In web two, where there are multiple other expenses
contained and entailed with running a business, generally in web two, companies dedicate about
10% of their revenue to security measures. So it seems like a good benchmark, as for me,
but in web three, sometimes more part of the revenue should go to security. Again,
some projects that we've talked to who've been hacked in the past, they do up to
10 audits with different vendors before releasing even more features.
I'm not saying that's the only way to move forward, but it shows that projects start to
invest more in security after they get hacked. I know it's a long way to say that proactive
approach is better, but I hope it gave you some reasonable examples to do it. Hacking a
secret partner, we are happy to provide up to 20% discount on all of our services.
The amount of discount only depends on your level of urgency. So if you need an audit or
pen test within like a month or five to six weeks, we are happy to provide a bigger discount of 20%
in cases that you need to audit and to release something like really in a matter of weeks,
we're still preserving a discount, but it's going to be 10%. As for the bug bounty on our
hack and proof platform, we're also going to get much better conditions than any other project,
but these are measures for post deploy stage. On top of that, so all of our customers are
getting mentioned on our Twitter account, so you're going to have some additional problems.
For secret projects, we're also happy to connect with our partner network. As we discussed earlier,
it's things like accelerators, incubators, market makers with whom we have good conditions
and can make a warm introduction so you can spend less time on searching and getting all the
connections that you need for growth. That's very cool. I think in my personal experience,
the length of the queue for audits is sometimes it's an issue for projects because
people make a plan to release something, then in a lot of cases they think, well,
an audit will take a week. Yeah, audits do take a week, but you might need to wait for
six weeks to start the audit. I think it makes perfect sense what you mentioned about the
discount, which is larger for people who made the right planning and who are willing to wait
for quite some time. Also, the bug bounty, I think it's also a very important part of
the whole puzzle because even after audits, some things can remain undiscovered and only a bug
bounty can help really find some more intricate vulnerabilities that were not discovered in the
primary audit. I think this is a valuable thing for our developers. I want to ask,
what was Hakken's experience with the Cosmos ecosystem in general? What are maybe some of
the more interesting names that you guys were working with in this ecosystem, this part of Web3?
Thanks, Alex. So, basically Cosmos is a new thing for us, and our auditors are even developing
tools for Cosmos like test coverage analysis because we know that such tools
either developed privately or not easily accessible.
We've worked with Serenity Shield, and they are one of the example projects who
take multiple stages of smart contract audit, open in a bug bounty, even for the
test net scenarios before going to my net. Otherwise, I don't have a list like on top of my head,
but if it's something of your interest, please share your reactions and let me share this
full complete list under this tweet because I also need to check the NDA requirements for
each of the projects. Sorry for being stealthy, just being cautious.
That's exactly how a security company should be.
I also think that Alex has raised a really important point about time and expectations.
It's true that audits for simple functionality and smart contracts stay quick,
but there are also projects that take several months. These are two extremes, but what's
important to also keep in mind is that usually no company gets a 10 out of 10
from the first audit review unless they were audited before. What I mean here is that
if it's your second, third audit for the same smart contract scope, then yeah,
maybe your fifth audit is going to be 10 out of 10 straightforward.
At the same time, and it's totally fine that first audit gets not so high score. I mean,
there may not be critical issues that allow bad actors to basically squeeze your wallet,
but there may still be some vulnerability concerns. That's why most of the companies take
two rounds of audit. If it scares you, hold on, because it doesn't affect the price in most of
cases. So hacking includes two old attributes within the price. So unless the code hasn't
changed significantly and you had to rewrite your whole functionality after the first review,
which I hope you won't need to. In this case, the second review is quicker and it doesn't
entail any extra cost. But what projects usually oversee is the time that they need for
remediation. So let's give an example. A token smart contract audit would take us one week.
You're going to see a report with all the recommendations, ways to optimize
gas if possible, and all the recommendations on documentation, code style, security.
That's pretty much it. Usually projects take between one to two weeks to implement those
changes. And then there is another review. So it's better to start thinking about audit
as soon as you start developing any functionality and submit your request to us at least one and a
half or two months before you need to launch this functionality. Otherwise, there are risks of
basically either releasing and launching without not fully reviewed code,
which we strongly do not recommend, or postponing the launch of the anticipated functionality,
which can bring maybe some community sentiment, but it's better to wait for a couple of weeks
than publish post-mortem notes on the Twitter. So I hope you agree.
Yeah, yeah, absolutely. Absolutely. Well, general security is a very, very tricky stuff and it
needs to be constantly kept up in all the developments. And sometimes, you know, in a
lot of cases, people develop stuff, do an audit, and then they just continue developing
seemingly small things, which lead to potentially some catastrophic failures.
And so, I mean, I don't know what is the recommended approach, but in general,
if somebody wants to work really by the book, I guess, then any commit or any new release
needs to undergo audit. But I'm afraid a lot of projects are not doing that for various reasons.
And that probably adds more risk in a way to some of the projects that are doing that.
Like, do you have any stats on like how many people do additional development after an audit
is completed versus people who are just, you know, auditing the exact same version and
releasing the exact same version to production? Okay, that brings us to like one of the topics
of our research, which is connected to audit coverage. So we can slightly move into some
sneak peeks of our firings of hacks and otherwise lost funds that happened last year. And yeah,
Alex is right that indeed some companies change code after the audit been done or take a more
like risk-seeking approach when there is literally no audit before launching. So
in total, there were around 450 hacks and out of them, 305 had no audit at all.
This is close to 70% of all hack projects, they had no audit at all, which already
usually we find like really similar issues in most of the smart contracts if we're talking
not about the token, but like the app audit. Usually there are re-entrancy attacks.
There are like, lacks of proper audits of potential.
Sorry, a flash loan attacks, meaning that if there are several components to the system
and third parties, the more components in the system there is, the higher the chances of
like a mistake or something going out as planned. And usually like flash loan attacks,
like really popular way to manipulate any defined protocol, which isn't considered hacking.
Like it doesn't break any code. It just takes advantage of missed logic or unforeseen conditions.
So coming back to the statistics, again, more than 70% of all hack projects were not audited.
Around 15%, which is 97 projects, they had audits, but their audits have not covered the exploit scope.
What I mean here is that audits have not covered all scope and specifically part that was left out
contained an exploit and vulnerability that got manipulated. So 22 projects, which is a bit less
than 10% had irrelevant audits covering the exploit. So what it means is that there was an audit and
exploit was included into the audit scope. But then the project has updated the code,
which made the audit basically irrelevant and published it. And eventually the newly updated
code contained an exploit that wasn't foreseen up like with the previous version of the report
and found the stolen and only 23 projects out of 450 got relevant. So we see that
just 10% of all exploited smart contracts had any form of audit and only half of those projects
had relevant audit. So it's like less than 5%. What we mean here is that basically
5% of projects has code deployed on the blockchain that matched the audit report code.
So what happens when the audit fails, even if you do it correctly?
So this data was gathered by our trust army team, which is our project for do your own research
type of head state. So anyone who is connected to a retail investment is welcome to join to
run rewards and improve your security and research metrics. So what happens when the
audits fail? It's really important to talk to several auditors because any audit has a human
factor to it. And those who say that they guarantee 100% security after reviewing your code are most
probably lying. So it's generally a good approach to take several steps to secure your code.
One of them could be hiring several auditors. Another one can be both and waste one auditor
and open in a bug bounty program where you can select the rewards. And if the vulnerability
was found, you would get submitted to you privately without anyone knowing about the issue.
So that's pretty interesting metrics because again, for retail investors, they may know that
how it is important, but making sure that the audit is relevant and up to date to what's
currently deployed is usually like oversaw and people may skip this part. So with this,
we're adding to raise awareness about being relevant up to date and coloring as much scope
as possible. If it happens that you don't have enough funds to like pay for the audit,
it's always an option to open a crowd source audit or bug bounty program for a couple of days or weeks
if you're running low on cash, but you still want some sort of security review.
Well, those data points are really kind of scary. Like I wish there were some way to
know if the application I'm interacting with has gone through an audit and what's the coverage.
I don't know. Have you guys maybe thought of partnering and maybe not even just hacking,
but the industry because it needs to be a consortium of auditors, just maybe partnering
with a wallet or with, I guess, partnering with a wallet would make sense. Like you
met a mass for somebody who would, you know, when you go and interact with something,
it could show you like, okay, this contract was audited 100% and that one is just not at all
or maybe 50% audited. And I guess that would improve the situation in a way because more
people would go and do the audits because, I mean, if they don't do the audits, then
users will actually see that and be, you know, reluctant to use the products.
It's a really reasonable point. Yeah, it's a really reasonable point, Alex. So
last year we've seen a couple of like really smart plugins, like wallet guard that's counts website
for malicious elements or like code injection. This is like pretty much web two type of technology,
but focused on web three problems. There are also web three antiviruses that can protect yourself
from phishing. But speaking of audits, it's a really game of reputation and
companies like Open Zeppelin who have like really made a huge investment contribution into open source,
secure smart contracts are considered like the higher league. It's really reasonable to make
kind of data platforms, which is basically what we're doing with our CER.live, like certificate for sure.
At the same time, to unify all the security providers across the industry, it may be a tricky
question because everyone considers and sets up their own security standards so far. So one may ask
for like three audits for different security auditors to consider it is contract saved.
Some would require like 10 tests each six months for centralized exchanges or DeFi protocols. Some
would require 20 years. So I can say that it's an open debate, open question. Hacking is totally
up to creating like a unified database where a retail investor can type in their favorite project
or project that they're researching and get the full report knowing which auditor has audited which
part of any. When was it done? How relevant is it? And if there are any other potential threats.
So there is no such tool yet. At the same time, we're working on it in
various committees and organizations that shape common standards like enterprise Ethereum Allianz,
crypto volley, cryptocurrency certification consortium. These sort of companies
and to make it more accessible and quality data available for any user.
Nice. Good to hear. So hopefully the web3 world will gradually become more and more secure
as time goes. That's great. Great. And also our ecosystem, right? Because with, you know,
as those efforts progress, I don't see any reason why it shouldn't also be the same in the secret
ecosystem. I'm just validating that a contract has been audited properly. It can be done on
secret in the same way as on any other blockchain, even though the data in the contract is confidential.
So we're about 15 minutes to the top of the hour. I want to make sure we have time for
audience questions. If you don't mind, hacking team, if we want to go ahead and let people
put up their hands if they have a question, and we'll bring you on stage in just a bit.
While we're waiting on questions, I guess I have a question kind of based on
these data points that you just gave. I think you probably provided the proof in those data
points, but how would you answer this question? Because this is a sentiment that I've seen with
some developers, especially ones who may not have a lot of funds to put towards audits.
They may say something like, audits do not prevent hacks, you know, just because you're audited
doesn't mean the hacks not going to happen. So why get audited in the first place?
It's just a waste of money. How would you respond to that?
I would say there is a grain of truth in this. So indeed, as anything connected to a human factor,
all auditors who are human beings by default, they may miss issues. So it's really important
to look at the quality audit providers and how they can mitigate that. So for example,
having multiple stages of peer review, among other auditors of your work, working in
Duo or Trio would decrease the chances of any issue being missed. It's also important to take
advantage of automated tool scan, which can be static analyzers, but also more exotic technologies
like fast testing, FUZZ. Usually such tools are quite resource-intensive, and auditors utilize
them for protocol audits. But in Hacknd, we do it for smart contract audits as well.
So things like that, like multiple stages of review decrease the chances. But again,
they're not going to zero, and I get it. That's why it's a really common standard to use
several auditors who can review the same scope. But at the same time, it just increases the cost
of the audit. And if the project is running low money or in like super bootstrapped code,
there are still ways to tackle it. So I would consider using monitoring tools.
I mentioned it before that for a secret network, it's going to be a little bit more nuanced,
because not all data is available for monitoring to prevent an attack. But for
like going EVM chains, and I know secret has plans to
like mutually integrate into EVM, it's going to be possible. So again, we've said
taking several audits, if it's possible, using monitoring tools to prevent threats
and malicious attacks, but also opening a bug bounty. It's usually overlooked how
great third party bug bounty platforms are. So it's usually like third party bug bounty
platforms have three times higher submissions than self hosted bug bounties.
Also, the reward size is a factor. But trust me that having a bug bounty platform open is better
for you, because any project that exists on the market is a walking bug bounty. It's
just the question how this bug is going to be used, is it going to be submitted to you,
or being manipulated and taken advantage of by a bad actor. So having a bug bounty is a good step.
And if for now, it's impossible to afford and hold it from a credit or credible auditor,
I would consider opening a bug bounty and see if you have any submissions. So crowd source power.
Agreed. Much better to get ahead of it and put out a bug bounty and let people apply
report directly to you instead of going public with whatever they find.
Or seeing the money and going private.
I also have a quick question about your technology. So you mentioned using different kind of tools
for audit. How much is AI being used for audit? Are you guys
using somebody else's models, developing your own models, using chat GPT?
Because I heard of developers literally pasting their smart contracts and chat GPT and saying
find a vulnerability and having fun with whatever is wrong. So is it like a real thing in the audit
industry? And if yes, maybe you can share some thoughts about this with us.
Yes, we are super pro AI. We believe that AI can't take your position, but those people who
and teams who use AI tools to some extent will get their job done quicker than those teams that
don't. So this said, at this point of time, chat GPT model version 4 or 4.5 or any other AI models
our research and development team has tested was quite superficial. So the technologies are getting
more complex. And maybe in a year from now, there are going to be tools that will do it much better.
But the thing is that at this point in time, it's not there yet. And AI tool will not bear
any responsibility for any potential losses that happened due to its analysis.
What I want to add here is that working with a great experience team like in PR agency or having
has our own incident response team, this year 275 million, pardon, 400 million of assets was
returned through recovery efforts, which means a proper incident response strategy
has brought up to somewhere around 25% of all assets that have been lost last year,
which is around $2 billion. So we use AI tools by ourselves. For now, they
go as like really good helpers, but they will not like at this point in time, they're not close
enough to like a human review. But we'll see, we'll see where it goes. For now, our team doesn't rely
on AI tools. Awesome. Thanks for sharing. It's really fascinating to see how, you know,
how AI can really help in a meaningful way. Yeah, because there's also a lot of hype
around this, which is yeah, apparently not, not so fast, right? Not so fast. Cool. Thank you.
I have a question about, so you mentioned that, that people submit some projects will submit new
code and not get it audited. But then there's the the value of agile development where you
publish code frequently. I'm just wondering if you have any program that does monitoring of new
new PRs, new published code on an ongoing basis. So like checking it every day or checking every
week or checking it whenever anything is published. Do you have any system like that, that people
can buy? Thanks, Lisa. Could you also define what do you mean by checking? I mean, doing an audit on
new code that has been published. So if it's going to be an automated tool is going to bring us to
some like really smart general art, general artificial intelligence that would replace the
auditor. So we don't rely on tools like that, or don't trust all of the review to just one tool.
If there is a need for CI, CD and agile development, in some cases, when there is like a
pretty big scope, or we have a contract with a customer for like a year or two,
we can integrate into the just be an internal security team that just happen to be third party.
What I mean here is, for example, the protocol is building their new versions and they release
the updates like every month. In this case, we dedicate a team that focuses solely on this
project. They don't need to onboard as it's like a blank new state for any piece of scope.
And this way it's going to save a lot of time on reviews and also will make the remediation
process, which is process where tech team fixes the vulnerabilities much quicker because we exist
in the same communication space. There is a direct access between tech team of the project and the
auditors. But all of this is like ways to make the continuous integration smoother.
It's very much advised to audit any code that's being updated, even if it seems that it doesn't
change much. Really smart people can find ways to manipulate like even smallest changes of code.
So I hope this answers the question.
I think we have one more question as well from squirrels.
Hey, guys, can you hear me? Okay. Yep.
Nice. Okay. I had some problems on the on the PC before, so hopefully it's working
fine. Hey, buddy. How are you doing? Fantastic. Good to hear you again, man.
Yeah, mate. I hope you had a great year. Okay. So my question is related to your hack and merge.
So this is where you are taking the high token, HAI token. You're turning 10% of the supply into
10% equity and hacking group with a huge token burn as well. So that's super interesting,
number one. I wanted to ask you where the hackers stand on enhanced security for
real assets and tokenized securities. Obviously, people have to submit KYC when they buy those
things. So it can directly link your on and off chain data. Have you seen any innovative
on chain KYC solutions that protect privacy? And, you know, do you see any use cases for
secret network there as well?
So once again, the question is, what different security protocols should be implemented for
LWA? Yes, exactly. Yes. So LWA, like real boat asset tokenization, is indeed on rise the last
couple of years. We've seen a lot of examples in the NFT boom of 2021. But
right now we see like totally legit and working products that tokenize real estate,
fine art and even shares like we did for hack and where 10% of hacking shares are
dedicated to holders of our community through our token. So here it's a little bit of like a wild
west yet, even though there are billions invested in our W eight, there are little,
I would say, standards that are mutually agreeable among everyone. And
recently hacking has joined ERC 3463 consortium. Basically, it's the association for real world
asset tokenization and pushing the standard for permission tokens. It gets already audited by us
and one other auditor and is currently used by like, really huge companies, like web to companies
like Fujitsu, who made Fuji and several pretty big ecosystems in the electric space as well. So
our W a products and smart contracts should be agree upgradeable. And as accessible to
implementation and integration to protocols as possible, and specifically focused on securities,
because defy is seem to be just the main driving factor behind web to crowd
tackling and joining web tree. So usually what they look for are securities and other financial
instruments. But yeah, our W a goes well beyond the finances world itself. Again,
it can be used in B2C products for loyalty programs and many other forms. So for now,
there is no right answer to that. But by shaping the standards in this association, we hope to bring
everyone on the same table and to agree on what seems to be like a really promising vertical of
that three. Nice, thank you for your answer. I'd never I'd not heard of ERC 3643 yet,
but it seems like something that could use a sniff equivalent on secret network. So
I think we're going to need to wrap this up. We're at the top of the hour. Thanks for the questions.
Hacken, thanks for being here with us today. We really appreciate your time.
I wanted to make sure before we close this out that we make it clear how apps developing on
secret can benefit from this partnership. How can they apply and make sure that they're
recognized as a secret application and take advantage of these benefits that this partnership
is providing. So I think there's two main ways that they can do this. One is to just go to the
hackin website hackin.io and simply at the top right, there's a button where you can request a quote.
And if you do that, and you just mentioned in the notes that you are working with secret
networks, you're building on secret network, then hacking will recognize that and offer you
those benefits. Is that right buddy? Yes, exactly. The other way is to also contact just me directly
or send the DM to Patrick and we're going to take it from there. So whatever is convenient for you,
but just to make sure that you're going to get all the benefits and special treatment
that you deserve from hackin, please include that you're coming from secret network so our team can
basically approach it the appropriate way. That's just a reminder to keep things structured.
Yep, so either through the hackin website or just get in touch with one of us
and we'll make sure that we put you in touch with hackin personally.
Awesome. Well, thanks for being here, everybody. Thanks for sticking around for the full thing.
Hackin, thanks for your time. We're looking forward to sending some secret projects your
way and working with you guys more in the future. We really appreciate what you're providing to our
ecosystem. Pleasure is ours and it's great to connect with projects like yourself.
Secret Networks Code got really high appraisal from our VPO product who is
tackling all of the software products that we have internally and externally.
We really believe in the power of privacy and you do it the right way. So pleasure is ours.
Let's rock it in 2024 and hope to connect with you later.
Let's do it. All right. Have a good week, everybody. We'll be back next week at
the same time Tuesday at 5pm UTC for Secret Spaces. Have a good one.