hi
Dedaub Security Suite Updates Q4-24
FREE MONITORING for all!
The Dedaub Security Suite continues to evolve with features designed to simplify blockchain transaction monitoring and security analysis. These new capabilities address Web3 challenges and empower developers, security professionals, and organizations to work more effectively. Here’s an overview of what’s new.
Blockchain Transaction Monitoring Available to Free-Tier Users
We are excited to offer all registered users free access to Blockchain Transaction Monitoring queries.
With our free plan, users can set up monitoring bots or queries to track on-chain activities and trigger custom actions through webhooks. These tools allow users to flag unusual transactions or stay alert to specific on-chain events, empowering them to maintain vigilant oversight of their projects. Blockchain transaction monitoring is essential for this oversight.
(For the free tier of the application, there are limits in how many queries can be running simultaneously, or generating alerts.)
Multi-Chain Monitoring Agents
Monitoring agents are now network-agnostic, meaning they can track activities across multiple blockchains, like Ethereum and other EVM-compatible networks. Blockchain transaction monitoring across these networks is now more efficient.
For example, a DeFi project that runs on Ethereum and Binance can now monitor high-value token transfers and detect suspicious behavior on both networks simultaneously. Updated macros make configuring these cross-chain queries easy, ensuring seamless and efficient monitoring.
Public Function-Based Similarity
Identifying patterns across contracts is now more straightforward. The Public Function-Based Similarity feature allows users to find contracts with similar functions to their target contract. This feature uses large language models (LLMs) to detect similarities.
Enhanced Monitoring Editor
The updated monitoring editor simplifies the query writing process, making it faster and more intuitive. The query language server now offers real-time suggestions, including table and macro names, helping users quickly identify the correct syntax and options for their monitoring requirements. Additionally, the revamped error reporting system accurately identifies issues in queries, such as undefined variables or incorrect filters, and provides actionable feedback to help users resolve these issues. This is especially useful for blockchain transaction monitoring queries.
Monitoring Star Rating System
The Monitoring Star Rating System within the Dedaub Security Suite allows users to quickly provide feedback on monitoring queries. Using this star rating system to share their experiences, users contribute to a valuable library of insights that assist others in finding the right tools to meet their needs. This approach ensures the platform stays focused on practical, real-world use cases.
Blockchain Transaction Monitoring Folders for Organization
The new monitoring folders feature allows users to systematically organize queries systematically, ensuring better clarity and accessibility within the Dedaub Security Suite. Users can navigate their query library quickly and maintain a cleaner workspace by categorizing queries into dedicated folders for better blockchain transaction monitoring.
Advanced RPC Fetch Functions
The latest Dedaub Security Suite introduces advanced monitoring capabilities that support external REST API requests. Five new functions allow users to incorporate data from external sources directly into their monitoring queries. The system supports HTTP GET, POST, and PUT requests.
Results from the requests can be joined against results from other tables.
In total, there are 5 new functions:
- http_get() for all GET requests
- http_get_json() for GET requests that return json strings
- http_get_json_array() for GET requests that return json arrays
- http_post() for POST requests
- http_put() for PUT requests
Cross-Chain Contract Lists
With the new cross-chain contract lists feature, users can manage contract data spanning multiple blockchain networks in one unified list. For instance, users can create a single list to monitor contracts deployed on Ethereum and other EVM-compatible networks. This helps streamline blockchain transaction monitoring across networks.
Annotate and Share Transaction Traces
Transaction traces now support annotations, making it easier to interpret complex data. Users can add custom highlights and aliases to addresses and share these annotated traces with their team for collaborative analysis.
Blockchain Monitoring + contract lists = ♥️
Users can now incorporate contract lists into their monitoring query.
Improved Gnosis Proxy Support
We’ve added better support for Gnosis proxies to our Security Suite! You can now interact with the proxy using the underlying implementation ABI.
Advanced Code View
Play around with our new advanced code view in the decompiler and projects! The new code view allows multiple code representations to open concurrently in a split panel, with the ability to synchronize the two in some cases.
Dedaub at DeFi Security Summit 2024
Dedaub is proud to sponsor the DeFi Security Summit (DSS) 2024, which will be held from November 7th to 9th in Bangkok. The summit aims to enhance the security of smart contracts in decentralized finance. This sponsorship reflects our commitment to bolstering Web3 by elevating blockchain security standards and promoting collaboration within the ecosystem.
In the 2024 edition, we’re contributing to two key sessions:
1. SEAL Panel: “Safer Development: Don’t Get Rekt”
This panel will cover best practices for secure development, with insights from top security leaders. Gain practical strategies to avoid common pitfalls in smart contract development.
2. “Smart Contracts to Embeddings: Using Off-the-Shelf LLMs for Fun and Profit”
Dedaub will demonstrate how Large Language Models (LLMs) can improve smart contract analysis, providing developers with new tools to understand and enhance contract security.
DSS 2024 | About DeFi Security Summit
The DeFi Security Summit (DSS) is an annual, marketing-free event dedicated to advancing the security of decentralized finance (DeFi) applications and blockchain-based technology. Inspired by renowned security conferences like CCC and Defcon, DSS is a platform for white-hat hackers, protocol builders, security researchers, and tool providers to collaborate and share insights. The summit focuses on education, technical advancements, and best practices to secure blockchain applications’ on-chain and off-chain components. DSS 2024 will be the third edition, building on the success of previous years. For more info, visit https://defisecuritysummit.org/.
About Dedaub
Dedaub is a pioneer in Smart Contract security technology and auditing. We blend cutting-edge program analysis with real-world white-hat hacking. As a founding collaborator of the SEAL 911 initiative, we contribute to emergency response frameworks within the blockchain ecosystem. Trusted by leading protocols, Dedaub is the security partner for Oasis Protocol Sapphire and collaborates with the Chainlink BUILD program. Our role on the ZKSync Security Council and as a security advisor to Arbitrum DAO emphasizes our commitment to safeguarding major Web3 projects.
Transient Storage in the wild: An impact study on EIP-1153
With the recent introduction of transient storage in Ethereum, the landscape of state management within the Ethereum Virtual Machine (EVM) has evolved once again. This latest development has prompted us at Dedaub to take a fresh look at how data is stored and accessed in the EVM ecosystem, as well as analyze how the new transient storage is used in real-world applications.
It’s important to note that even though transient storage has properly been integrated into the EVM, the transient modifier is still not yet available in Solidity. Therefore, all usage of transient storage is directly from the TSTORE and TLOAD opcodes using inline assembly, meaning usage is not that widespread yet, and could also be at a higher risk of vulnerability.
📢 Actually as of 9th October 2024, with the introduction of solc 0.8.28, Transient storage is fully supported! This does not invalidate any of the content in this article, but please consider this article was written at Ethereum Block Number 20129223.
In this comprehensive blog post, we will explore the strengths and limitations of each storage type. We will discuss all their appropriate use cases, and examine how the introduction of transient storage fits into the broader ecosystem of EVM data management. If you do not need a refresher of how the EVM manages state, feel free to skip to the EIP-1153 impact analysis section.
EIP-1153 | Quick refresher of data storage and access
Storage
Storage in Ethereum refers to the persistent storage a contract holds. This storage is split into 32 byte slots, with each slot having its own address ranging from 0 to 2256 – 1. In total, that means a contract could store potentially up to 2261 bytes.
Of course, the EVM doesn’t track all of the bytes simultaneously. Instead, it’s treated more like a map—if a specific storage slot needs to be used, it’s loaded similar to a map, where the key is its index and the value is the 32-bytes that are being stored or accessed.
Starting with slot 0, (Solidity) will try to store static size values as compactly as possible, only moving to the next slot when the value cannot fit into the remaining space. Structs and fixed size arrays will also always start on a new slot and any following items will also start a new slot, but their values are still tightly packed.
Here are the rules as stated by the Solidity docs:
- The first item in a storage slot is stored lower-order aligned, meaning the data is stored in big endian form.
- Value types use only as many bytes as are necessary to store them.
- If a value type does not fit the remaining part of a storage slot, it will be stored in the next storage slot.
- Structs and array data always start a new slot and their items are packed tightly according to these rules.
- Items following struct or array data always start a new storage slot.
However, for mappings and dynamically size arrays, there’s no guarantee on how much space they will take up, so they cannot be stored with the rest of the fixed size values.
For dynamic arrays, the slot they would have taken up is replaced by the length of the array. Then, the rest of the array is stored like a fixed size array starting from the slot keccak256(s), where s is the original slot the array would have taken up. Dynamic arrays of arrays recursively follow this pattern, meaning an arr[0][0] would be located at keccak256(keccak256(s)), and where s is the slot the original array is stored at.
For maps, the slot remains 0, and every key-value pair is stored at keccak256(pad(key) . s), where s is the original data slot of the mapping, .is concatenation, and the key is padded to 32 bytes if it’s a value type but not if it’s a string and byte array. This address stores the value for the corresponding key, following the same rules for other storage types.
As an example, let’s look at a sample contract Storage.sol and view its storage:
contract Storage {
struct SomeData {
uint128 x;
uint128 y;
bytes z;
}
bool[8] flags;
uint160 time;
string title;
SomeData data;
mapping(address => uint256) balances;
mapping(address => SomeData) userDatas;
// ...
}
The command forge inspect Storage storage --pretty from foundry can be used to view the internal layout:
| Name | Type | Slot | Offset | Bytes | Contract |
|-----------|---------------------------------------------|------|--------|-------|-------------------------|
| flags | bool[8] | 0 | 0 | 32 | src/Storage.sol:Storage |
| time | uint160 | 1 | 0 | 20 | src/Storage.sol:Storage |
| title | string | 2 | 0 | 32 | src/Storage.sol:Storage |
| data | struct Storage.SomeData | 3 | 0 | 64 | src/Storage.sol:Storage |
| balances | mapping(address => uint256) | 5 | 0 | 32 | src/Storage.sol:Storage |
| userDatas | mapping(address => struct Storage.SomeData) | 6 | 0 | 32 | src/Storage.sol:Storage |
All the defined values are stored starting from slot 0 in the order they are defined.
- First, the
flagsarray takes up the entire first slot. Eachboolonly takes 1 byte to store, meaning the entire array takes 8 bytes total. - The
uint160 timeis stored in the second slot. Even though it only takes 20 bytes to store, meaning it can fit in the remaining space of the first slot, it must start on the second slot since the first slot is storing an array. - The
string titletakes up the entire third slot, since it is a dynamic data type. The slot stores the length of the string, and the actual characters of the string should be stored starting atkeccak256(2). - Next, the entire
datastruct takes up 2 slots. The first slot of the struct packs both thexandyuint128values, since they each only take 16 bytes. Then, the second slot of the struct stores the dynamicbytesvalue. - Finally, there are two mapping values, each taking up an empty slot to reserve their mapping. The actual mapping values would be stored at
keccak(pad(key) . uint256(5))orkeccak(pad(key) . uint256(6))respectively.
Here’s a diagram visualizing the storage:
If the title or z variable contain data that is longer than 31 bytes, they would instead be stored at keccak(s), as shown by the arrows. The mapping values are stored following the defined rules above for hashing the key.
Finally, storage variables can also be declared as immutable or constant. These variables don’t change over the runtime of the contract, which saves on gas fees since their calculation can be optimized out. constant variables are defined at compile-time, and the Solidity compiler will replace them with their defined value during compilation. On the other hand, immutable variables can still be defined during construction of a contract. At this point the code will automatically replace all references to the value with the one that was defined.
Memory
Unlike storage, memory does not persist between transactions, and all memory values are discarded at the end of the call. Since memory reads have a fixed size of 32 bytes, it aligns every single new value to its own chunk. So while uint8[16] nums might only be one 32-byte word when stored in storage, it will take up sixteen 32-byte words in memory. The same splitting also happens to structs, regardless of how they are defined.
For data types like bytes or strings, their variables need to be differentiated between memory pointers or storage pointers, using the memory or storage keyword respectively.
Mappings and dynamic arrays do not exist in memory, since constantly resizing memory is very inefficient and expensive. Though you can allocate arrays with a fixed size using new <type>[](size), you cannot edit the sizes of these arrays like you can with storage arrays using .push and .pop .
Finally, memory optimization is very important, since the gas cost for memory scales quadratically with size as memory expands, rather than linearly.
Stack
Like memory, stack data only exists for the current execution. The stack is very simple, being just a list of 32-byte elements that are stored sequentially one after another. It is modified using POP, PUSH, DUP, and SWAP instructions, much like stacks in standard executables. Currently, the stack only stores up to 1024 values.
Most actual calculations are done on the stack. For example, arithmetic opcodes such as ADD or MUL pop two values from the stack, then push the result with the binary operation onto the stack.
Calldata
Calldata is similar to memory and stack data in that it only exists within the context of one function call. Like memory, all values must also be padded to 32 bytes. However, unlike memory, which is allocated during contract interactions, calldata stores the read-only arguments that are passed in from external sources, like an EOA or another smart contract. It is important to note that if you want to edit the values passed in from calldata, you must copy them to memory first.
Calldata is passed in with the rest of the data during the transaction, so it must be packed properly according to the specified ABI of the function that is being called.
Transient Storage
Transient Storage is a fairly new addition to the EVM, with Solidity only supporting the opcodes starting 2024, with the proper language implementation expected to arrive in the near future. It is meant to serve as an efficient key-value mapping that exists during the context of an entire transaction, and its opcodes, TSTORE and TLOAD. It always takes 100 gas each, making it much more gas efficient than regular storage.
The specialty of transient storage is that it persists through call contexts. This is perfect for scenarios like reentrancy guards that can set a flag in transient storage, then check if that flag has already been set throughout the context of an entire transaction. Then, at the end of the entire transaction, the guard will be wiped completely and can be used as normal in future transactions.
Despite its transient nature, it is important to note that this storage is still part of the Ethereum state. As such, it must adhere to similar rules and constraints of those of regular storage. For instance, in a STATICCALL context, which prohibits state modifications, transient storage cannot be altered, meaning only the TLOAD opcode is allowed and not TSTORE.
EIP-1153 impact analysis
Since transient storage is a relatively recent feature we were able to be comprehensive in inspecting all cases of how it has been used as of Ethereum block number 20129223. We found that from the ~250 deployed contracts containing or having libraries containingTSTORE or TLOAD opcodes, there were ~180 unique source files, meaning over 60 of these deployed contracts were duplicates deployed cross-chain.
Here is the recorded distribution of the usage of transient storage in these ~190 contracts:
Out of the around 190 unique contracts on chain that use this feature, we were able to differentiate them into 6 general categories:
- First and foremost, over 50% of the usage of transient storage is on reentrancy guards. This makes sense, as reentrancy protection is the perfect use case for transient storage and is also very easy to implement, with a simple one possibly looking like:
modifier ReentrancyGuard {
assembly {
// If the guard has been set, there is re-entrancy, so revert
if tload(0) { revert(0, 0) }
// Otherwise, set the guard
tstore(0, 1)
}
_;
// Unlocks the guard, making the pattern composable.
// After the function exits, it can be called again, even in the same transaction.
assembly {
tstore(0, 0)
}
}
- On the other hand, only 3.6% of the contracts used this pattern as an entrancy lock, locking the contract state between transactions to ensure that certain functions could only be called after calling other functions. Here’s a short example.
// keccak256("entrancy.slot")
uint256 constant ENTRANCY_SLOT = 0x53/*...*/15;
function enter() {
uint256 entrancy = 0;
assembly {
entrancy := tload(ENTRANCY_SLOT)
}
if (entrancy != 0) {
revert("Already entered");
}
entrancy = 1;
assembly {
tstore(ENTRANCY_SLOT, entrancy)
}
}
function withdraw() {
uint256 entrancy = 0;
assembly {
entrancy := tload(ENTRANCY_SLOT)
}
if (entrancy == 0) {
revert("Not entered yet");
}
// ...
}
- Next, around 6% of the contracts used transient storage to preserve contract context for callback functions or cross-chain transactions. This was mostly on Bridge contracts, like this one here.
- 8.3% of the contracts used transient storage to keep a temporary copy of the contract state to verify that certain actions are authorized. For example, this contract by OpenSea temporarily stores an authorized operator, specific tokens, and amounts related to those tokens to validate that all transfers happen as they should.
- A bit less than 9% of the contracts used transient storage for their own specialized purposes. For example, an airdropping contract utilizes
tstoreas a hashmap to track and manage eligible recipients within the transaction context. - 20% of contracts although had no transient storage opcodes in the bytecode, contained functions that utilised transient storage in the referenced libraries. Most of these libraries are openzeppelin internals such as their implementation of ERC1967 (see StorageSlot).
The introduction of transient storage marks a significant evolution in the EVM’s data management capabilities. Our analysis at Dedaub reveals that while it’s still in its early stages of adoption, transient storage is already making a notable impact, particularly in smart contract security and efficiency.
The introduction of transient storage marks a significant evolution in the EVM’s data management capabilities. Our analysis at Dedaub reveals that while it is still in its early stages of adoption, transient storage is already making a notable impact, particularly in smart contract security and efficiency.
Key takeaways from our analysis of transient storage usage include:
- Reentrancy guards dominate the current use cases, accounting for over 50% of transient storage implementations. This highlights the immediate value developers see in using transient storage for cross-function state management within a transaction.
- Beyond security, innovative developers are finding creative ways to leverage transient storage for storing contextual information and managing contexts throughout complex transactions.
- The adoption of transient storage, while still limited, shows promise for improving gas efficiency and simplifying certain smart contract patterns.
Gas efficiency improvements
In our analysis of transient storage usage, we also evaluated its gas efficiency compared to regular storage. To do this, we collected the last 100 transactions for each of the contracts analyzed. For each transaction, we obtained its execution trace and used a Python script to simulate gas costs by replacing TSTORE operations with SSTORE under the same conditions (including cold load penalties and other storage rules).
The results were impressive: across all use cases, using transient storage led to an average gas savings of 91.59% compared to regular storage operations. Below, you can find a more detailed graph that shows gas savings per category. Interesting to note that in the case of the Specialized Functionality, gas savings of around 98.7% were recorded. This is because of the airdropping contract mentioned above, and in this case memory might have been a more adequate comparison.
Conclusion
As the Ethereum ecosystem continues to evolve, we expect to see more diverse and sophisticated uses of transient storage emerge. Its unique properties – persisting across internal calls within a transaction while being more gas-efficient than regular storage – open up new possibilities for optimizing smart contract design and execution.
Below we are publishing the dataset and scripts that were used for the above post.
DEDAUB Supports Privacy4Web3 Hackathon
The Privacy4Web3 Hackathon, supported by Oasis Network, is an excellent opportunity for developers to use privacy-centric technologies while innovating in Web3. This edition, also known as Hackathon Oasis Network, has a prize pool of $130,000, with contributions from industry players, including Dedaub.
Developers can utilize Oasis’ confidential EVM, Sapphire, and the newly launched Runtime Off-chain Logic (ROFL) framework. ROFL enables off-chain components to interact with the on-chain domain, expanding Sapphire’s capabilities and creating new possibilities for composability. Learn more
Key Dates
- Submission Period: September 19 – November 1
- Judging Period: November 1 – November 10
- Winner Announcement: November 12
Privacy4Web3 Hackathon | About Dedaub’s Role and Contribution
As a sponsor of the Privacy4Web3 Hackathon, Dedaub is offering $10,000 in audit credits to winning projects that utilize Sapphire and ROFL (Runtime Off-Chain Logic). By offering audit credits, Dedaub wants to emphasize the importance of security when starting new projects.
“Our work with Oasis Network reflects our commitment to Web3 security. We want to ensure developers building privacy-preserving solutions have the right tools and guidance to secure their smart contracts.” Neville Grech, Co-Founder, Dedaub,
Dedaub aims to enhance Web3 safety by employing advanced technology, conducting comprehensive audits, and providing extended security solutions. We have conducted over 200 audits for leading Web3 protocols, securing billions in Total Value Locked (TVL), partnering with industry leaders such as the Ethereum Foundation, EigenLayer, and Liquity. As a part of our commitment, we offer guidance as security advisors for various projects and initiatives.
Dedaub is a security partner of Oasis Protocol Sapphire, a founding collaborator of Seal 911, and a participant in the Chainlink Build Program. Additionally, we are a member of the zkSync Security Council and serve as a security advisor for the Arbitrium DAO.
Privacy4Web3 Hackathon | About Oasis
Oasis is home to Sapphire, the world’s first confidential EVM network. It also boasts the Oasis Privacy Layer (OPL), a cross-chain privacy solution that any EVM dApp can use. Oasis also has ROFL, a framework that supports off-chain components to runtimes like Oasis Sapphire.
Oasis is a layer-one blockchain built to support confidential applications at scale. This is done with a unique layered architecture that presents the optimal building and execution environment for DeFi, AI, RWAs, Gaming, NFTs, DAO governance, and more. Learn more
Privacy4Web3 Hackathon | Ocean Protocol
Ocean Protocol was created to democratize data access and ensure fair and secure sharing in the New Data Economy. Its tools enable seamless trading of tokenized data assets and data management throughout the AI model life cycle. Ocean Protocol is also a founding member of the Artificial Superintelligence Alliance. Learn more.
Bedrock vulnerability disclosure and actions
A few hours ago, the Dedaub team discovered a smart contract vulnerability in a number of uniBTC vault smart contracts in the Bedrock project. We disclosed the issue to the Bedrock account on Twitter and soon thereafter (after no response in 20 mins) to SEAL 911 for immediate investigation and action.
A SEAL 911 war room, under the guidance of @pcaversaccio, was created and we frantically tried for two hours to reach Bedrock developers. At that time, blackhats exploited the vulnerability for a $1.8m loss. However, given that this was an infinite-mint vulnerability on the uniBTC token, it is perhaps fair to assess that the damage was contained. Most of the potential losses were averted by pausing third party protocols exposed to the at-risk funds, including Pendle and Corn. Notably, Pendle had over $30M of liquidity on the Corn network for the vulnerable asset. On Ethereum, the market cap of uniBTC was $75M, which an infinite mint renders worthless, and the asset was deployed in (at least) 8 networks.
Root Cause
The root cause of this vulnerability is a mismatched calculation of the exchange rate between Ethereum and Bitcoin, in one path of the minting logic. In turn, this allows anyone who deposits Ethereum to the vulnerable smart contract vault to mint uniBTC in equal amounts. (Up until the vulnerability, uniBTC could exit to Wrapped Bitcoin at 1-1 rates.) Since the price of Ethereum is many times lower than the price of BTC, this creates an instant profit for any attacker exploiting any of these vaults. The vulnerable vault contract was a permissioned minter for uniBTC, so infinite amounts could be minted. The only adjustment made during this minting function is appropriate scaling in the number decimals of the assets.
In order to appreciate the gravity of this issue, we can illustrate this directly on the following code, straight from the vulnerable uniBTC vault smart contract (the implementation behind the proxy for the Vault):
function mint() external payable { require(!paused[NATIVE_BTC], "SYS002"); // Dedaub: adjust decimals and mint equal amount _mint(msg.sender, msg.value); }
Once the issue is exploited, the next step of a potential attacker would be to make use of this ill-gotten token on a number of other DeFi protocols, such as decentralized exchanges like Uniswap.
Reporting the issue to Bedrock and exploitation
As soon as our team had the issue, we contacted Bedrock on Twitter and entered a war room on SEAL 911.
Initial X.com exchange (time in UTC+2).
Unfortunately, even though we found the issue in the smart contract several hours before, by the time the team responded, the vulnerability had been exploited. The vulnerability could be discovered via shallow means (e.g., fuzzing bots) and the smart contract had only been deployed for under two days.
Timeline prior to exploit:
UTC 16:00 – issue discovered by Dedaub team and confirmed through simulation
UTC 16:27 – issue reported to Bedrock team
UTC 16:41 – war room on seal created on telegram
UTC 18:28 – First exploit transaction on Ethereum
The exploiter(s) subsequently minted large amounts of uniBTC and swapped them on a number of Uniswap and other AMM pools, stealing around $2M in funds directly. Note that the market cap of uniBTC on the Ethereum mainnet is $75M, which is the real potential loss for an infinite mint vulnerability.
Notably, the vulnerable contract was deployed on (at least) 8 different chains. We are aware of Ethereum, Binance, Arbitrum, Optimism, Mantle, Mode, BOB, and ZetaChain.
Averting Larger Losses
In addition to a number of pools on Uniswap (and Pancakeswap on Binance), the largest holder of uniBTC was Pendle. Luckily through war room actions, the Pendle team disabled the uniBTC token on their platform. With the main exit liquidity gone, the Bedrock team reacted some hours later (with the main devs in a 2-5am timezone) to also pause the relevant vaults.
This article will be updated with more detail and context on the discovery (which happened as part of a challenge task during our company retreat) in the next days.
Dedaub coordinated the Secureum RACE-32
Smart contracts are the underpinning of blockchain technology, and they present unique security challenges. To address this, platforms like Secureum have emerged, focusing on training researchers and developers to navigate and mitigate security risks, and we at Dedaub decided we wanted to partner Secureum in this mission.
Why we support the Secureum RACE
We decided to be part of the Secureum RACE because we believe hands-on challenges are the best way to learn. Security isn’t something you can fully grasp from reading papers or attending lectures—you need to get your hands dirty, confront real-world vulnerabilities, and think like an attacker.
The security of smart contracts is challenging due to the inability to modify the code once it goes live. This makes it extremely difficult to fix bugs or vulnerabilities. It’s even more complex, because contracts frequently interact with other contracts and different platforms, which adds even more complexity and multiplies the risk factor.
Secureum platform empowers researchers and developers to help improve their technical skills for what is needed in the challenge to secure Web3 technologies.
As the designer of RACE-32, we have the privilege of observing Web3 researchers and developers navigate complex security issues that mirror real-world vulnerabilities in Ethereum smart contracts. This allows us to witness firsthand and see how they apply their knowledge to devise creative and effective solutions.
As well as this, we see how researchers and developers grow in their ability to identify risks and exploit weaknesses, both of which are critical for the security of the Web3 ecosystem.
Why the RACEs are important
The Secureum RACE aims to create a community of researchers and developers who think critically about security. It’s an opportunity to expand their skills and immerse themselves in the world of Web3 security.
By addressing actual vulnerabilities in smart contracts, participants acquire necessary technical knowledge and develop the mindset to safeguard decentralized applications in real-world scenarios.
“RACEs are hands-on, immersive, and, frankly, a bit relentless—just like the threats we’re up against.” Yannis Smaragdakis, Dedaub Co-funder
Designing the RACE-32
We wanted much more than your standard easily graded competition, so we created the Secureum RACE 32 to be an educational challenge. Our main aim, therefore, was to encourage participants to delve deeply into complex smart contract security issues. With this in mind, The RACE is designed to create an experience that participants can refer to for a long time rather than single out the top performers based on scores.
Even though the time constraint made it challenging to understand the depth of the questions thoroughly, we stressed that the competition aims at learning and gaining insights. We urged participants not to feel disheartened if their scores hadn’t met their own high expectations. Instead, we praised some participants for putting together the solutions, pointing out that this would make the RACE a valuable educational resource beyond just the competition.
This focus on education shows Dedaub’s commitment to helping the smart contract developer community grow. This is the backbone of Dedaub’s mantra as our co-founders both have strong academic backgrounds and always value teaching and sharing knowledge. With this in mind, one of the company’s core values is to empower the next generation by educating and supporting future blockchain security experts and help them reach their full potential.
With challenges like Secureum RACE 32, we create real-world learning opportunities that give researchers and developers practical skills and deeper understanding. Our aim is to help them succeed in the Web3 space.
What is Secureum?
Secureum is a portmanteau of “Security” and “Ethereum” and their focus is safeguarding the Ethereum ecosystem through expert training and challenges. It’s an extensive educational platform that focuses on Ethereum smart contract security, providing a variety of resources and training programs. These include:
Secureum RACEs: Interactive quizzes that assess participants’ understanding of smart contract vulnerabilities. These quizzes are part of Secureum’s efforts to enhance practical security skills.
Community and Events: Secureum hosts events like TrustX to advance the Ethereum security ecosystem.
In summary, Secureum is committed to educating and preparing individuals for roles in Ethereum security through structured learning and practical challenges. Learn more
Dedaub Named Member of ZKsync Security Council
We’re thrilled to announce that Dedaub is now a member of the ZKsync Security Council. We’re grateful for the community’s recognition of our efforts to play an active role in securing and maintaining the integrity of the Web3 space.
What is the ZKsync Security Council?
The ZKsync Security Council is a governance body tasked with safeguarding the security of the ZKsync protocol (ZKsync ERA, ZK Chains, and other components of ZKsync). Comprised of at least nine technical experts, the council has the authority to perform both standard and emergency actions to address security threats. Members are Signers of a multisig wallet, giving them the power to execute critical decisions that protect the protocol. Read more.
Emergency Responses
The Security Council can freeze the ZKsync protocol in response to security threats, such as critical bugs or exploits. A Soft Freeze lasts for 12 hours and requires approval from three Security Council Members. A Hard Freeze lasts for seven days and requires approval from nine Security Council members.
An Emergency Upgrade can be implemented during a freeze to address the threat. Any Security Council Member may initiate an Emergency Upgrade without the approval of the Token Assembly.
Why Dedaub Was Selected
Dedaub was selected for the ZKsync Security Council because of its extensive expertise in smart contract security. The company has successfully completed over 200 security audits, conducted impact studies for the Ethereum Foundation, and developed innovative security Web3 technologies as part of its security suite.
The Dedaub team boasts exceptional academic credentials, with most members holding relevant PhDs, providing a solid foundation for our rigorous approach to Web3 security. ZKsync Security Council is one of many entities that trust Dedaub to increase its security expertise for its initiatives. Dedaub is also a founding member of the Security Alliance (SEAL), Arbitrum DAO Security Advisor, Oasis, and Chainlink Security Partners.
The Importance of Being Part of the ZKsync Security Council
Dedaub’s role in the ZKsync Security Council is actively protecting the ZKsync protocol. We our commitment to enhancing smart contract security and building trust in decentralized platforms and ZK rollups.
Dedaub has invested heavily in preparing for ZK technologies and sponsored the House of ZK event in Brussels, which featured discussions on Zero Knowledge technology and networking opportunities. Neville Grech, Dedaub’s co-founder, participated in a panel on “Trustless Interoperability Using ZK,” along with other industry experts.
Strengthening Legal Protections for White Hat Hackers
White Hat Hackers in the Crosshair
As a white hat hacker and educator, I’ve seen first hand how legal frameworks can fail to protect those who devote their lives to secure software systems.
A case that strikes close to home is a case involving a couple of my University students, who were arrested and were now summoned in court for responsibly disclosing a vulnerability, in Malta. A copy of the leaked vulnerability disclosure email is available here. Two of the students, Michael Debono and Giorgio Grigolo, were subsequently hired by Dedaub. We also extended financial aid to cover part of their legal fees. The arrests occurred after they found and exposed a security flaw in Malta’s largest student application and suggested a bug bounty. This incident shows how the law can treat these good-faith efforts no differently from malicious hacking.
In addition to these students, Mark Vella, a Professor who’s coincidentally a colleague of mine at the University of Malta, is also being charged as an accomplice.
The leaked list of charges (translated into English) includes very serious accusations, so let’s look at a couple of these and try to understand the absurdity of why these were levied. In doing so, I’m keeping in mind transcripts of their interrogation questions and emails that were exchanged.
| Accusation levied | Likely reason why |
| 1,2, 5 – 7: Unauthorized access to a computer, remotely, and copying part of its data. | As part of the responsible disclosure, the students allegedly included a screenshot demonstrating the issue (via a curl command). |
| 9, 10: Intent to make an illicit gain, financial or otherwise. | The students, in their bug report, suggest that they would be eligible for a bug bounty. |
| 9: Forcing the “victim” (the author of the software) to do (or omit) some action. | The students kindly asked for promotion of their CTF team. |
| 8: With respect to Vella (University Professor) – having prepared the rest of the accused to commit crimes. | Allegedly, their Professor saw the email exchange and advised them to make some changes to the wording of their responsible disclosure. |
Another interesting thing that struck me is that during the interrogation of Vella, the interrogator seemed to be toying with the idea of presenting him as a head of this (criminal) organization, with the students acting in his direction, which is obviously absurd.
Implications of this case
This case highlights the significant risks that white hat hackers face, particularly under outdated and rigid cybercrime laws. While the situation has been prominently demonstrated in Malta, it serves as a broader warning that such challenges could arise elsewhere. Malta’s cybercrime regulations, particularly Article 337C, are largely modeled after the Computer Misuse Act 1990 (CMA) from England and Wales. The CMA has not only shaped Maltese law but also influenced legislation in many Commonwealth countries, such as Australia’s Crimes Legislation Amendment Act 2001. Similarly, while the Computer Fraud and Abuse Act (CFAA) in the United States predates the CMA, it has been updated to include provisions strikingly similar to those in the CMA.
The crux of the problem in Malta stems from an excessively strict interpretation of these laws by the Attorney General. This rigid enforcement fails to account for the differences between malicious actors and ethical hackers, leaving well-intentioned individuals vulnerable to prosecution. But why should white hat hackers be penalized due to outdated laws and overly strict interpretations?
One potential solution is the implementation of Safe Harbor frameworks, such as the one proposed by the Security Alliance (SEAL), a leading security coalition in the Web3 space, of which we (Dedaub) are a founding member. The Safe Harbor framework provides legal protection to ethical hackers who responsibly disclose vulnerabilities. While it may not be a perfect solution, Safe Harbor offers a starting point for updating Malta’s outdated cybercrime legislation, aligning it more closely with the realities of modern cybersecurity.
The allegations against white hat hackers like Debono and his peers should serve as a wake-up call for lawmakers. It’s crucial that legislators rethink their approach to cybersecurity and ensure that ethical hackers—those acting in good faith to safeguard digital systems—are protected from prosecution.
Coincidental Visit of Malta’s Prime Minister
Finally, the story ends with a silver lining. The charges we discussed in this article were (ironically) served to the students at almost the same time that the Prime Minister and the Minister of the Economy came to the Dedaub offices. There, the students, as well as myself, had the opportunity to exchange views on the topic. The Ministers vowed to help and to set up better legal frameworks so as to avoid cases like this in the future. The Ministers clearly understood that the activities of white hat hackers are beneficial to society. I sincerely hope we will see more progressive legal changes that protect and promote the activities of white hat hackers over the next few months.
Dedaub at SPLASH 2024
Dedaub is proud to sponsor the SPLASH 2024 conference, helping unite top thinkers in software, programming languages, and systems. We support the community’s advancement of computer science, extending beyond our Web3 security work.
The Doctoral Symposium, where mid-stage doctoral students receive vital research guidance, aligns with our academic roots. Led by university professors, our team is a powerhouse of expertise, with most members holding PhDs. We believe advanced knowledge is vital to delivering exceptional solutions and are excited to foster future tech leaders.
“SPLASH 2024 is where ideas meet action. At Dedaub, we push boundaries—whether in blockchain security or academic thought. By backing SPLASH 2024 , we’re investing in the minds that will define our industry. It’s about innovation, integrity, and preparing the next generation to lead.” Yannis Smaragdakis, Co-founder of Dedaub
Dedaub’s co-founders and senior researchers will attend, supporting open dialogue and contributing to the development of innovative solutions for technology’s future.
Sponsoring SPLASH 2024 emphasizes our commitment to expanding knowledge and empowering the next generation of technology leaders. We see this conference as a platform for pushing the boundaries of blockchain and smart contract security while nurturing emerging talents.
For those attending SPLASH 2024, we look forward to engaging with you, exchanging ideas, and exploring the future of programming together.
About SPLASH 2024
SPLASH (ACM SIGPLAN International Conference on Systems, Programming, Languages, and Applications: Software for Humanity) covers various software creation and delivery aspects. It’s a leading conference at the crossroads of programming languages and software engineering. SPLASH 2024 will feature the co-located OOPSLA, Onward!, SAS, GPCE, and SLE conferences, as well as SPLASH-E and other engaging workshops and events.
SPLASH 2024 will bring together researchers and practitioners worldwide to explore the latest advancements and trends in software and programming languages. We are excited to be part of this dynamic event and to contribute to the ongoing dialogue on shaping the future of software development. Learn more.