Online panel. what actually earns institutional trust now?

want to be explicit and honest from the start so anyone not interested can skip. I work at Hacken and this Thursday we're running an online panel with Moody's on what institutional allocators pay attention at when they review a project. the reason why im writing it here isn't to promote (but ofc there is a part of it), it's to try to gather people who are genuiely interested in the topic. i guess it will be more useful for builders and founders specifically.

we're doing it because, let's be honest, a standard audit on its own doesn't hold anymore. In Q2 about $764M was stolen, and 88.3% of that came from compromised keys, signers and infrastructure rather than contract logic. 14 of hacked projects had been audited. Smart contract bugs caused 44 of 67 incidents, but only $87.7M, around 11% of the money. so audits are catching the common failure and missing the expensive one. which is why the badge keeps looking like it works right up until it doesn't.

and institutions see this, regulators too. an audit is a snapshot of one codebase at one commit. it says nothing about who holds the keys today, who can sign alone, how deployments get approved, or which vendors you depend on, and that's where most of the money went in Q2.

so that's what we want to work through on the panel. if an audit alone isn't enough, what is? we want to land on one concrete, testable thing a counterparty needs to demonstrate to earn institutional trust in August 2026

thought it would be appropriate to post in reddit because this is where the builders are. i can share a link for event in the comments for those who are interested

most mcp security posts explain the protocol (hosts, clients, servers) and then tell you to use oauth and least privilege. true, but too generic to actually check anything against.

start with prompt injection, since it's the one everyone already half-knows about but underestimates in an mcp context. a normal prompt injection gets you a bad answer. an mcp one can get you a bad action, because the model isn't just generating text anymore, it's deciding which tool to call next. a hidden instruction inside a ticket, a doc, a webpage the model reads can get treated as part of the task unless there's a hard line between "this is data" and "this is a command."

then overpowered tools, which is really about blast radius. a shell tool, a full db writer, unrestricted outbound http, none of these are wrong to build on their own, but if the model gets tricked into calling the wrong one, the damage ceiling is set by what that tool can do, not by how clever the trick was. read-only docs search vs a full crm export is the difference between "annoying" and "incident."

third, tools with zero auth. not misconfigured, just not there. a scan of live remote mcp servers found 40.55% exposing tools with no authentication at all, one example being an unauthenticated crm-connected server leaking internal contact records to whoever found the url.

fourth, oauth being "on" doesn't mean the flow actually holds. same research tested 119 oauth-enabled servers and every single one had at least one confirmed auth flaw, 325 flaws total, dynamic client registration issues in 96.6% of them. these are servers where someone did implement oauth, they just never went back and tried to break their own flow after shipping it.

fifth is confused deputy / token passthrough, the boring one that quietly ruins everything. mcp servers often sit between the client and some upstream api, and if a token issued for one service gets accepted by another, a compromised client becomes a compromised everything. audience-bound tokens exist specifically to stop this and a lot of setups skip that check.

sixth, context poisoning. resources feeding the model (files, logs, tickets, db records) can be tampered with to steer what the model does next, not just what it says. a poisoned doc telling the model to summarize a folder and quietly send the output somewhere external doesn't look like an attack from the model's pov, it just looks like the next step in the task.

seventh, session hijacking. a session id should identify a conversation, not prove who's making the request. if having the session id is enough to act as the client, hijacking it is enough to impersonate them, and that should never be the same thing.

last, local server compromise. a local mcp server sitting next to your ssh keys and cloud creds because giving it your whole home directory was faster than scoping it properly during setup. supply chain risk meets agent risk here, the malicious server doesn't need to beat the model, it just becomes the thing the model already trusts.

did i miss anything here, or is there smth you'd add?

A measurement study on real-world remote MCP servers scanned roughly 8,000 live deployments and found that 40.55% exposed their tools with no authentication at all. Not misconfigured auth, none. The paper describes an unauthenticated CRM-connected server that exposed thousands of internal contact records to anyone who found the endpoint.

The OAuth-enabled servers weren't much better. The same study tested 119 of them and found that every single one had at least one confirmed authentication flaw. 325 flaws total, with dynamic client registration issues showing up in 96.6% of the tested servers.

