Disclaimer: These are personal opinions based on my current understanding of CRE while learning it. They may evolve as I gain more experience.

Why I’m Writing This

I live in two worlds: as a developer obsessed with hackathons (they’re how I feed my curiosity and force myself to learn fast) and as a security auditor, which changes how I look at systems. It pushes me to think more about how things break and what it actually takes to build something secure.

In my first article, I approached Chainlink CRE with a builder’s mindset, focusing on what’s possible and how to ship. This article is different.

Here, I’m approaching CRE as a security auditor. I’ll walk through:

• Potential mistakes developers are likely to make
• Why those mistakes matter
• What both builders and auditors should look for when reviewing CRE workflows

If you’re building with CRE, think of this as your early warning system: the things I’d flag in an audit before they cost you money or credibility.

If you’re auditing CRE projects, treat this as your checklist for the gap between “it compiles” and “it’s actually secure.”

Understanding the Foundation

Before diving into what breaks, it’s important to understand what makes CRE different.

Consensus Computing

Consensus computing means that a decentralized network of nodes must agree on the result of executing code before that result is accepted.

CRE does not run on one machine. It runs on many, simultaneously.

When your workflow calls an API or reads from a blockchain, multiple independent nodes execute the same operation. Each node produces its own result. Those results are compared, and if enough nodes agree (quorum), the result is accepted. If they do not, the workflow fails.

This provides:

• Tamper resistance: no single node can manipulate results
• High availability: the system continues operating despite node failures
• Trust minimization: no single operator must be trusted
• Verifiability: results are cryptographically verified

This process happens automatically for every capability call. You do not write consensus logic yourself. It is built into the CRE runtime.

There is a critical caveat: consensus only works if every node executes identical logic.

Determinism

Determinism means that given the same inputs, the code produces the exact same outputs. Every time. Everywhere.

Your workflow does not run once. It runs in parallel on multiple nodes. For consensus to succeed:

• every node must execute the same steps
• in the same order
• with the same inputs
• and produce the same intermediate results

If any step differs, nodes cannot agree.

The key connection:

• Determinism enables consensus
• Non-determinism breaks consensus

Determinism isn’t a feature. It’s a prerequisite. Consensus computing only works if the computation is deterministic. If nodes don’t execute exactly the same logic, they can’t agree, even if they’re honest.

DON Mode vs. Node Mode: Understanding execution contexts

The key difference between these modes is who is responsible for creating a single, trusted result from the work of many nodes.

Runtime<C> (DON Mode) — The Default:

This represents the DON’s (Decentralized Oracle Network) execution context. It’s passed to your main trigger callback.

When to use: For operations that are already guaranteed to be Byzantine Fault Tolerant (BFT).

When you use the Runtime, you ask the network to execute something, and CRE handles the underlying complexity to ensure you get back one final, secure, and trustworthy result.

Common use cases:

• Writing transactions to a blockchain with the EVM client
• Accessing secrets
• Operations where CRE can automatically provide BFT guarantees

NodeRuntime<C> (Node Mode):

This represents an individual node’s execution context.

When to use: When a BFT guarantee cannot be provided automatically (e.g., calling a third-party API).

You tell each node to perform a task on its own, and each node returns its own individual answer. You are then responsible for telling the SDK how to combine them into a single, trusted result by providing a consensus and aggregation algorithm.

Potential vulnerabilities and best practices

Determinism is easy to break

When workflows run, all nodes must generate identical request IDs for capability calls. If code paths diverge, request IDs differ, quorum is not reached, and the workflow fails.

The failure pattern is simple:

Code diverges → different request IDs → no quorum → workflow fails

Common sources of non-determinism

Object iteration

JavaScript objects do not guarantee key order by specification. While modern engines preserve insertion order, relying on this behavior can cause subtle bugs across different runtimes or during JSON serialization.

Wrong:

const obj = { b: 2, a: 1 }
for (const key in obj) {
  console.log(key) // Order may vary
}

Correct:

const obj = { b: 2, a: 1 }
for (const key of Object.keys(obj).sort()) {
  console.log(key, obj[key]) // Always alphabetical
}

Maps and Sets preserve insertion order by specification, making them safe for deterministic iteration when order matters.

Promise handling and the .result() pattern

SDK capabilities use the .result() pattern instead of async/await. When working with multiple operations, the order you call .result() must be deterministic.

Never use:

const fastest = await Promise.race([fetchFromAPI1(), fetchFromAPI2()])
const firstSuccess = await Promise.any([fetchFromAPI1(), fetchFromAPI2()])

These methods introduce non-determinism because different nodes may “win” the race or succeed with different sources.

Instead, call .result() in a fixed, deterministic order:

import { cre, type Runtime, type NodeRuntime, consensusMedianAggregation } from "@chainlink/cre-sdk"

// Fetch from API 1, then API 2, in a fixed order
const fetchPrice = (nodeRuntime: NodeRuntime<Config>): bigint => {
  const httpClient = new cre.capabilities.HTTPClient()

  // Try first API
  const response1 = httpClient
    .sendRequest(nodeRuntime, {
      url: "https://api1.example.com/price",
    })
    .result()

  // If first API succeeds, use it; otherwise try second API
  if (response1.statusCode === 200) {
    return parsePriceFromResponse(response1)
  }

  // Try second API as fallback (deterministic order)
  const response2 = httpClient
    .sendRequest(nodeRuntime, {
      url: "https://api2.example.com/price",
    })
    .result()

  return parsePriceFromResponse(response2)
}

// In your DON mode handler
const onTrigger = (runtime: Runtime<Config>): MyResult => {
  // Run the fetch logic in node mode with consensus
  const price = runtime.runInNodeMode(fetchPrice, consensusMedianAggregation<bigint>())().result()

  return { price }
}

Dates and times

Never use JavaScript’s built-in time functions in DON mode. Nodes may have slightly different system clocks, causing divergence.

Wrong:

const now = Date.now()
const timestamp = new Date()

Correct:

const now = runtime.now() // Same timestamp across all nodes

runtime.now() returns DON Time, a consensus-derived timestamp that all nodes agree on.

Working with LLMs

LLMs generate different responses for the same prompt, even with temperature set to zero. This breaks consensus.

Instead, request structured output (JSON with specific fields) rather than free-form text, then use consensus aggregation on the structured fields. This allows nodes to agree on key data points even if exact text varies.

Randomness must be consensus-safe

Standard randomness breaks determinism. If each node generates its own random value using Math.random(), consensus is impossible.

CRE provides deterministic randomness:

• In DON mode, runtime.random() produces identical sequences across nodes
• In Node mode, nodeRuntime.random() produces per-node randomness suitable for later aggregation

Never use JavaScript’s built-in randomness. Always use the runtime-provided generator.

Local simulation does not catch this. Simulation runs with a single-node model. It validates SDK integration but cannot detect non-determinism or multi-node consensus failures. Passing simulation does not imply production safety.

Decentralized execution does not mean decentralized data

Calling a centralized API from a decentralized workflow does not make the data decentralized.

If every node calls the same API, owned by the same provider, behind the same infrastructure, all nodes can receive the same manipulated data or no data at all if the service is down.

Consensus only ensures nodes agree on what they observed. It does not guarantee the observation itself is trustworthy.

Using aggregation correctly

When you run code in Node mode, each node executes independently and returns its own result. CRE does not decide how those results are combined. In runInNodeMode, that responsibility is entirely yours.

You can aggregate node results using CRE’s built-in aggregation functions or by writing a custom aggregation function. In both cases, aggregation only answers one question: do enough nodes agree? It does not validate correctness. Nodes can reach perfect consensus on a result that is logically wrong.

CRE’s built-in aggregation functions encode assumptions about the data. They are safe only if those assumptions match reality.

• Median aggregation consensusMedianAggregation<T>() is suitable for numeric values where outliers should be filtered, such as prices or measurements.
• Identical aggregation consensusIdenticalAggregation<T>() should be used for values that must match exactly, like block hashes, transaction IDs, or addresses.
• Common prefix and suffix aggregation consensusCommonSuffixAggregation<T>() are useful for arrays where nodes may observe diverging sequences but still share a common beginning or end.
• For structured data, ConsensusAggregationByFields<T>() allows each field to use an appropriate strategy, which is often safer than forcing a single aggregation rule onto the entire object.

All built-in aggregation functions support .withDefault() to return a fallback value when consensus fails. Using a default is a design choice, not a best practice. In some workflows it's safer than failing hard. In others, it hides real problems. Custom aggregation functions carry the same risk if failure cases are not handled explicitly.

Auditor’s takeaway: Aggregation determines how nodes agree, not whether the result is correct. When reviewing workflows, the key question is whether the chosen aggregation strategy actually matches the data being aggregated.

Validate everything you receive

A successful HTTP request does not guarantee valid data. If you do not validate responses, workflows may:

• process error payloads as valid data
• operate on undefined or null values
• aggregate malformed responses
• write garbage onchain

Always validate:

• HTTP status codes
• response schema
• value ranges
• presence of required fields

Agreement on bad data is still bad data.

Finality when reading from EVM

Reading from non-finalized blocks exposes your workflow to blockchain reorganizations (reorgs). Data that looks correct now might later be reversed. CRE provides three confidence levels for reading blockchain data:

• LATEST : The most recent block, no finality guarantees. Useful for real-time dashboards or displays where speed matters more than certainty.
• SAFE : A block unlikely to be reorganized, but not fully finalized. Good for monitoring or alerting when you need reasonable confidence. (Note: SAFE is not available for all chain reads.)
• FINALIZED : Blocks considered irreversible. Use for critical operations, financial transactions, or anything where incorrect data could cause significant harm.

⚠️ Warning: If you don’t explicitly specify a block number, CRE defaults to LATEST. This can silently introduce risk.

Critical operations after EVM write

Chain write operations return a WriteReportReply when the transaction is included in a block, not when it reaches finality. If a block containing your transaction is reorganized:

• CRE’s Transaction Manager (TXM) automatically resubmits your transaction
• Gas bumping is applied as needed to ensure the transaction is included

If you need absolute certainty that your write transaction reached finality, implement post-write verification by reading the blockchain state after a custom number of confirmations. Do not rely solely on WriteReportReply for finality confirmation.

