Institutional real-world asset platforms need security review that reflects how they will operate in practice. We worked with @ChainLabCTU (@CVUTFEL) on an institutional RWA platform for tokenised bonds supporting SME financing on EBSI.

The scope covered two Solidity codebases ogic, identity controls, custody, account abstraction, recovery, and WebAuthn validation. The engagement combined a private CODESPECT review with a SpecSiege community audit contest.

The case study explains how the two review layers supported broader coverage and helped prepare institutional RWA infrastructure for production. The link to the case study is in the reply ⏬

Eight years of work to defend against a computer that doesn’t exist yet.

NIST started standardising post-quantum algorithms in 2016. The first standards landed only in 2024.

If you verify signatures on-chain, the next step affects you directly.

A big theme of Day 1 at step: preparing Ethereum for the post-quantum era. New cryptography is being built with formal verification in mind.

The bar goes up. The risk doesn’t disappear; it moves:
→ a proof is only as good as the spec it checks against → serialisation, key handling, and client or contract integration often remain outside the proof
→ signatures get much bigger: ECDSA 65 B vs. ML-DSA 2.4 KB+ and SLH-DSA 7.8 KB+.

For contracts adopting these schemes, that changes calldata, verification, and gas costs.

Writing signature verification today? Enforce the exact encoding of every algorithm you support, but keep the interface versioned and extensible so new algorithms can be added safely.

Verified crypto plus audited integration. You need both.

Turns out we match the Devcon volunteers.

Not a bad match, actually. Same mission: getting builders where they’re going, safely. 🟣

Your job: make it work.
Ours: imagine how it could fail.
Neither is enough alone. Together, that’s purple teaming.

@EFDevcon starts today. Tell us what you’re building and we’ll swap notes on what we’ve been seeing lately.

Find us there. We’re the ones in purple. 🟣

AI agents move real liquidity in DeFi, yet nobody can tell a safe one from a reckless one.

We co-developed the @owneydotapp Trust & Security Framework for agentic DeFi. Now it’s up for a grant on @thedaofund to go open source and fully automated.

Support it here 👇
initiatives.thedao.fund/initiative/tru…

Week in review at CODESPECT

Hacks shake trust. Builders rebuild it.
This week ended with the Binance hack, the largest crypto theft on record. The whole industry held its breath. But…

At Stellar Meridian, we saw the exact opposite: a drive to build and secure. Teams pitched products for emerging markets, new wallets, improvements to Soroban and easier ways for everyday people to get into crypto. Fear won’t keep chains running, let alone help them grow.

Keep building, but build securely. That’s the idea behind our new DeFa case study: a full audit on Starknet, our AI-assisted pre-review on Stellar. Same logic, two chains, two security lenses.

Q: How do builders earn trust after a week like this?
A: An audit is a good start, not the finish line. What comes next matters too: reviewing every later change (AI can help), putting upgrades behind a timelock, and protecting the keys that control them. Most of the biggest hacks did not start in the code. They started with a signer.

Trust is not claimed. It is verified.

A new day, a new conference!
CODESPECT is heading to Mumbai for @EFDevcon8!
Meet our CEO @talfao1 and CTO @jecikpo to talk about where Ethereum is moving and what it takes to keep it secure, from Solidity and Vyper codebases to L2s and the protocols built on top of them.
If reum, come find us between talks.

Meridian is behind us. Then overnight, Binance lost ~$6.3B.

No smart contract bug. A hot wallet signed an EIP-7702 authorisation that delegated it to an attacker’s sweeper contract. Every deposit after that got drained.

Web3 security has two halves:

1. Opsec/backend: who and what can make your keys sign
2. On-chain: what your contracts let anyone do

For the second one, we built a Soroban Security Checklist for @StellarOrg builders.

Use it on contracts that are live now and on whatever you’re building next. Check the link to our website⏬

Soroban security checklist: codespect.net/checklists/sor…

AI security harness for @StellarOrg (Soroban) smart contract audits, now live.

Our first run with @defaprimitive worked. Now we want more projects to test it.

First 3 Stellar teams with ready codebase to DM us or reach @talfao1 on Telegram get a free AI review.

At Meridian in Lisbon for the next few hours. Come find us. (purple codespect shirts)

Day 1 at Meridian (@StellarOrg), Lisbon. 🇵🇹

Justin Rice put it precisely this morning: builders are the “palace builders”, the core of the whole chain. Hard to disagree. A network is only as strong as the contracts people actually deploy on it.