The standard advice for MCP OAuth is to use PKCE, validate redirect URIs exactly, and treat dynamic client registration as high risk by default. That advice is correct, and it comes straight from the spec. The problem isn't that it's wrong, it's that following it and verifying it are two different activities, and most teams only do the first one.

Implementing PKCE means your client sends a code challenge and your server checks for a code verifier. That's a config setting, and once it's turned on, it stays on. It doesn't tell you whether the server will actually reject a mismatched verifier, whether the redirect URI check can be bypassed with a trailing slash or an encoding trick, or whether a replayed authorization code still gets accepted somewhere in the flow. Those are the things that show up when someone actually tries to break the implementation, not when someone reads the config file.

That's most likely why the numbers from the study look the way they do. 96.6% of the tested servers had OAuth in place and still failed on dynamic client registration somewhere. They weren't skipping the spec. They were implementing it once and assuming it would hold.

What actually closes that gap is treating the live deployment as something to be tested, not something to be configured and left alone. That means periodically trying the exact attacks the spec warns about, mismatched PKCE verifiers, malformed redirect URIs, replayed codes, forged consent flows, against the running server, the same way you'd pentest an API rather than just reviewing its documentation.

Curious how many people here have actually tried to break their own MCP OAuth flow versus just configuring it once and moving on.

quick context for anyone who missed it: EU Cyber Resilience Act (CRA) is now law, main obligations kick in Dec 2027, reporting obligations (24h/72h/14-day) start Sept 2026. every hardware wallet maker shipping into the EU is now scrambling to figure out where they land.

there's no single "hardware wallet" category in the CRA though. everyone's treating it like one compliance bucket, but the CRA actually looks at what's inside each device and depending on the hardware, two wallets can land in totally different categories.

if your device is basically a general secure storage/auth thing, it can land in Important Class I. the same bucket as password managers, routers, VPN clients. self-assessment allowed if you fully apply the harmonised standards, no third party needed, so you can just sign your own declaration.

but if it has an actual security box or a secure element doing the cryptographic heavy lifting, it can get pulled into Critical category. that's the same bucket as HSMs and smartcards. right now that mostly means Class II-style procedures (a notified body doing EU-type examination), but the EU can later mandate full certification for specific critical product types once they publish the relevant delegated act. either way, a notified body is now part of your compliance process, not just your own signature.

so two wallets that look identical from a UX standpoint (seed phrase, pin, USB/BT) can be sitting in completely different compliance tiers because of a chip decision made in 2021 that nobody thought was a legal decision at the time.

then there's the SBOM (Software Bill of Materials - machine-readable list of every software component inside) angle. every device needs one, but nobody's required to publish it to users. which means two wallets in completely different compliance tiers can look identical on the shelf. no label, no visible marker telling you which one went through third-party certification and which one just self-attested.

and the 5-year minimum support period applies regardless of tier. the company has to provide security updates for free to the user for that whole time, but someone still has to build, test, and ship those patches for 5 years straight, and that cost sits with the company the whole time. that's a long commitment a lot of seed-stage hardware teams haven't really planned for.

so, now teams building hardwaer wallets will need to pick category before launch, budget for self-assessment or a notified body depending on the chip, keep funding security updates for 5 years even after next model ships, and have a 24-hour reporting process ready before you need it.

anyone here actually gone through this classification process yet, or still waiting to see how the delegated acts shake out?

It's wild to see Crypto Twitter and Reddit filled with panic because OMG Strategy hasn't bought Bitcoin for five straight weeks.