Multiple duplicate report submissions reaching your API.

When a workflow executes, all nodes in the DON attempt to send the report to your API. Each node generates its own unique cryptographic signature for the report. Because these signatures differ across nodes, traditional HTTP caching has limited effectiveness. The cache can’t match requests with different signatures.

To fix, use a two-layer defense strategy:

1. Client-side caching (limited but essential): Always include cacheSettings in your transformation function
2. Server-side deduplication (required): Your API must implement deduplication using the hash of rawReport (keccak256(rawReport)) as the unique identifier

Unverified report data being processed by your API.

Unlike onchain submissions where the KeystoneForwarder contract automatically verifies signatures, HTTP endpoints receive raw data without cryptographic verification.

To fix, your receiving API must verify cryptographic signatures against DON public keys before trusting any report data. This is your responsibility. There’s no automatic verification layer for HTTP submissions.

Silent numeric bugs

One class of silent bugs that might get overlooked is about wrong numeric results caused by differences in how languages handle numbers.

CRE workflows today are written in Go and TypeScript, but they frequently read from and write to Solidity contracts, which use very different numeric semantics. The way each language represents and manipulates numbers is not uniform:

• Solidity uses fixed-width integers like uint256, which have strict bounds and defined overflow/underflow behavior on-chain (reverts in 0.8.0+, wraps in earlier versions).
• Go represents Solidity integers as *big.Int in generated bindings, which supports arbitrary precision but has different behaviors for operations and overflows compared to fixed-width EVM integers.
• TypeScript uses bigint for Solidity integer types in ABI encoding/decoding, but basic number types are floating-point and can silently lose precision.
• Future SDKs may introduce new numeric models or type systems (Rust, Python, etc.).

These differences are inherent to the language runtimes, not bugs in CRE itself. If developers aren’t careful, math can silently:

• Overflow or wrap in ways that differ from on-chain expectations
• Lose precision in off-chain logic before being encoded for the EVM
• Behave inconsistently between what the workflow calculates and what the smart contract expects

This doesn’t typically break consensus. Every node will compute the same value, but it can lead to agreements on the wrong value.

Going low-Level without a clear reason

CRE offers two ways to make HTTP requests in TypeScript workflows:

• http.SendRequest (recommended)
• cre.RunInNodeMode (lower-level, manual)

If your use case fits a standard request/response model, http.SendRequest should be your default choice. It handles deterministic request construction, consensus-friendly execution, and proper interaction with the DON, reducing the surface area for subtle bugs.

Using RunInNodeMode provides more flexibility, but it also shifts responsibility to you:

• ensuring requests are identical across nodes,
• selecting and applying the correct aggregation strategy,
• preventing duplicate side effects.

Forgetting cache settings for HTTP requests

By default, every node in the DON executes the same HTTP request independently. For GET requests, this is usually harmless. For non-idempotent requests — such as POST, PUT, PATCH, or DELETE — it introduces real risk.

Without cache settings, the same request may be executed multiple times, even though consensus succeeds and the workflow completes successfully.

From CRE’s perspective, nothing is wrong. From the external system’s perspective, the same action just happened more than once.

How CacheSettings Help

cacheSettings enables a shared cache across the DON:

• one node executes the request,
• other nodes reuse the cached response,
• side effects occur once instead of many times.

A typical configuration looks like:

cache: {
  readFromCache: true,
  maxAgeMs: 60000
}

Important Caveats

• Caching is best-effort, not a guarantee. Duplicate execution can still occur due to network failures, routing changes, or nodes hitting different gateway instances.
• Choosing maxAgeMs matters.
  - For write operations, it should be slightly longer than the workflow execution time.
  - For read operations, it should reflect acceptable staleness.
  - To force fresh execution, set it to 0 or omit caching entirely.
• Caching also requires fully deterministic requests. The URL, headers, and body must be byte-for-byte identical across nodes. Non-deterministic values like Date.now() will break caching.
• For critical operations, caching should always be combined with API-level idempotency keys, since cache behavior alone cannot guarantee single execution.

Before you ship: Security Checklist

• [ ] Ensure all object iterations use sorted keys
• [ ] Ensure all time operations use runtime.now()
• [ ] Ensure all randomness uses runtime.random()
• [ ] Ensure critical chain reads use finalized blocks
• [ ] Define aggregation strategies for all Node mode operations
• [ ] Define .withDefault() or explicit failure handling for aggregation
• [ ] Use bigint for all Solidity numeric values
• [ ] Implement post-write verification for critical chain write transactions
• [ ] Validate all HTTP responses (status, schema, ranges)
• [ ] Use cache settings for all non-idempotent HTTP requests
• [ ] Implement API-level idempotency or report hash deduplication
• [ ] Verify cryptographic signatures for HTTP report submissions
• [ ] Use http.SendRequest unless custom node logic is required
• [ ] Document all centralized trust assumptions explicitly

Conclusion

CRE’s security model is powerful because it is built on consensus. But consensus is unforgiving. It requires strict determinism and cannot detect when all nodes agree on incorrect data.

The vulnerabilities outlined in this article are the gaps between “it compiles” and “it’s secure.” The mistakes that turn promising workflows into production failures.

For builders: Treat determinism as a hard requirement. Validate everything. Test with real multi-node deployments. Use the checklists above.

For auditors: Start with determinism, verify data validation, check finality handling, and never trust simulation results alone.

What I learned building three complex workflows at ETHGlobal Buenos Aires

At ETHGlobal Buenos Aires during Devconnect, our team built Wolfy Wallet — a fork of Rabby Wallet with EIP-7702 support, hardware multisig, and most notably, a fully decentralized x402 payment facilitator built using Chainlink CRE.

We walked away with three awards:

🏆 Chainlink — Best Workflow with Chainlink CRE
🏆 Octav — Best App Built Using Octav API
🏆 Zircuit — Best Zircuit Integration

But beyond prizes, the real outcome was learning how CRE behaves when pushed to its limits. We built three sophisticated workflows — verification, settlement, and execution monitoring — and along the way discovered many quirks, pain points, and breakthroughs.

This article is a breakdown of what I learned building a decentralized x402 facilitator using CRE in production conditions.

What is Chainlink CRE?

Chainlink Runtime Environment (CRE) is Chainlink’s all-in-one orchestration layer unlocking institutional-grade smart contracts — data-connected, compliance-ready, privacy-preserving, and interoperable across blockchains and existing systems.

Think of it as a way to write code that can:

• Read from multiple blockchains
• Call external APIs securely
• Do computations off-chain
• Write results back on-chain
• All while being decentralized and trustless

The magic here is that everything runs across multiple independent nodes through something called a Decentralized Oracle Network (DON). When your code makes an API call or reads blockchain data, multiple nodes do it independently, then use Byzantine Fault Tolerant consensus to agree on the result. This means you get the same security guarantees as blockchain transactions, but for everything your code does — not just the on-chain parts.

The SDK currently supports TypeScript and Go, so you can develop your workflow in TypeScript or Go, and CRE compiles it to WebAssembly (WASM) that runs in a sandboxed environment across the DON.

Why I Used CRE: The x402 Problem

The x402 is basically HTTP 402 (Payment Required) but for crypto — it lets you gate access to services behind on-chain payments.

Here’s the problem: x402 requires a “facilitator” if the server doesn’t want to do this job— a trusted service that handles the payment flow between clients and servers. The facilitator has three key responsibilities:

1. Verify payments: Confirm that the client’s payment payload meets the server’s declared payment requirements
2. Settle payments: Submit validated payments to the blockchain and monitor for confirmation
3. Provide responses: Return verification and settlement results to the server, allowing the server to decide whether to fulfill the client’s request

Currently, facilitators are either self-hosted (you run your own server) or hosted facilitator service (trust someone else’s server) e.g. Coinbase’s Facilitator. Both are centralized services.

We wanted a fully decentralized facilitator. That’s where CRE came in.

Our goal was simple:

No servers. No trust assumptions.
A fully decentralized facilitator.

What We Built

I built two CRE workflow files with three total workflow handlers that together form a complete decentralized facilitator “ source code “:

The architecture: Two workflow files (d-verify and d-settlement) with three handlers total - one for verification, one for settlement submission, and one for monitoring execution events.

1. Payment Verification Workflow (d-verify)

Trigger: HTTP trigger — receives payment verification requests from servers

Capabilities Used:

• EVMCleintread- Multiple calls to verify EIP-712 signatures, check token balances, and validate nonces
• http - Uses sendRequest to POST verification results back to the server

What it does: Validates all x402 payment requirements (protocol version, permit signatures, token balances, deadlines, nonces, amounts, recipient addresses)

Outputs: HTTP POST callback (via sendRequest) to the server with verification result (pass/fail + details)

2. Payment Settlement (d-settlement)

This is actually two workflows in one file that work together:

Workflow 2a: Settlement Submission (HTTP-triggered)

Trigger: HTTP trigger — receives settlement requests after verification succeeds

Capabilities Used:

• EVMCleintread: Re-verify payment before settlement (security measure)
• EVMCleintwrite: - Submit signed report to SettlementReceiver contract on-chain

What it does: Re-verifies the payment, prepares execution data, generates a signed report, and submits it on-chain to be executed

Outputs: Returns JSON (but remember: HTTP triggers don’t actually return data to the caller — you just get an “ACCEPTED” status)

Workflow 2b: Execution Monitoring (EVM log-triggered)

Trigger: EVM log trigger — monitors ExecutionSucceeded and ExecutionFailed events from ExecutionProxy contract

Capabilities Used:

• http - Uses sendRequest to POST settlement results to the server's callback URL

What it does: Watches the blockchain for settlement execution results from the ExecutionProxy contract and decodes the event data

Outputs: HTTP POST callback (via sendRequest) to the server with settlement result (pass/fail + details: success, transaction, network, errorReason, payer)

The Hard Lessons

Here’s what I learned the hard way building these workflows:

1. HTTP Triggers Don’t Return Data (Big Limitation!)

When you trigger a workflow via HTTP, you cannot return data like a normal API.

You get back a response like this:

json

{
  "success": true,
  "response": {
    "workflow_id": "0x...",
    "workflow_execution_id": "0x...",
    "status": "ACCEPTED"
  }
}