Today showed us that projects on everywhere right now. In a few hours, we met more new projects building on Stellar than we usually come across in a month: payments, RWA, DeFi.

Different stages, same question underneath: how do we ship this so it holds up? That’s a question we’re happy to help answer.

Looking forward to the conversations that started today. See you tomorrow.

Meridian (@StellarOrg) side events start today, so a lot of Soroban code is about to get shown off.
Quick pre-deploy check worth running before you demo:
- Privileged functions call require_auth on the right address, not just any address
- Nothing that must persist lives in temporary storage. Once its TTL runs out, it’s gone for good
- update_current_contract_wasm is behind proper access control
- Custom balance logic handles from == to without corrupting state

We’re in Lisbon all week. Happy to go deeper on any of these in person.

DeFa (@defaprimitive) brings real-world invoice financing onchain, and it builds a different product on each chain.

We reviewed both. On Starknet, a manual audit of their invoice-backed lending pools.

On Stellar, something different. Their cross-chain PayFi product was still n our in-house AI-assisted pre-review.

Not a scanner: the same offensive mindset our auditors use in manual audits and audit contests, with every result confirmed by a human. In days, it surfaced validated cross-chain integrity, facility lifecycle, and scalability bugs

Link to case study ⏬

Read how both engagements ran: codespect.net/case-studies/d…

Building on Stellar or Starknet? Get the review before mainnet, not after: codespect.net/request-assess…

Same word, different guarantee.

This week Yapeswap lost ~$21.9K. Quorum: 0. Votes for: 0.000055% of voting power. Votes against: 0. That was enough to take over the feeToSetter role and redirect pool deposits to the attacker.

Nobody attacked the quorum. Nobody ever set one.

When auditors see a quorum in code, the first question is: who set it?

In Ethereum governance contracts, quorum is a parameter. Among the first things we check: how the quorum is calculated, who can change it, and how easily someone can get the votes to meet it.

This is not just an Ethereum thing. It's a logic bug, not a language bug. A Soroban governance contract with quorum set to 0 ships the exact same bug. Quorum = 0 compiles on any chain.

Stellar adds a twist, because quorum is also at the core of its consensus. In SCP, each validator chooses which nodes it trusts, and the network stays safe as long as those trust sets overlap.

The network's quorum protects the chain. Yours protects only what you set it to.

Week in review at CODESPECT:
Different chain, same focus on security.

This week at CODESPECT was about research, not only audits and pentests. Those kept us busy too, so early in the week we published an article on the risks hiding in privileged roles.

The rest of the week belonged to a chain that is actually older than Ethereum: @StellarOrg. With Meridian coming up, where our CEO @talfao1 will be, we pulled apart some of the security components Soroban brought with it. He learns from the security mistakes of other chains. More chains should.

We respect that a lot. See you in Lisbon.

Yesterday’s bug, solved.

Bug: sending to yourself (from == to). Both balances are read upfront, so the second write uses a stale value. Balance doubles.

Fix: write from, then read to.

It was not a necessary Soroban-specific bug, but it was made on purpose. Even though Soroban it still keeps logical issues.

Spot the bug

Yesterday we said Soroban (@StellarOrg) is safe from reentrancy, and it’s true. But…

The host really does block every attempt to re-enter a contract that hasn’t finished yet, and there’s no way around it.

The core of reentrancy isn’t the callback itself, though. ate. And when the bug is in the contract’s own logic, the host can’t help you.

So is this vault safe?

Find the bug 👇 Answer tomorrow.

Some of Ethereum’s most famous bugs don’t exist by design on Soroban (@StellarOrg).

Soroban is Stellar’s smart contract platform. Its designers learned from EVM bugs and built protections into the host.
How:
→ reentrancy is blocked by the host
→ no delegatecall or selfdestruct
→ require_auth() handles signatures and replay protection
→ constructors run atomically at deploy

Still a risk:
→ Authorisation. A missing or misplaced require_auth() lets anyone act without permission.
→ Math and rounding. Rounding in the user’s favour can be exploited repeatedly, and casts silently truncate values.
→ Upgrades. update_current_contract_wasm replaces the contract’s code. The risk lies in who can trigger the upgrade and in incompatible data between versions.
New risk:
→ State archival. Every storage entry has a TTL (time to live) and gets archived or deleted unless it’s extended.

So Soroban doesn’t solve every problem. Some security risks remain; others shift to new areas. Still, it’s good to see teams building new VMs thinking about security. As a security company, we can only appreciate these efforts.

Meet our founder in Lisbon next week.