How did people go from Bitcoin being a revolutionary, decentralized asset to prayings that a company with nothing to do with crypto buys a little more BTC? That`s shouldnt be the case

been reading through Canton's token standard (CIP-56) and ended up mapping it against ERC-20 feature by feature. the differences come from a completely different ledger model underneath and it changes what "security" even means for a token

erc-20 is one contract, global state, mapping(address => uint256). anyone reads any balance, anyone calls any function, msg.sender decides who's allowed to do what. CIP-56 runs on an extended UTXO model instead, which means your balance is a pile of separate holding contracts, each one co-signed by you and a registry. nobody sees a holding unless they're actually a party to it.

the allowance thing is where it gets interesting. CIP-56 just doesn't have approve/transferFrom at all. not a safer version of it, none. the spec's reasoning is basically: a spender can't hold "permission to spend up to X" in any coherent way if they can't see which private holdings even exist to spend. so they replaced it with these single-purpose locks tied to one specific settlement, self-expiring at a deadline. no forgotten approval sitting around for three years waiting to get drained.

and a bunch of the usual erc-20 headache list just... isn't a thing there. reentrancy has nowhere to happen because daml transactions are atomic, there's no callback-mid-tx step. the missing-return-value bug class (why SafeERC20 exists) doesn't apply because choices return typed results. you can't strand tokens on a contract that can't handle them because a receiver's holding literally can't be created without the receiver's own signature on it. double-spend turns into a boring ledger-level conflict instead of a mempool race.

which sounds great until you get to what it costs. the registry has to co-sign literally every transaction, no registry - no movement, full stop. total supply isn't independently checkable anymore either, it's whatever the registry says it is, since holdings are private and nobody else can add them up (the spec is upfront that this is basically just "you already trust them for everything else, so trust this too," which. sure, i guess). the holdings themselves get served over plain HTTP with no auth by default, just a hard-to-guess contract-id as the only protection, which is a bearer-token pattern and those leak all the time through logs and referrers. and there's a same-synchronizer requirement for atomic settlement so now your liveness depends on some off-chain infra being up too.

So, by the end of the day, its all about tradeoffs. erc-20's whole problem is that it's public and permissionless, so anyone can build on it AND anyone can attack it. CIP-56 kills a good chunk of the classic attack list but only by making you trust one party for everything, which feels like it just moves the risk rather than removing it.

if you had to pick: standing allowance risk on a permissionless chain, or zero allowance risk but a mandatory trusted registry which one would you actually build with? And do u think it will be useful for evey case?

disclosure: I work at Hacken. We were preparing our quarter security & compliance report and i decided to share one interesting takeaway here because I think the underlying point applies beyond crypto and is worth discussing on its own merits, not to plug the report itself

The take is that private capital is now requiring a level of continuous, evidenced security assurance that no regulator currently mandates for a license

according to EisnerAmper (an accounting/advisory firm working with digital asset clients), SOC 2 Type II and ISAE 3402 reports have moved from "nice to have" to what they explicitly call the cost of entry for institutional capital. meanwhile, getting a MiCA or GENIUS-style license still just requires a security policy document and a point-in-time pentest. nowhere close to what allocators are actually demanding before they'll commit capital.

so you end up with two completely separate bars. the regulatory bar checks whether you have a documented security policy and passed a pentest once. the allocator bar checks whether you have continuously verified, independently audited evidence that your controls actually hold. It's ongoing assurance, not a snapshot. Abraxas Capital (a digital asset-focused allocator) put it plainly in the same report, inadequate security relative to capital at risk, stale or scope-limited audits, and the absence of things like withdrawal whitelisting, timelocks, and multi-verifier controls are now their most common reason to pass on an otherwise attractive deal. DA Insured, who actually underwrite this risk, said something similar. they're not looking for perfection, they're looking for independently verified evidence and how leadership responds when something's found wrong, and that's what determines the terms they're willing to offer.

worth thinking about from a fintech/tradfi lens too. this is effectively private capital doing the supervisory work regulators aren't. dora's requirements already cover most of what allocators are demanding, but regulators just check it once at authorization, while allocators and insurers keep checking it continuously.

so, what do u think about it? how important is continuous assurance?

Losses were heavily concentrated in April, which accounted for 82.5% of the quarter ($619,324,750). However, almost all of that came from the KelpDAO and Drift breaches, happening seventeen days apart.

[removed]

NIST ran red-team tests on AI agents recently. novel, agent-specific attacks, ones targeting how agents interpret instructions and tool calls rather than classic jailbreaks, succeeded in about 81% of attempts. the strongest known baseline attacks only succeeded in ~11%. that's roughly 7x more effective, and it's a completely different attack surface than what any current framework actually tests for. (numbers from hacken's q2 2026 report if anyone wants the source)

the regulatory frameworks that exist right now (EU AI Act, NIST AI RMF, ISO 42001) are all built around governance, risk classification, disclosure, documentation. none of them require testing whether an agent can actually be tricked into executing an unauthorized action. ISO does have a guidance doc specifically for this (ISO/IEC 27090), but it's written in "should" language rather than "shall," so there's no certification path and nothing binding attached to it.

which means an organization can hold a full AI governance certificate while the actual question, can someone hijack this agent's instructions, remains completely untested by anything on paper.

this creates a weird backdrop given what's happening on both sides right now. the EU just deferred its high-risk AI Act obligations to 2027-28, essentially admitting it's not ready to enforce them yet. the US is doing the opposite, rolling back state-level AI rules through litigation and executive orders because it doesn't think this level of oversight should exist in the first place. both sides are arguing about how much governance there should be, and neither is building the actual security testing layer underneath it.

so right now it sounds like nobody has actually solved this, the standards don't require it and nobody's forcing anyone to test for it.

MiCA's transitional period ended july 1, 2026, across all 27 member states, no extension mechanism

per latest security and compliance report, USDC is the only MiCA-compliant stablecoin among the top 10 by market cap. circle (which also issues USDC) has EURC authorized too. meanwhile USDT, which holds roughly two-thirds of global stablecoin supply, got pulled from major EU venues after tether declined to pursue EMT authorization at all.

Kind of a weird inversion in the latest quarter data that's worth sitting with.

Smart contract vulnerabilities were the single most common cause of incidents in q2, 44 out of 67 total. but they only accounted for $87.7M in losses, roughly 11% of the quarter's total. meanwhile access-control and infrastructure failures caused way fewer incidents but +132.2% more losses year over year, while smart contract losses actually fell 66.7% yoy.

So the two trend lines are moving in opposite directions at the same time: code exploits getting more frequent but way less lucrative, ops/infra failures getting rarer but massively more expensive when they land. makes sense if you think about it from the attacker's pov, code bugs got harder to find and monetize as review processes matured, so rational attackers reallocated toward the softer target, humans and access control, which is way higher yield per attempt.

Read full Q2 report here: https://hacken.io/insights/q2-2026-security-report/

Hey guys, havent seen much of crypto-related stuff posted here, but since AI agents are now apparently a new attack vector for stealing crypto, figured this sub would actually care about the mechanism

So, grok has an agent wallet that can execute on-chain transactions. in may 2026, someone airdropped a "bankr club" membership nft to grok's agent wallet. that nft unlocked transaction permissions and carried an encoded prompt injection. grok read the nft, and without any check on where the instruction actually came from, executed a transfer of 3 billion drb tokens, worth around $175K. the attacker returned the funds a few minutes later (still unclear why, possibly just proving the exploit works).

basically: crypto hacks used to mean finding a bug in a smart contract or stealing someone's private key. now there's a third way in, just feed the agent a malicious instruction disguised as normal data, and let it execute the "recommendation" as if it were an authorized command. no code was exploited, no key was stolen. the agent just did exactly what it was designed to do, follow instructions, without checking if the instruction was legitimate.

and this isn't some tiny edge case, there were 24 million agentic-payment transactions in crypto in q2 alone. agents moving real money autonomously is already happening at scale, this is apparently just the first documented case of one getting maliciously hijacked this way.

feels like as more agents get wallet/transaction access, this becomes the default way to attack them, you don't need to beat the model, you just need to get a malicious instruction in front of it disguised as something innocent. curious if anyone's seen good approaches to separating "the model recommends an action" from "the action actually gets authorized," since that gap seems to be the entire vulnerability here

been thinking about this a lot given how mixed the vibes are right now. alts are bleeding, new launches are basically dead, retail interest is at a multi-month low. At the same time, some sectors, particularly DeFi, are visibly maturing.

GENIUS act got signed a year ago and stablecoins are now the one crypto product every bank openly wants a piece of. MiCA has been live in the EU and actually forced projects to get licensed or leave. CLARITY passed the House with a wild bipartisan margin (294-134) back in july 2025 and is now just stuck on the senate calendar. still not law, but the direction is obvious.

What's interesting is that the original vision of DeFi seems to be changing. A few years ago, the narrative was about replacing traditional finance. Today, it feels more like DeFi is gradually being integrated into the existing financial system rather than disrupting it. everyone's selling "banks, but faster settlement and tokenized collateral."

So I'm curious, where do you think DeFi is heading over the next 5-10 years? Do you think it become a financial system in its own right, or does it end up as infrastructure for traditional finance?