That’s it. Just “we got your request.” Your actual workflow output lives in the CRE logs.

The Problem: For x402, the facilitator needs to immediately tell services whether a payment is valid. But we can’t return that data in the HTTP response!

My Workaround: I used Chainlink’s http capability to make HTTP sendRequest callbacks to the service with the verification result. Not perfect because:

• It’s not 100% compliant with x402 architecture
• You can hit quota limits on HTTP calls
• But it was the only solution available

I hope they provide a better solution for this soon.

2. External Calls Must Use Capabilities

You cannot just import a library and make API calls or EVM calls directly (in our case, we were using the x402 library). If you try, you get this unhelpful error:

panic: runtime error: invalid memory address or nil pointer dereference

Why: All external interactions (API calls, blockchain reads/writes) must go through CRE’s “capabilities” system. This is how the DON nodes coordinate to execute calls and reach consensus.

The Learning Curve: You have to learn to think in capabilities:

• Want to call an API? → Use http capability
• Want to read/write blockchain data? → Use EVMClient Read & Write capabilities

It’s a different mental model than normal backend development.

3. Secrets Configuration Is Confusing

When simulating locally, you need to set up secrets in a specific way:

The Gotcha: The key name and value name in secrets.yaml cannot be the same.

Wrong:

yaml

secretsNames:
  EVM_ADDRESS:
    - EVM_ADDRESS  # ❌ This breaks!

Right:

yaml

secretsNames:
  EVM_ADDRESS:
    - EVM_ADDRESS_ALL  # ✅ Different name

Then in your .env:

bash

EVM_ADDRESS_ALL="0x1234..."

This tripped me up for hours. The error messages don’t help you figure this out.

4. Always Use Cache Settings

Critical lesson: Always include cacheSettings in HTTP requests for non-idempotent operations (POST, PUT, PATCH, DELETE) to prevent duplicate executions.

The Problem: All nodes in the DON execute HTTP requests independently. For payment settlements or callbacks, this can cause duplicates.

The Solution: cacheSettings creates a shared cache—first node executes the request, others reuse the cached response.

typescript

cacheSettings: {
  readFromCache: true,     // Enable cache reading
  maxAgeMs: 60000,         // Accept cached responses up to 60 seconds old
}

Key points:

• Set maxAgeMs slightly longer than your workflow's execution time (e.g., 60000ms)
• Caching is best-effort, not guaranteed to prevent all duplicates
• Only works if all nodes construct identical requests (same URL, headers, body)

In our x402 facilitator, we used this for all callback requests to minimize duplicate payment notifications.

5. Simulation Requires — broadcast Flag

When simulating locally, if you want to do any EVM calls (reads or writes), make sure to pass the --broadcast flag:

bash

cre workflow simulate my-workflow --target staging-settings --broadcast

Without it, CRE can’t execute real evm calls in simulation.

6. You Need Whitelisting to Deploy

Currently only whitelisted accounts can deploy to production CRE. You can simulate locally all you want, but to actually run on the DON, you need Early Access approval.

During the hackathon, the Chainlink team deployed our workflow for us, but before that we could only simulate, which was enough to validate the architecture.

7. Concurrency Limits Are Real

You can only run 5 workflows concurrently across your entire account. This means if 10 payment verification requests come in at once, 5 will process and 5 will queue (and wait up to 10 minutes before being dropped). For a payment facilitator serving multiple users, this is tight. We should rethink about our desgin and plan accordingly.

The Service Quotas You Need to Know

CRE has strict limits. Here are the key ones that affected my workflows:

Per-account limits:

• Deploy 1 workflow per minute (burst: 1)
• Maximum 5 concurrent workflow executions across all workflows
• Workflow triggers: 5 per second (burst: 5)
• Max binary size: 100 MB (20 MB compressed)

Per-workflow limits:

• Triggers fire at 1 per 30 seconds (burst: 3)
• Max 10 triggers per workflow
• 5-minute timeout with 100 MB memory
• Maximum 5 concurrent instances per workflow
• 100 KB response size limit

Capability limits:

• 3 concurrent capability calls max
• HTTP: 5 calls per execution, 10 KB response, 100 KB request
• EVM read: 10 calls per execution, 100 blocks for log queries
• EVM write: 5M gas quota, 1 KB report size, 10 target chains

Other limits:

• Logging: 1 KB per line, 1,000 events per execution
• EVM log triggers: max 5 per workflow, monitor up to 5 contract addresses

These limits are tight when you’re building something production-grade. The 5-concurrent-execution limit especially means you need to think about queuing and retry logic in your application layer.

What CRE is Great For

IMO, despite the limitations, CRE is genuinely powerful for certain use cases:

✅ Cross-chain orchestration: Our workflows supported 7+ EVM chains (Ethereum, Base, Arbitrum, Optimism, Polygon, Avalanche, BSC) with one codebase “ more to come”

✅ Moving computational logic to a trustless decentralized off-chain network: Reduce on-chain costs by processing complex logic off-chain with the same security guarantees

✅ Complex workflows: Combining HTTP triggers, EVM reads, EVM writes, and log monitoring in one coherent flow

✅ Institutional-grade security: Every operation goes through BFT consensus — no single point of failure

What CRE Currently Can’t Do (or Does Awkwardly)

❌ Synchronous HTTP responses: Can’t return data directly from HTTP-triggered workflows

❌ High-frequency operations: IMO concurrency and rate limits make it unsuitable for high-throughput scenarios

❌ Easy debugging: Error messages need improvement; hard to debug WASM execution issues

⚠️ Cost at scale: Currently there is no cost estimation for your workflow to help you decide. It will definitely be way less than on-chain, but there’s no clarity yet on how much since you’ll be monthly billed

Final Thoughts

Building a fully decentralized x402 facilitator on CRE wasn’t easy.
But it proved a point:

You can run real payment infrastructure
without servers, trusted hosts, or custodial intermediaries.

CRE is still early. It has sharp edges.
But the architecture is groundbreaking — and worth betting on.

For everyone keep an eye on it. As the platform matures and adds features like confidential computing, the use cases will expand significantly.

Resources:

• CRE Documentation
• Our Wolfy Wallet Project
• x402 Payment Standard

Tips and tricks from +10 hackathon winner

Last May, I co-hosted a community mixer in Cairo for Arabs in blockchain community, during the Chainlink Chromium Hackathon. In the intro talk, I shared some few tips, tricks, and personal insights on why I believe everyone should participate in hackathons. In this article, I’m documenting those thoughts and expanding on them in more detail.

Why You Should Join?!

If you were there, you probably remember me saying:

The reason I’m so excited to talk about hackathons is that, after coffee, hackathons are my second favorite thing.

While that line usually gets a laugh, beyond my personal enthusiasm, there are solid reasons why I encourage you — dear reader — to get involved.

Hackathons offer learning opportunities you simply won’t find in a classroom or a typical work environment. You’re not just reading about concepts — you’re applying them under time pressure, solving real problems, and shipping actual products. That kind of hands-on experience accelerates your growth in a way no tutorial or lecture ever could.

They’re also incredible spaces for meeting like-minded developers, designers, and innovators. The people you collaborate with during those intense 24–72 hour sprints often become future co-founders, long-term collaborators, or close friends. Many companies quietly use hackathons as headhunting grounds, and a strong teammate or mentor can become your most valuable advocate. A referral from someone who’s seen you perform under pressure is worth far more than a cold LinkedIn message.

Participating in hackathons doesn’t just boost your skills — it boosts your visibility. Winning (or even just building something impressive) strengthens your CV, helps you stand out in internship and job applications, and gives you direct exposure to recruiters and sponsors who are actively looking for talent. These events are powerful platforms to showcase your abilities through tangible projects, grow your professional network, and even unlock funding or incubation opportunities for promising ideas.

They also keep you up to date with fast-moving technologies, help you build a strong professional reputation, and provide a creative space to explore new ideas outside your daily routine.

But hackathons aren’t the same. Some are ideation-focused, where the main objective is to generate creative concepts and innovative solutions, even if you don’t build a full product. Others emphasize technical execution, challenging participants to develop functional prototypes or demonstrate innovative uses of specific technologies. Then there are hackathons that adopt a startup mindset, seeking projects with real-world potential, good market fit and strong teams that they can fund, incubate, or support beyond the event. Recognizing the type of hackathon helps you align your team, skills, and strategy to stand out in exactly what the organizers are looking for.

In this article, the focus is on hackathons that emphasize technical execution. These are the events where you come up with an innovative idea and build a functional MVP to showcase your skills and creativity. This doesn’t mean you’re not solving a real problem, but the key difference is that factors like market research, team completeness, and product–market fit are not as heavily emphasized. The spotlight is on how well you can use the technology to bring your idea to life within a short time frame, rather than proving the business viability of the project.

Now I’m assuming you are interested in joining a hackathon and I believe the next questions that came to your mind are:

Where to Find Hackathons in Web3

First, it’s important to know that there are two main types of hackathons: online and in-person. Each has its own vibe, advantages, and challenges, and the “best” option really depends on your personal preferences.

If there were a grand prize for the best hackathon experience, I’d give it to ETHGlobal — they host both in-person and online events, and their community is top-notch. But ETHGlobal isn’t the only place to look. Platforms like DoraHacks, Devfolio, and Devpost are also major hubs where most Web3 hackathons take place.

You’ll also come across some of the biggest annual events, such as ETHDenver, among many others. A great way to stay informed is by joining blockchain communities, where people often share upcoming hackathons, opportunities, and conferences.

If you haven’t already, consider joining our community to stay updated. At the time of writing, we’re promoting the Forte-Hacks —by Flow and if you’re in Cairo, join us today for a hackathon mixer!

Which Hackathon to Join — How to Evaluate and Choose the Best

When deciding which hackathon to join, I usually focus on a few key factors to make sure I get the best possible hacking experience — because hacking should be fun!

The first thing I look at is the organizer. A well-organized hackathon sets the tone for everything. I check their reputation for support, safety, and trust. Trust is especially important — you need to be confident that the organizers and sponsors will actually deliver the prizes and rewards they promise.

Next, I look at the prize pool. Naturally, a larger prize pool is more attractive. Competing for $500K is far more motivating than competing for $10K.

Finally, I consider the diversity of hacking ideas and technologies. The more diverse the tracks and challenges, the more room there is for innovation, learning, and creativity. A broad range of themes keeps things exciting and gives you the chance to explore new tools and ideas.

How to Join and form a team

The process of joining a hackathon depends on the specific rules and format, so it’s important to read the guidelines carefully for each event.

When it comes to team building, there are several ways to find teammates — or for others to find you. Most hackathons have team formation channels on Discord, where participants can introduce themselves and connect. You can also meet potential teammates at online or in-person mixers (like the one we’re hosting tomorrow!), or simply post on social media to let others know you’re looking for a team or a teammate.

Don’t be afraid or shy to put yourself out there — posting that you’re looking for teammates or replying to others’ posts is completely normal and often leads to great collaborations. If you don’t already have friends joining the hackathon, don’t worry — hackathons are amazing spaces to meet new people and build long-term friendships.

In fact, during my last hackathon, I met my teammate through a Discord team formation channel, and together we ended up as finalists at ETHGlobal Tippie. That’s the power of putting yourself out there.

How to Secure a Win

Now let’s talk about some tips and tricks to help you secure that win — and maybe even some prize money. But remember winning isn’t just about the money. It’s also about the recognition you earn for doing an amazing job, mastering the technology, and proving that you can build and ship a product within 24 hours (if it’s a 24-hour hackathon). And honestly, there’s nothing more lovely and exciting than hearing or reading “You are a winner!” after all your hard work. That moment makes everything worth it.

Here are some practical tips and common mistakes to avoid to increase your chances of winning:

• Pick a simple but powerful idea: Focus on solving a real problem with a clear, executable concept. Overly ambitious ideas often end up half-finished.
• Avoid trying to build a massive dream project in 24 hours: Keep your scope realistic. It’s better to start small, iterate, and deliver a working MVP than to start big and never finish.
• Think smart, but don’t get stuck debating: Good ideas need discussion, but there’s a fine balance. Productive planning early on is essential, but endless arguing and overthinking waste precious time. Decide, commit, and move forward.
• Start fast: The first hours are critical. Don’t spend the entire first day in meetings — make decisions early and begin building to give yourself time to refine later.
• Build a balanced team: A strong mix of tech, design, and business skills sets you up for success. But it’s not just about skills — it’s about attitude and commitment. A reliable teammate who knows less but delivers consistently is often more valuable than someone highly skilled but unreliable.
• Stay focused: A scattered team rarely wins. Clear direction, discipline, and good communication keep the project on track.
• Avoid bad pitching: If you can’t communicate your idea well, no one will understand what you’ve built — even if it’s brilliant.
• Make the judges’ job easy: Don’t make them work to figure out what you built. Structure your demo, pitch, and documentation so the value and impact are obvious. A well-written README and submission that explains your project clearly and guides them through your work will make it much easier for judges to grasp everything quickly.
• Align your project with the hackathon theme: Show a clear connection between your solution and the challenge.
• Leverage existing tools: Use pre-built frameworks and libraries to save time — hackathons reward speed and creativity, not reinventing the wheel. Make smart use of AI tools and VibeCode to speed up development and focus on what really matters.
• Document as you go: This simplifies preparing your final presentation and demo.
• Talk to mentors early: Early feedback can save you from major mistakes later.
• Organize time and roles from the start: Clear planning avoids last-minute chaos and ensures everyone knows their responsibilities.
• Start gathering feedback as early as possible, especially on the problem you’re solving, your approach, and how you’re planning to build it. This kind of input is most valuable before you start coding heavily — it can help you catch blind spots, refine your scope, and avoid wasting hours on the wrong direction. Talk to mentors, judges, experienced builders, or even other participants. Pay close attention to their reactions. Interest, follow-up questions, or suggestions usually mean you’re on to something. Confusion or disengagement can signal that your problem statement or approach isn’t clear enough yet.
• keep pitching your idea to everyone you meet throughout the hackathon. Each quick pitch acts as practice — it helps you sharpen your idea and uncover different perspectives. People will often give you useful feedback on missing features, alternative tools, or stronger ways to frame the problem.

By applying these tips and avoiding common pitfalls, you’ll significantly boost your chances of standing out, impressing the judges, and hearing those magic words: “You are a winner!”

What If You Don’t Win

Let’s be honest: most hackathons won’t end with you holding a trophy. But here’s the truth — some of my most valuable experiences came from hackathons where I didn’t place. Here’s how to turn a “loss” into real growth:

• Get feedback immediately: Approach judges and mentors while the event is still fresh. Ask specific questions: “What could have made our project stronger?” or “Was our technical approach solid?” This insight is invaluable for your next attempt.
• Your project still has value: Just because judges didn’t pick you doesn’t mean your idea is worthless. Continue building it, open-source it, or add it to your portfolio. A well-documented GitHub repo can impress recruiters more than a trophy. Many successful startups — including some unicorns — began as “losing” hackathon projects.
• Reflect objectively: Analyze what worked and what didn’t. Was it the idea? Execution? Pitch? Team dynamics? Write a quick post-mortem while it’s fresh in your mind.
• Showcase your work anyway: Post about your project on social media, write a blog post, or create a demo video. Frame it as “Here’s what I built in 24 hours at [Hackathon]” rather than focusing on placement. The tech community respects builders, win or lose.
• Leverage your network: The connections you made matter more than the prize. Stay in touch with teammates, other participants, and sponsors. Some of my closest collaborators and job opportunities came from hackathons where we didn’t win anything.
• Iterate if there’s potential: If your idea has legs, keep working on it post-hackathon. Refine it, get user feedback, and maybe even launch it properly.
• Use it as fuel, not discouragement: Every hackathon winner has lost multiple times. I certainly have. Each setback taught me something that contributed to future wins. The question isn’t whether you’ll face losses — it’s whether you’ll let them stop you or use them as stepping stones.

Remember: You just compressed weeks of learning into 24–48 hours and shipped something under intense pressure. That alone is an achievement. The goal isn’t just winning prizes — it’s becoming the kind of person who can build, ship, and present under pressure. That skill is worth more than any single prize pool.

Conclusion

Hackathons are more than just competitions — they’re intense learning experiences, career accelerators, and community-building moments rolled into one. Whether you’re a developer, designer, marketer, or simply curious about Web3, joining at least one hackathon can open doors you didn’t even know existed. You’ll build real projects, meet inspiring people, push your skills to new levels, and maybe even walk away with a prize — or a startup idea that changes your career path.

So don’t wait for the “perfect” moment or the “right” team. Pick a hackathon, show up, and give it your best. The worst that can happen is that you’ll learn something new. The best that can happen? You’ll surprise yourself with what you can achieve in just a few days.

See you at the next hackathon 👩‍💻🚀

Why everyone in web3 should participate in Hackathon at least once ! was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

From the heart of Istanbul, where the vibrant hum of Ethereum enthusiasts echoed through the city during Devconnect, I went on a transformative journey that extended far beyond the conference walls to the Nesin Mathematics Village, a hidden gem in Western Turkey. My journey from the bustling Ethereum Devconnect in Istanbul to this unique retreat was not just a transition of locations; it was a transformation of experience.

Devconnect: A Prelude to the Extraordinary

Devconnect, held from November 13–19, was a spectacle of Ethereum innovation that drew over 3500 enthusiasts. As I immersed myself in the dynamic atmosphere at the Devconnect Cowork in the Istanbul Congress Center, little did I know that the real magic was yet to unfold in the tranquil haven of the Nesin Mathematics Village.

Post-DevConnect: 0xVillage at Nesin

From November 19–23, following Devconnect, I went to 0xVillage, nestled in the Nesin Mathematics Village in Western Turkey. This unique program was a collaborative effort to bridge the worlds of Ethereum and the Turkish math community, fostering a long-lasting relationship. The primary aim was to create a space for researchers to delve into web3 without the distractions of marketing or business components.

Intro to the Nesin Mathematics Village:

The Nesin Mathematics Village is a non-profit village dedicated to math, philosophy and the arts. It’s a picturesque place not far from the ancient city of Ephesus and the Temple of Artemis, one of the Seven Wonders of the Ancient World. It is like Smurfs but with math. Classes run the entire year (check the summer undergraduate/graduate program). 0xVillage was an independent event in the Village. For a firsthand story of the Village, check out Ali Nesin’s Leelavati Prize Lecture.

The Essence of 0xvillage: Learning, Exploring, Connecting

1. Learning:

The core of the program experience lies in its dedication to mathematics, art, and philosophy. Participants engage in research talks on crypto, expanding their knowledge base in a focused and uninterrupted environment.

2. Exploring:

The program is not just about learning; it’s about embracing the surrounding regions. We had the opportunity to explore the rich history of Ephesus, delve into local culture, and experience the warmth of Turkish hospitality.

3. Connecting:

One of the most enriching aspects of 0xVillage was the diverse representation from countries around the world — Belgium, Canada, Egypt, France, Germany, Honduras, India, Iran, Japan, Poland, Singapore, South Korea, Thailand, Tunisia, Turkey, and the USA. The gathering of minds fostered connections that transcended geographical boundaries, creating a global network of like-minded individuals.

4. Enjoying Our Time:

In the beautiful Nesin Mathematics Village, we didn’t just stick to the scheduled stuff; we really connected and relaxed. We found quiet spots to chat, and shared meals together. Nature was our chill-out zone — walks, thinking time, and getting creative in a laid-back way. Our time in Nesin became a cool mix of building tight bonds, just enjoying the moment as well as learning, making our experience there really special.

5. Embracing Inclusivity and Cultural Exchange

The program, led by Yiğit Kılıçoğlu and Nour Assil, co-organizer, deserve special appreciation for their commitment to exclusivity. The Nesin Mathematics Village is a testament to the power of collaborative and cooperative philosophy, providing a space for individuals from all walks of life to come together and explore the intersections of crypto and culture.

Action Items: A Call to Support and Expand the Experience

As we reflect on this transformative experience, two crucial action items come to light:

Support the village:

Nesin Mathematics Village relies on support to continue its mission. Consider contributing to sustain this unique haven for learning and cultural exchange. Check the village gallery

Expand the experience globally:

Let’s replicate this enriching experience worldwide. Imagine 0xVillage events in different countries, each infused with its own unique color and flavor.

Closing Thoughts: Valuing Humanity in Crypto Spaces

In the dynamic world of cryptocurrency, let’s not forget the essence of humanity. We need a blend of learning, exploration, and cultural exchange, all immersed in the purity of nature. As we advocate for more inclusive initiatives, let’s bridge gaps and discover the beauty in diverse hearts worldwide. There’s a world full of wonders waiting to be explored — why not embark on this collective journey?

Disclaimer

This article, “10 smart contract vulnerabilities with code examples” was prepared as part of Ekolance’s smart contract audit training. It is intended for educational purposes only.

Introduction

This article is a compilation of 10 smart contract vulnerabilities, with code examples and explanations. It’s an attempt to create a comprehensive list of known vulnerabilities and to provide a resource for smart contract auditors and developers.

#1 Reentrancy

Description

Reentrancy is a vulnerability that allows an attacker to re-enter a function multiple times before the first function call is finished. so whenever the contract makes external call to other addresses, this is a possibility for reentrancy attack.This can lead to unexpected behavior, including reordering of transactions, and can be used to drain funds from a contract. Rareskills did a fantastic job explaining the different types of vulnerabilities in this article, as below:

• When Ether is transferred, the receiving contract’s fallback or receive function is called. This hands control over to the receiver.
• Some token protocols alert the receiving smart contract that they have received the token by calling a predetermined function. This hands the control flow over to that function.
• When an attacking contract receives control, it doesn’t have to call the same function that handed over control. It could call a different function in the victim smart contract (cross-function reentrancy) or even a different contract (cross-contract reentrancy)
• Read-only reentrancy happens when a view function is accessed while the contract is in an intermediate state.

Code Example:

function withdraw(uint amount) public{
    if (credit[msg.sender]>= amount) {
      require(msg.sender.call.value(amount)());
      // here we are updating the credit after the external call, which is vulnerable to reentrancy attack
      credit[msg.sender]-=amount;
    }
  

A real-life example

• A Historical Collection of Reentrancy Attacks

Mitigation

• Use the checks-effects-interactions pattern to avoid reentrancy attacks.
• Use a reentrancy lock (ie. OpenZeppelin’s ReentrancyGuard).

Reference

• SWC-107
• RareSkills article

The below 3 vulnerabilities are related to access control issues in smart contracts.

Access control vulnerabilities in smart contracts occur when there are flaws or weaknesses in the way a contract manages and enforces permissions or restrictions related to who can perform specific actions or operations within the contract. These vulnerabilities can lead to unauthorized access, manipulation, or control of the smart contract, potentially resulting in security breaches or financial losses. To simplify the explanation, we can say that access control is about controlling who calls a function.

#2 Missing Access Controls:

• A smart contract may be missing access controls, allowing anyone to perform certain actions or operations that should be restricted to specific users or accounts. For example, a smart contract may allow anyone to withdraw funds from a contract or destruct the contract, when only the contract owner should be able to do so.

Code Example:

pragma solidity ^0.4.22;
   contract SimpleSuicide {
   function sudicideAnyone() {
       selfdestruct(msg.sender);
       }
   }

A real-life example

• 0xbad, a notorious MEV bot.An anonymous attacker noticed a flaw in the bots arbitrage contract code, and drained 0xbad’s wallet “1,101 ETH”. The attacker noticed that “callFunction,” which is the function called by the dYdX router as a part of flashloan execution, wasn’t properly protected and allowed arbitrary code to be executed. The attacker used this to get 0xbad to approve all of their WETH for spender on their contract. The attacker then simply transferred the WETH out to their address. The attack has a nice story to read TBH, you can check it here
• Unprotected init() function was missing onlyOwner modifier, details.

Mitigation

• Implement Proper Access Controls: Carefully design and implement access control mechanisms within your smart contract. Clearly define who can perform specific actions and enforce these rules in the contract’s code.

Reference

• SWC-106
• SWC-105
• rekt.news

#3 Weak Access Controls:

Description

Contracts may implement access controls, but they are not robust enough to adequately restrict access to sensitive functions or data. Weak access controls often rely on simple checks that can be bypassed.

Code Example:

function claimAirdrop(bytes32 calldata proof[]) {
    bool verified = MerkleProof.verifyCalldata(proof, merkleRoot, keccak256(abi.encode(msg.sender)));
    require(verified, "not verified");
    require(alreadyClaimed[msg.sender], "already claimed");
    _transfer(msg.sender, AIRDROP_AMOUNT);
    //  "alreadyClaimed" is never set to true, so the claimant can issue call the function multiple times.
}

Mitigation

• Implement Proper Access Controls: Carefully design and implement access control mechanisms within your smart contract. Clearly define who can perform specific actions and enforce these rules in the contract’s code.

A real-life example

• On October 27, 2022 UvToken lost $1.5M due to insufficient access controls.

Reference

• https://medium.com/@numencyberlabs/loss-1-5-m-technical-analysis-for-uvtoken-attacked-83ae7c35f10e

#4 Privilege Escalation:

Description:

Privilege escalation vulnerabilities occur when a user can upgrade their own permissions within the contract, gaining access to functions or data they were initially restricted from. As common example of this is when an attacker takes ownership of the contract . Code Example:

A real-life example

• Enzyme Finance bug: Enzyme Finance implements meta transaction via OpenGNS. In Enzyme Finance Implementation, there wasn’t any verification of the provided forwarder’s address in the paymaster making any malicious forwarder makes many relayCalls to the RelayHub until the target fund’s Vault is drained. The bug and fix are well explained in this article.
• Implement Proper Access Controls: Carefully design and implement access control mechanisms within your smart contract. Clearly define who can perform specific actions and enforce these rules in the contract’s code.

Reference

Reference

• https://medium.com/immunefi/enzyme-finance-missing-privilege-check-bugfix-review-ddb5e87b8058

#5 Missing or Improper Input Validation

Description

Missing or improper input validation is a vulnerability in a smart contract that occurs when the contract fails to adequately check and validate the data and parameters supplied by users or external sources before processing them. This vulnerability can have significant security implications as it may allow malicious actors to exploit the contract’s weaknesses. Here’s a breakdown of the key aspects of this vulnerability:

Code Example:

contract UnsafeBank {
    mapping(address => uint256) public balances;
    // allow depositing on other's behalf
    function deposit(address _for) public payable {
        balances[_for] += msg.value;
    }
    function withdraw(address from, uint256 amount) public {
        require(balances[from] <= amount, "insufficient balance");
        // attacker can withdraw more than their balance. Also attacker can withdraw from any address because no checks for authorization as well 
        balances[from] -= amount;
        msg.sender.call{value: amout}("");
    }
}

A real-life example

SushiSwap RouteProcessor2 : This contract contained a vulnerability where it didn’t properly validate the route parameter provided by the user to the processRoute function. This vulnerability allowed an attacker to set the route to point to a malicious, attacker-controlled pool. With a malicious pool, the attacker can call swapUniV3, which will set the variable lastCalledPool to the address of its pool and call the swap function of the malicious pool. That swap function will call uniswapV3SwapCallback, which validates the sender by checking to see that they are the lastCalledPool. Since this value is set to the malicious pool’s address, its callback is accepted. With the ability to call back into the uniswapV3SwapCallback function, the attacker can construct transactions that drain tokens from the account of users that set up approvals for the new RouteProcessor2 contract. The attackers managed to steal about $3.3 million, and the scope of the attack was limited by whitehack hacks that frontrun malicious transactions.

Mitigation

To mitigate this vulnerability, smart contracts should implement robust input validation checks. This includes verifying the sender’s authority, checking parameter values against predefined constraints, validating external data sources, and ensuring that input doesn’t exceed specified limits.

Reference

• SushiSwap hack explained
• iThe Top 10 Most Common Vulnerabilities In Web3

Description

A signature replay attack, also known as a replay attack, occurs when an attacker takes a valid signature from one transaction and reuses it to authenticate a different transaction in the same chain or in differnt b blockchain network.

Code Example:

// missing noonce 
// SPDX-License-Identifier: MIT
pragma solidity ^ 0.8.17;

import "github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v4.5/contracts/utils/cryptography/ECDSA.sol";

contract Vault {
    using ECDSA for bytes32;

        address public owner;

    constructor() payable {
        owner = msg.sender;
    }

    function transfer(address to, uint amount, bytes[2]memory sigs) external {
        bytes32 hashed = computeHash(to, amount);
        require(validate(sigs, hashed), "invalid sig");

        (bool sent, ) = to.call{ value: amount } ("");
        require(sent, "Failed to send Ether");
    }

    function computeHash(address to, uint amount) public pure returns(bytes32) {
        return keccak256(abi.encodePacked(to, amount));
    }

    function validate(bytes[2]memory sigs, bytes32 hash) private view returns(bool) {
        bytes32 ethSignedHash = hash.toEthSignedMessageHash();

        address signer = ethSignedHash.recover(sigs[0]);
        bool valid = signer == owner;

        if (!valid) {
            return false;
        }

        return true;
    }
}


// missing chain id 

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

import "github.com/OpenZeppelin/openzeppelin-contracts/blob/release-v4.5/contracts/utils/cryptography/ECDSA.sol";

contract Vault {
    using ECDSA for bytes32;

    address public owner;
    mapping(bytes32 => bool) public executed;

    constructor() payable {
        owner = msg.sender;
    }

    function transfer(address to, uint amount, uint nonce, bytes[2] memory sigs) external {
        bytes32 hashed = computeHash(to, amount, nonce);
        require(!executed[hashed], "tx already executed");
        require(validate(sigs, hashed), "invalid sig");

        executed[hashed] = true;

        (bool sent, ) = to.call{value: amount}("");
        require(sent, "Failed to send Ether");
    }

    function computeHash(address to, uint amount, uint nonce) public view returns (bytes32) {
        return keccak256(abi.encodePacked(address(this), to, amount, nonce));
    }

    function validate(bytes[2] memory sigs, bytes32 hash) private view returns (bool) {
        bytes32 ethSignedHash = hash.toEthSignedMessageHash();

        address signer = ethSignedHash.recover(sigs[0]);
        bool valid = signer == owner;

        if (!valid) {
            return false;
        }

        return true;
    }
}

A real-life example

• Yearn Vaults on ETH POW forks that use the same chainId and a DOMAIN_SEPARATOR value that is calculated at contract deployment are vulnerable to replay attacks, details.

Mitigation

1. Use Nonces or Timestamps Incorporate nonces (random numbers) or timestamps into messages. Each message should have a unique nonce or timestamp, making it impossible for an attacker to replay the same message multiple times.
2. Use a chain-specific signature scheme such as EIP-155, which includes the chain ID in the signed message. This will prevent transactions signed on one chain from being valid on another chain with a different ID.

Reference

• replay attack explained
• https://coinsbench.com/signature-replay-hack-solidity-13-735997ad02e5

#7 Sandwich attacks (front-running/back-running)

Description

Sandwich attacks, also known as front-running and back-running, are types of malicious trading strategies that exploit the order execution process on decentralized exchanges (DEXs) and automated market makers (AMMs) in the cryptocurrency space. These attacks involve manipulating the order book to profit from the price movements caused by a victim’s trade. Here’s how sandwich attacks work:

Front-Running: In a front-running attack, an attacker monitors pending transactions in a blockchain’s mempool to identify a large trade about to occur. The attacker quickly places their own buy or sell order with slightly better terms than the victim’s trade. This causes the victim’s trade to execute at a less favorable price, while the attacker’s trade benefits from the price change caused by the victim’s order.

Back-Running: Back-running is a similar concept but involves the attacker placing their trade just after the victim’s trade has been confirmed but not yet included in a block. This allows the attacker to profit from the price change caused by the victim’s trade before it becomes part of the blockchain.

A real-life example

Exotic culinary: Hypernative systems caught a unique Sandwich Attack against Curve Finance

Mitigation

• Implement anti-front-running measures: Developers can implement technical measures to prevent front-running and other attacks. This might include measures such as batched orders, preventing attackers from seeing the details of pending trades.
• Use private mempool “ dark pool” to hide your transactions

Reference

• https://beincrypto.com/learn/sandwich-attacks-explained/
• https://systemweakness.com/caught-in-the-middle-understanding-and-preventing-defi-sandwich-attacks-bdf1d33e401d
• https://medium.com/@Hypernative/exotic-culinary-hypernative-systems-caught-a-unique-sandwich-attack-against-curve-finance-6d58c32e436b

#8 Price oracle manipulation

Description:

Price oracle manipulation is a form of attack or manipulation in decentralized finance (DeFi) and blockchain-based systems that involves manipulating the data provided by a price oracle to gain an unfair advantage or exploit vulnerabilities in smart contracts. Price oracles are external data sources that supply real-world data, such as asset prices or exchange rates, to smart contracts for various purposes, including decentralized trading and lending. Price oracle manipulation can have serious consequences, as it can lead to financial losses and destabilize DeFi platforms.

Code Example:

It is a price manipulation issue, which can be exploited by donation to incorrectly calculate the price as shown in the following figures.

A real-life example

• On May 28, 2023 Baby Doge lost $137k in a price oracle manipulation exploit.
• Zunami Protocol lost $2.1M as the project’s Ether- and USD-pegged stablecoins came under a price manipulation attack.

Mitigation

• Properly implement Decentralized Oracles e.g Chainlink: DeFi platforms and smart contracts can use multiple independent oracles to aggregate price data. This reduces the risk of manipulation because an attacker would need to manipulate multiple oracles simultaneously, making it more challenging.

Reference

• https://medium.com/immunefi/enzyme-finance-missing-privilege-check-bugfix-review-ddb5e87b8058
• https://rekt.news/zunami-protocol-rekt/
• https://github.com/calvwang9/oracle-manipulation

#9 Governance attacks

A governance attack, also known as a governance manipulation attack, is a type of attack that occurs within decentralized autonomous organizations (DAOs) and DeFi platforms where malicious actors attempt to manipulate or control the decision-making processes of the platform’s governance system for their own benefit. Governance in these contexts typically involves voting on proposals to make changes or decisions about the platform’s rules, parameters, and operations.
Governance attacks can take various forms, including allowing proposals to be executed without quorum, allowing execution of proposals without any voting step, or directly manipulating the votes of other participants. These attacks can compromise the decentralized nature of the protocol and lead to centralization of power, or result in financial benefits for the attackers. Governance attacks are particularly relevant in DAOs, where decision-making authority is distributed among token holders.

Code Example:

pragma solidity ^0.4.22;
pragma solidity ^0.8.13;
 
import "@oz/token/ERC20/ERC20.sol";
import "@oz/token/ERC20/utils/SafeERC20.sol";
import "@uniswap-v2-periphery/interfaces/IUniswapV2Router02.sol";
import "forge-std/console.sol";
 
contract Attacker {
   using SafeERC20 for ERC20;
 
   ERC20 usdc = ERC20(0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48);
   ERC20 bean = ERC20(0xDC59ac4FeFa32293A95889Dc396682858d52e5Db);
 
   function proposeBip() external payable {
       swapEthForBean();
       console.log(
           "After ETH -> BEAN swap, Bean balance of attacker: %s",
           bean.balanceOf(address(this)) / 1e6
       );
 
       depositAllBean();
       console.log(
           "After BEAN deposit to beanStalk, Bean balance of attacker: %s",
           bean.balanceOf(address(this)) / 1e6
       );
 
       submitProposal();
   }
 
   function attack() external {
       approveEverything();
 
       flashloanAave();
 
       console.log(
           "Final profit, usdc balance of attacker: %s",
           usdc.balanceOf(address(this)) / (10**usdc.decimals())
       );
      
       usdc.transfer(msg.sender, usdc.balanceOf(address(this)));
   }
}

A real-life example

• On April 17, 2022, Beanstalk suffered a $182 million governance attack where the attacker exploited the project’s protocol governance mechanism and drain funds from the pools. Source

Mitigation

• Establish a robust, well-defined, and transparent governance framework that outlines the decision-making processes, voting mechanisms, and rules for participation. Implement secure and tamper-resistant voting systems that ensure the integrity of votes.

Reference

• https://medium.com/@emanherawy/flash-loans-the-double-edged-sword-of-defi-5f9b46c45d6e
• https://de.fi/blog/beanstalk-losses-181-million-the-governance-attack-using-a-flash-loan-7459174dfa8e

#10 Faulty Calculation

Description

Errors or inaccuracies in the mathematical or computational logic within smart contracts or DeFi protocols. These errors can lead to unintended consequences, financial losses, or vulnerabilities that can be exploited by malicious actors.

Code Example:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract LendingPlatform {
    mapping(address => uint256) public userBalances;
    uint256 public totalLendingPool;

    function deposit() public payable {
        userBalances[msg.sender] += msg.value;
        totalLendingPool += msg.value;
    }

    function withdraw(uint256 amount) public {
        require(userBalances[msg.sender] >= amount, "Insufficient balance");
        
        // Faulty calculation: Incorrectly reducing the user's balance without updating the total lending pool
        userBalances[msg.sender] -= amount;
        
        // This should update the total lending pool, but it's omitted here.
        
        payable(msg.sender).transfer(amount);
    }
}

A real-life example

• On May 1, 2023, Level Finance was exploited due to a business logic issue and incorrect calculation, resulting in a total loss of $1.1M, link

Mitigation

• security Audits: Conduct thorough security audits of smart contracts and DeFi protocols by reputable auditing firms. Auditors can identify coding errors and logic flaws.
• Code Review: Review the smart contract code carefully to identify potential calculation errors. Enlist experienced developers or auditors for this task.
• Test Environments: Use testnet environments to thoroughly test smart contracts and DeFi protocols before deploying them on the mainnet. Test for various scenarios, including edge cases.
• Fuzzing testing : use fuzzing to generate all the possible values

These 10 vulnerabilities serve as lessons, highlighting the importance of robust security practices in blockchain development. It’s crucial to understand that these vulnerabilities can not only exist in isolation but are often combined in intricate ways to exploit smart contracts. By comprehending these weaknesses and the potential for their interplay, developers and auditors can better fortify blockchain systems, fostering a more secure and resilient landscape for the future of decentralized technology.

Reference

• https://blog.solidityscan.com/level-finance-hack-analysis-16fda3996ecb
• https://github.com/yearn/yearn-security/blob/master/disclosures/2022-09-06.md

10 smart contract vulnerabilities with code examples was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

Disclaimer

This article, “Understanding Smart Contract Vulnerabilities: A Case Study on the Euler Finance Hack” was prepared as part of Ekolance’s smart contract audit training. It is intended for educational purposes only.

Important note:

4/6/23: Hacker returns stolen funds, marking one of the largest DeFi recoveries.

Introduction

On March 13, 2023, Euler Finance, fell victim to one of the largest DeFi attacks in 2023. Euler Finance is a permissionless lending/ borrowing DeFi protocol operating on the Ethereum network. Euler Finance is over collateralized lending platform that support any erc20 token. The attacker could steal $197M in ETH, WBTC, USDC and DAI through flashloan and price manipulation.

This attack is ranked as the 6th largest attack in crypto based on the rekt.new leaderboard, and Euler’s TVL dropped from $264M to just $10M. In addition to Euler itself (whose token, EUL, fell over 50%), the fallout affected many projects integrated with Euler.

Timeline of Events

In 11:59 AM (GMT+3) · Mar 13, 2023, PeckShield raised an alarm about suspicious activity happening in Euler Finance protocol. After one hour, Euler Labs acknowledged the exploit, stating they were “working with security professionals and law enforcement”.

Intro to Euler Finance Protocol

In order to better understand the incident, we need to understand some important information about the protocol and how it works.

“Euler is a non-custodial permissionless lending protocol on Ethereum that helps users to earn interest on their crypto assets or hedge against volatile markets without the need for a trusted third-party” Euler doc.

Euler Protocol issues eToken and dToken whenever a user borrows /lends a token. When Euler protocol users perform lending or borrowing operations , they transact with two types of tokens: eTokens (which represent collateral) and dTokens (which represent debt).

Euler issues eTokens based on the types of funds deposited by users; dTokens automatically trigger on-chain liquidation when the platform holds more dTokens than eTokens.

The Euler protocol checks a user’s position on the platform “Health Score ‘’ by comparing the value of the user’s eTokens (collateral) to their dTokens (debt). If a user has a higher value of collateral compared to the debt, then the user is in a healthy position; otherwise, the user’s position may become subject to liquidation. This operation is called “liquidation checks’ ‘ and is very important for ensuring that the user can repay their debt and maintain the security of their assets.

When a position becomes under-collateralized, the platform can liquidate the user’s collateral to recover the debt. This process usually involves selling the collateral at a discount to incentivize liquidators to participate and facilitate the recovery of the debt.

Root Cause Analysis

In July 2022, Euler Finance team introduced eIP14, where the vulnerable code was introduced . The introduced changes were audited by Sherlock . This update has many changes but what we care about is the DonateToReserve function that enables depositing of eToken which basically burns eToken only , no dToken burn, leading to an incorrect conversion of borrowed assets to collateralized assets.

The attacker could perform his attack by leveraging the below features

1. Flash Loan
2. liquidity issue in the DonateToReserve function
3. liquidation discount of Euler Finance, check

Execution Flow ( reference ) :

1- Attacker gets 30 M DAI flash loan from Aave

2- Deploy Violator contract ( which would incur bad debt)

- Transfer the full 30m DAI loan balance to the violator

- Deposit 20m DAI to the DAI EToken of Euler Finance, receiving ~19,56m eDAI tokens

- Create a 200m artificial eDAI leverage, minting ~195,68m eDAI and 200m dDAI to the violator

- Repay 10m DAI on the violator’s position, causing their dDAI balance to go to 190m

- Create another 200m artificial eDAI leverage, minting ~195,68m eDAI and 200m dDAI to the violator

- Donate 100m eDAI to the reserve of the EToken

At this point, we have the following violator state:

• eDAI: ~310,93m
• dDAI: 390m

The liquidator will exploit this due to the calculations within the Liquidation module.

3- Deploy liquidator Contract:

- Liquidate the position, acquiring ~310,93m eDAI tokens and ~259,31m dDAI tokens

- Withdraw the full reserve of DAI tokens by burning the corresponding eDAI tokens on exchange rate of 0,97 eDAI per DAI

4- Repay the flash loan

5- Swap USDC and WBTC for DAI and ETH

Response and Mitigation

• Euler reached out to the attacker’s address via tx input data:

We understand that you are responsible for this morning’s attack on the Euler platform. We are writing to see whether you would be open to speaking with us about any potential next steps.

• Sherlock has taken responsibility for missing the vulnerability in their review of EIP-14 last year, and will pay a claim of $4.5M to Euler.
• The hacker returned the stolen funds and apologized through a series of encrypted messages.

Lessons Learned

• Testing for different simulated scenarios is crucial.
• Pushing updates to smart contracts is so dangerous and should be carefully tested and reviewed. Any tiny modification might open many back doors for dangerous vulnerabilities.

Resources:

• https://rekt.news/euler-rekt/
• https://medium.com/@omniscia.io/euler-finance-incident-post-mortem-1ce077c28454
• https://twitter.com/FrankResearcher/status/1635241492079067144
• https://blockapex.io/hack-analysis/euler-finance-hack-analysis/#:~:text=In%20the%20Euler%20Finance%20hack%2C%20the%20attacker%20exploited,loan%20%28the%20flash%20loan%29%20to%20the%20third%20party.
• https://www.chainalysis.com/blog/euler-finance-flash-loan-attack/
• https://www.euler.finance/blog/eulers-innovative-liquidation-engine

Understanding Smart Contract Vulnerabilities: A Case Study on the Euler Finance Hack was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

بسم الله الرحمن الرحيم ،

نبدا فى المستوى السادس فى لعبة ايثرناوت

وكالعادة نبدا بالمطلوب

The goal of this level is for you to claim ownership of the instance you are given.
  

Things that might help

Look into Solidity's documentation on the delegatecall low level function, how it works, how it can be used to delegate operations to on-chain libraries, and what implications it has on execution scope.
Fallback methods
Method id

نبص على الكود مع بعض

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Delegate {

  address public owner;

  constructor(address _owner) {
    owner = _owner;
  }

  function pwn() public {
    owner = msg.sender;
  }
}

contract Delegation {

  address public owner;
  Delegate delegate;

  constructor(address _delegateAddress) {
    delegate = Delegate(_delegateAddress);
    owner = msg.sender;
  }

  fallback() external {
    (bool result,) = address(delegate).delegatecall(msg.data);
    if (result) {
      this;
    }
  }
}

هو عاوزك تبقى مالك العقد ،

اه والله بس ادالك هنت ازاى تعمل ده ، من خلال

ال delegatecall
دايما كتير ناس بتتلخبط فيها بس علشان ابسطها لك تعالى نضرب مثال

تعالى نتخيل ان ليك جيران عندهم حفلة ما ، فانت قولت قشطه اروح اكلمهم علشان اهيص معاهم ، وااكل حلويات وروق على نفسي .
زى الباشا رحت خبطت عليهم ، فلقيتهم كلهم جم عندك ، فى الشقه .. والعيال بتننط ع الكراسي ، وفتحوا التالجه وطلبوا دليفرى على حسابك ، عملوا اللى نفسهم فيه بس على حسابك انت ، وشقتك انت اللى اتبهدلت

ده بالظبط اللى بيحصل لما عقد يكلم عقد من خلال delegatecall

العقد بينفذ اى حاجه موجوده ف العقد التانى اللى بيكلمه بس ف الحقيقه التغيير بيبتم ف العقد اللى بعت ، مش اللى اتبعت له

طبعا الخاصيه دى مفيده جدا جداا في مواطن معينه زى لما احب استخدم بروكسى كونتراكت واخلى العقد بتاعى قابل للتحديث، بس فى نفس الوقت خطيرة جداااااااااااا ﻻنك بتدى سلطه كبيرة جدا لكود ما انه يشقلب لك الدنيا ، وكانك عزمت حراميه فى بيتك ومنتظر منهم يشوفوا الفلوس فى اﻻرض يحطوها فى صندوق اﻻمانات

بعد م فسرنا فكرة ال delegatecall
تفتكروا ازاى نقدر ناخد ملكية العقد ؟
لوبصين هنلاقى العقد

contract Delegate {

  address public owner;

  constructor(address _owner) {
    owner = _owner;
  }
// اى حد بينادى ع الفنكشن دى بيبقى المالك للعقد
  function pwn() public {
    owner = msg.sender;
  }
}

ويبقى الحل ايه؟

contract Delegation {

  address public owner;
  Delegate delegate;

  constructor(address _delegateAddress) {
    delegate = Delegate(_delegateAddress);
    owner = msg.sender;
  }
/* pwn نكلم الفنكشن 
 بس من خلال الفنكشن دى*/
  fallback() external {
    (bool result,) = address(delegate).delegatecall(msg.data);
    if (result) {
      this;
    }
  }
}

طب هتبعت الفنكشن دى ازاى؟
، ببساطه لو هتعملها من الفرونت اند ، انت بس محتاج تجيب السجنتشر بتاعها، فيه طرق كتير تانيه بس دى كمثال

web3.eth.abi.encodeFunctionSignature("pwn()")

ونسلم الحل

وبكده انتهى المقال ، ونلتقى فى التحدى القادم

سلسلة تشرح حلول ايثرناوت

بسم الله الرحمن الرحيم ،

بقالى كتير مكتبتش ، للاسف . المهم

نبدا فى المستوى الخامس فى لعبة ايثرناوت

خلونا نبدا بالمطلوب

The goal of this level is for you to hack the basic token contract below.

You are given 20 tokens to start with and you will beat the level if you somehow manage to get your hands on any additional tokens. Preferably a very large amount of tokens.

  Things that might help:

What is an odometer?

لو بصينا على الكود مع بعض

// SPDX-License-Identifier: MIT
pragma solidity ^0.6.0;

contract Token {

  mapping(address => uint) balances;
  uint public totalSupply;

  constructor(uint _initialSupply) public {
    balances[msg.sender] = totalSupply = _initialSupply;
  }

  function transfer(address _to, uint _value) public returns (bool) {
    require(balances[msg.sender] - _value >= 0);
    balances[msg.sender] -= _value;
    balances[_to] += _value;
    return true;
  }

  function balanceOf(address _owner) public view returns (uint balance) {
    return balances[_owner];
  }
}

للوهلة اﻻولى ربما تقول الكود آمن والاختراق ده غير قابل للتنفيذ ،

بس هو عاوز يعلمك حاجمه مهمه قوى فى سوليدتى
overflow and underflow attack

ده لينك بيشرحها بشكل لطيف للمهتمين

فكرتها ببساطه ان الكومبيلر قبل اصدار 0.8 ، مكنش بيعمل فحص لحجم الداتا ، بمعنى انك لو اخترت لمتغير ما داتا تياب ع سبيل المثال unit8
ده يعنى ان المتغير ده مبيقدرش يحفظ اراقام اﻻ فى نطاق ( 0 ل 2**8–1)

ولو بعت له 2**8 ، اللى بيحصل ان الترانسزاكشن بيتم عادى والرقم بيعد من اﻻول ، يعنى الرقم بيرجع ف المثال اللى فوق 0

لذلك فى اﻻصدارات القديمه كان مهم جدا نشتغل بمكتبات بتظبط العمليات الرياضيه بشكل آمن زى
OZ afeMath

ملحوظه : ابتداء من اصدار 0.8 ، معدناش بنحتاج نستخدم المكتبات دى ، ﻻن ال
EVM
بقت بتشيك بشكل افتراضى ، ولو الرقم زيادة او اقل ، الترانساكشن بيفشل

بعد ما فسرنا فكرة التحدى ، يلا بينا نحل
لما جيت شوفت الاكونت بتاعى معاه قد ايه توكن لقيت معاه 21
ولما بصيت على data type
لقيتها بتاخد من 0لحد 2**256–1 لان

uint == uint256

int / uint: Signed and unsigned integers of various sizes. Keywords uint8 to uint256 in steps of 8 (unsigned of 8 up to 256 bits) and int8 to int256. uint and int are aliases for uint256 and int256, respectively.

حسب الدوكيمنتاشن الخاصه سوليديتى
ولو ان اللى بنحدد فيها وبنقول 256 بتوفر جاز اكتر ، بس ما علينا

فانا كنت اللى محتاجاه انى انقص من حسابي لحد ما يبقى -1 ، علشان يلف ويرجع ب 2**255

وقد كان

وسلمنا الحل

وبكده انتهى المقال ، ونلتقى فى التحدى القادم

Introduction:

In the fast-paced world of decentralized finance (DeFi), financial innovation meets blockchain technology, promising groundbreaking opportunities for open, permissionless, and borderless financial services. As a passionate blockchain developer and smart contract auditor, my journey into the DeFi domain has been fueled by the desire to understand its complexities and contribute to strengthening its security. My commitment to mastering DeFi has led me to embark on a transformative learning experience in the esteemed DeFi Talent Program. In this program, I acquire the expertise to explore one of the most powerful financial tools in the DeFi space: flash loans. This article delves into the captivating world of flash loans, dissecting their real-world applications, their pivotal role in DeFi’s expansion, and the security vulnerabilities they introduce.

To better understand flash loans, let’s start by explaining what a loan is in general and the difference between traditional centralized loans and decentralized loans.

Loans

A loan refers to a sum of money borrowed by one party (the borrower) from another (the lender), with the agreement that the borrower will repay the borrowed amount along with applicable interest or fees within a specified time frame. Loans are a common financial arrangement used by individuals, businesses, and governments to access funds for various purposes, such as acquiring assets, funding projects, or managing cash flow.

Traditional centralized Loans:

In the realm of traditional finance, this process ( mentioned above) is overseen by trusted centralized financial entities, often banks. Collateral for traditional loans may encompass tangible assets (real estate, vehicles) or financial assets (stocks, bonds). Typically, these loans involve a comprehensive credit check and assessment of the borrower’s creditworthiness, income, and financial stability.

Crypto Loans:

A cryptocurrency-backed loan is a financial arrangement where an individual or business utilizes their cryptocurrency holdings as collateral, which is locked within a smart contract, to secure a loan. This approach enables crypto holders to access liquidity without having to sell their assets. This way, they can benefit from potential price appreciation while still obtaining funds for various purposes. Such loans are typically facilitated through crypto lending platforms. While these platforms usually don’t require a traditional credit check, some may carry out limited KYC (Know Your Customer) processes to adhere to regulatory compliance.

With this foundation, let’s get to Flash loans :

Within the dynamic landscape of decentralized finance (DeFi), flash loans in 2020, also known as atomic loans, have emerged as a groundbreaking concept. These loans are revolutionizing liquidity access and utilization within blockchain ecosystems. Unlike traditional DeFi loans, flash loans offer instantaneous and uncollateralized borrowing capabilities. This empowers users to access substantial funds within a single transaction, presenting new opportunities for sophisticated financial operations such as arbitrage, yield farming, and liquidity provision — all executed at remarkable speeds.

In simple terms, a blockchain transaction to a smart contract can involve multiple internal transactions if the main transaction calls a function that triggers other transactions. With this feature, a user can send a transaction to a lending platform and secure a zero-collateral loan (flash loan). They can then utilize this borrowed capital for arbitrage opportunities in various DeFi protocols and, ultimately, repay the loan with interest to make a profit. If the user fails to repay the loan with interest, the entire transaction is invalidated. In this scenario, all stakeholders benefit: Lenders receive passive income, borrowers gain from zero-collateral loans, and lending protocols promote liquidity, innovation, and community engagement.

Top Flash Loan Providers:

Here are some of the leading flash loan providers in the DeFi ecosystem:

Aave:

Aave, a prominent DeFi lending platform, offers flash loans as part of its comprehensive suite of services. Aave was the first protocol to introduce real flash loans on Ethereum in 2020. Users can borrow a wide range of tokens, and a 0.09% fee is charged for each flash loan transaction.

dYdX:

Operating on the Ethereum blockchain, dYdX is a DeFi borrowing and lending platform. Unlike other lending platforms, dYdX does not impose a fee for flash loans. Borrowers are only required to repay the borrowed funds along with a nominal 2 Wei fee.

Vulnerabilities in Flash Loans: Unraveling the Risks

Despite these advantages, it’s important to recognize that flash loans also come with a range of business risks that warrant careful consideration by both users and platforms. These risks possess the potential to reverberate across the stability, reputation, and overall financial well-being of DeFi platforms. Lenders, too, may find themselves facing the danger of losing their liquidity.

Regrettably, the DeFi landscape has witnessed a surge in recent instances of flash loan attacks, serving as a stark reminder of the darker side of this innovation. These attacks are characterized by their low-risk, low-cost, and high-reward nature, where malicious actors take out substantial flash loans to manipulate the market and exploit various DeFi protocols, yielding significant profits with minimal cost. Let’s delve into some of the critical vulnerabilities.

Common Types of Attacks: Real Examples of Notable Flash Loan Exploits

Flash Loan Liquidity Drain Attack: The “Value DeFi” Incident

In November 2020, the Value DeFi protocol experienced a $6 million flash loan attack that targeted its liquidity pools. The attacker exploited vulnerabilities in the protocol’s smart contracts to manipulate token prices and drain significant funds from the pools.

This attack highlighted the risk of flash loans being used to manipulate prices and drain liquidity from vulnerable DeFi protocols.

Flash Loan Governance Manipulation Attack: Beanstalk incident

Flash loans can be leveraged to manipulate governance processes within DeFi protocols. Malicious actors may borrow significant funds through flash loans to gain a substantial amount of governance tokens, subsequently using these tokens to influence protocol decisions and control critical functionalities. On April 17, 2022, Beanstalk suffered a $182 million governance attack where the attacker exploited the project’s protocol governance mechanism and drain funds from the pools. Source

Flash Loan Price Manipulation Attack: The “PancakeBunny” Incident

In May 2021, the PancakeBunny protocol on the Binance Smart Chain fell victim to a flash loan attack that focused on price manipulation. The attacker used flash loans to manipulate the prices of USDT/BNB and BUNNY/BNB causing disruptions and inconsistencies in the protocol’s operations. This attack demonstrated how flash loans can be employed to exploit price discrepancies and disrupt the functionality of DeFi platforms. Source

Flash Loan Reentrancy Attack: $5.4 Million The “dForce” Incident

The dForce protocol suffered a significant flash loan attack in April 2020. The attacker utilized a reentrancy attack in Vyper_contract’s ‘remove_liquidity’ and ‘get_virtual_price’ functions. This allowed The attacker to take advantage of two issues: When sending ETH to the attacker’s contract, the fallback function is triggered, which calls other methods. During the callback, the LP Token total has not been updated, resulting in an incorrect price calculation. Source

Flash Loan Oracle Manipulation Attack: The “Elephant Money” Incident

Elephant Money, a stablecoin platform that employs the TRUNK token, was a victim of the flash loan assault, which manipulated a token price oracle, resulting in a $22.2 million loss. Source

Mitigating flash loan attacks and their associated risks within the decentralized finance (DeFi) ecosystem requires a multi-faceted approach that combines technical measures, risk management strategies, and community collaboration. Here are some important things to do:

1. Strong Smart Contract Audits:

Perform thorough audits of the smart contracts that enable flashloans. This involves reviewing the code to identify and address vulnerabilities, bugs, and potential attack vectors. Third-party security audits conducted by reputable firms can help identify and rectify any issues before the contracts go live.

2. Testing and Simulation:

Conduct extensive testing and simulation of flashloan transactions to identify any unforeseen scenarios or potential risks. Testing can help uncover bugs, ensure proper transaction sequencing, and validate the correctness of the smart contracts.

3. Liquidity Monitoring:

Monitor the liquidity within the platform closely, particularly during periods of high flashloan activity. A sudden drain of liquidity due to flashloans could impact the platform’s overall stability and the ability of other users to transact.

بسم الله الرحمن الرحيم ،

نبدا فى المستوى الرابع فى لعبة ايثرناوت

خلونا نبدا بالمطلوب

Claim ownership of the contract below to complete this level.

  Things that might help

See the Help page above, section "Beyond the console"

عاوزك تستحوذ على ملكية العقد ، ولما نبص على الكود

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract Telephone {

  address public owner;

  constructor() {
    owner = msg.sender;
  }

  function changeOwner(address _owner) public {
    if (tx.origin != msg.sender) {
      owner = _owner;
    }
  }
}

هنلاقى ان فيه فنكشن ، اى حد معدى ف الشارع يقدر نادى عليها ويستحوذ على ملكية العقد ، بس بشرط صغير

function changeOwner(address _owner) public {
    if (tx.origin != msg.sender) {
      owner = _owner;
    }
  }

التحدى ده بسيط جدا ، وهدفه يعرفك على نقطه مهمه جدا ، مين اللى بيكلم الفنكشن دى ، او بعبارة اكثر مهنيه

function caller

خلينا نتفق انه نظريا وعمليا ، طالما سوليدتى بتدعم انك العقود تعمل تواصل مع عقود اخرى ، او ما يسمى بال
external calls

فانا اقدر ابعت لفنكشن فى عقد ، يكلم عقد تانى ، اللى بدورة يكلم عقد تالت ، وهكذا

فلو افترضنا انى عندى سلسلة من العقود، كل عقد فيه فنكشن بتنادى على فنكشن فى العقد اللى بعدها ، فانا هيكون عندى التالى فى سوليدتى

  // ده هيكون اخر مرسل 
        msg.sender;
   //  انما ده هيكون اول مرسل 
        tx.origin;
 

طبعا لو انا معنديش غير

1 call
فده بيعنى ان

        msg.sender=tx.origin;

وبناء على ما سبق، مهم جدا ننتبه لما نبرمج العقد انه مينفعش انى لما احب استوثق من المرسل لاى سبب زى نقل ملكية او غيرها انى استخدام

tx.origin

ﻻن سهل جدا التلاعب بيها

طب علشان نحل التحدى ده محتاجين ايه ؟

محتاجين نعمل عقد بسيط يكلم العقد ده

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface ITelephone { 
  function changeOwner(address _owner) external;
}

contract TelephoneAttack { 
    
  function attack(address victim) public{
    ITelephone(victim).changeOwner(msg.sender);
  }
}

ونسلم النسخه