2025-11-19 05:33:45
The addition of 'Vibe Coding' to the Collins Dictionary made headlines recently. But somewhat poetically, there is no entry for the consequences that can easily result from the celebrated praxis.
\ As an increasingly geriatric coder, my understanding gleaned from watching 'The YouTube' is that Vibe coding seems to involve writing software:
\ None of these things inherently indicate technical debt…but they do make it considerably more probable. And yet, technical debt mysteriously has no entry in the Collins dictionary.
\ One term has earned linguistic prestige; the other, despite being older, more widely used, and infinitely more expensive, remains unacknowledged.
\ It is almost as if the hype is more relevant than the reality.
'Vibe coding' captures the care free, improvisational side of programming; Write what feels good, and see where it goes. Technical debt captures the inevitable consequences of such approaches, and the moment you have to pay the piper.
\ And in fairness, maybe we are entering a new age, where these things don't matter as vibe-coded work can just be replaced with more vibe-coded work, and churn becomes the new norm.
\ I have no doubt that vibe coding can hold great value, and I have no doubt it will change the world. I also have no doubt the outcome will be as old as every quick fix that became someone else's long-term problem…even if the dictionary fails to name it
2025-11-19 05:32:27
Orem, United States, November 18th, 2025, /CyberNewsWire/--SecurityMetrics, a leading innovator in compliance and cybersecurity, today announced that its Shopping Cart Inspect (SCI) solutions has been selected as winner of the “Data Leak Detection Solution of the Year” award in the 9th annual CyberSecurity Breakthrough Awards program.
Conducted by CyberSecurity Breakthrough, an independent market intelligence organization, the annual program recognizes the most innovative companies, products, and technologies driving progress in the global information security industry.
SCI reduces the chances of an e-commerce skimming attack through the inspection of a website's shopping cart by a SecurityMetrics Forensic Investigator. The process involves the use of patented WIM Technology to determine if a website has fallen victim to JavaScript payment skimming.
WIM technology can detect web skimming at the moment it is triggered and will alert a merchant if a webpage has been compromised, through tools like Shopping Cart Inspect and Shopping Cart Monitor.
Using Inspect, SecurityMetrics Forensic Analysts review the rendered webpage code in a shopping cart URL to collect evidence of a skimming attack. Inspect is non-intrusive and website reviews are conducted without business interruption or merchant installation/intervention.
Following the inspection, SecurityMetrics Forensic Analysts create a risk report illustrating a risk rating and include a list of vulnerabilities, ranking them from medium to high-risk based on the CVSS scale.
The reports include a description of malicious JavaScript, identification of suspicious URLs on the website, a list of third-party domains participating in the e-commerce experience, and remediation recommendations. 24/7 technical support is also available to help with remediation.
“We understand how important it is to keep a business running as usual, so we designed SCI to discover website skimming attacks while still allowing business to continue uninterrupted. Our solution has been purpose-built to strengthen merchants, and our Forensic Analysts are at the forefront of emerging cyber threats,” said Brad Caldwell, CEO of SecurityMetrics.
\
“Our e-commerce investigations conducted by our expert Forensics Investigators will continue to identify trends that we will meet head-on with solutions that prioritize security technology for our valued global customer base.”
The 2025 awards program received thousands of nominations from more than 20 countries around the world, representing everything from disruptive startups to established global enterprises. This year’s winners embody the cutting edge of cybersecurity technology, delivering next-generation protection and resilience in today’s increasingly complex threat landscape.
“SecurityMetrics knows that keeping your website up and running is vital to your business,” said Steve Johansson, managing director, CyberSecurity Breakthrough. “SCI from SecurityMetrics helps businesses tackle vulnerabilities confidently and gives them the tools and support they need to identify malicious scripts, protect their business, and ensure customer trust. That makes SCI our choice for 2025’s ‘Data Leak Detection Solution of the Year!’"
SecurityMetrics secures peace of mind for organizations that handle sensitive data. They have tested over 100 million systems for data security and compliance. Industry standards don't keep up with the threat landscape, which is why SecurityMetrics hold their tools, training, and support to a higher, more thorough standard of performance and service. Never have a false sense of security.
Part of Tech Breakthrough, a leading market intelligence and recognition platform for global technology innovation and leadership, the CyberSecurity Breakthrough Awards program is devoted to honoring excellence in information security and cybersecurity technology companies, products and people.
The CyberSecurity Breakthrough Awards provide a platform for public recognition around the achievements of breakthrough information security companies and products in categories including Cloud Security, Threat Detection, Risk Management, Fraud Prevention, Mobile Security, Web and Email Security, UTM, Firewall and more. For more information, users can visit CyberSecurityBreakthrough.com.
Tech Breakthrough LLC does not endorse any vendor, product or service depicted in our recognition programs, and does not advise technology users to select only those vendors with award designations. Tech Breakthrough LLC recognition consists of the opinions of the Tech Breakthrough LLC organization and should not be construed as statements of fact. Tech Breakthrough LLC disclaims all warranties, expressed or implied, with respect to this recognition program, including any warranties of merchantability or fitness for a particular purpose.
Corporate Communications Manager
Landry French
SecurityMetrics
+1 801-995-6431
:::tip This story was published as a press release by Cybernewswire under HackerNoon’s Business Blogging Program. Do Your Own Research before making any financial decision.
:::
\
2025-11-19 05:18:20
Austin, TX/USA, November 18th, 2025/CyberNewsWire/--SpyCloud, the leader in identity threat protection, today released its report, The Identity Security Reckoning: 2025 Lessons, 2026 Predictions, outlining 10 of the top trends that will shape the cyber threat landscape in the coming year.
The predictions, based on observed and analyzed cybercrime activities from the past year and SpyCloud’s proprietary research and recaptured identity intelligence, shed light on the evolving tactics of cybercriminals and the identity-based threats security teams need to anticipate.
“Identity misuse is threaded throughout nearly every trend outlined in the report, from malware-driven session hijacking to synthetic identities and exposed non-human credentials,” said Damon Fleury, SpyCloud’s Chief Product Officer. “As attackers exploit this expanding footprint, organizations will be forced to rethink how they detect, respond to, and prevent identity threats across their entire ecosystem.”
SpyCloud’s Top 10 Identity-Driven Threats That Will Shape 2026:
\
\
"With the speed that technology moves, cybercrime evolves in lockstep and it’s equal parts fascinating to watch and challenging to keep up with,” said Trevor Hilligoss, SpyCloud’s Head of Security Research.
\
“The commoditization and influence of the dark web will continue to complicate things, making 2026 another nonstop year for defenders. Understanding the TTPs of these cybercriminals and gaining insights into the data they find most valuable will help these defenders continue to stay one step ahead and positively impact these efforts in years to come. But you can be sure we’ll track these shifts in real time and enable our customers and partners to effectively combat identity misuse in all of its forms.”
\
To explore the full report and see how SpyCloud’s holistic identity threat protection solutions help security teams prevent identity-based attacks like ransomware, account takeover, and fraud, users can click here.
SpyCloud transforms recaptured darknet data to disrupt cybercrime. Its automated identity threat protection solutions leverage advanced analytics and AI to proactively prevent ransomware and account takeover, detect insider threats, safeguard employee and consumer identities, and accelerate cybercrime investigations.
SpyCloud’s data from breaches, malware-infected devices, and successful phishes also powers many popular dark web monitoring and identity theft protection offerings. Customers include seven of the Fortune 10, along with hundreds of global enterprises, mid-sized companies, and government agencies worldwide.
Headquartered in Austin, TX, SpyCloud is home to more than 200 cybersecurity experts whose mission is to protect businesses and consumers from the stolen identity data criminals are using to target them now.
To learn more and see insights on your company’s exposed data, users can visit spycloud.com.
Account Director
Emily Brown
REQ on behalf of SpyCloud
:::tip This story was published as a press release by Cybernewswire under HackerNoon’s Business Blogging Program. Do Your Own Research before making any financial decision.
:::
\
2025-11-19 03:43:05
In the previous article, we explored how EIP-7702 lets you turn a regular wallet into a smart account without losing its address or transaction history — a key step toward evolving Ethereum accounts. Read it below.
https://hackernoon.com/turn-a-regular-wallet-into-a-smart-account-with-eip-7702?embedable=true
Now, it’s time to look at the standard that made Account Abstraction truly real: ERC-4337.
Account Abstraction has long promised to combine security, usability, and programmability into a single account model. With ERC-4337, this vision became possible without modifying the Ethereum protocol itself. Instead of changing consensus rules, it introduces a parallel transaction layer where smart contracts act as wallets with fully programmable validation logic. That unlocks a new design space — wallets that use passkeys instead of seed phrases, pay gas in USDC, or recover access via social recovery, all without relying on traditional EOAs.
Most articles about ERC-4337 are theoretical, which is fine for a high-level overview. But to truly understand it, we need to go deeper — into the EntryPoint architecture, how UserOperations are coordinated, and how a wallet can even deploy itself.
In this article, we’ll build ERC-4337 infrastructure from first principles: deploy an EntryPoint on a local chain, create a minimal ECDSA-based smart wallet, implement a factory for deterministic deployment, and build a simple pseudo-bundler to execute a complete UserOperation that deploys the wallet and sends ETH.
By the end, you’ll have working code and a clear understanding of how the pieces of Account Abstraction fit together in practice. \n
Traditionally, sending a transaction on Ethereum requires an Externally Owned Account (EOA) with a private key. Losing that key means losing access. Every transaction must be signed with ECDSA and paid for in ETH. Fingerprint login isn’t possible. Third-party gas payments aren’t either.
Account Abstraction fundamentally changes this model. The wallet becomes a smart contract that defines its own signature verification logic. It can validate a standard ECDSA signature, a passkey, a multisig approval, or any other rule implemented in Solidity.
However, smart contracts can’t initiate transactions directly — they still need an EOA. ERC-4337 solves this by introducing a new interaction flow built around the UserOperation format — a specialized type of transaction for smart accounts.
A UserOperation is sent to specialized nodes called bundlers. Bundlers collect operations, combine them into a single transaction, and forward it to the EntryPoint contract. The EntryPoint validates each operation, coordinates execution with smart accounts, and settles gas payments.
For the user, the process feels seamless — a simple action, a signature, and execution (or with session keys, sometimes even without signing).
Everything else — bundlers, EntryPoint logic, validation, and gas accounting — happens behind the scenes.
At the infrastructure level, however, this architecture forms the foundation of the next generation of smart wallets on Ethereum. \n
Foundry is used for working with ERC-4337 — a framework that simplifies Solidity development and automates testing and deployment.
If Foundry is not installed:
curl -L https://foundry.paradigm.xyz | bash
foundryup
Project initialization and dependency installation:
mkdir erc4337-wallet && cd erc4337-wallet
forge init --no-git
forge install eth-infinitism/account-abstraction
forge install OpenZeppelin/openzeppelin-contracts
The eth-infinitism repository contains the official ERC-4337 implementation, including the EntryPoint contract used across the standard’s ecosystem.
Current version — 0.8.
Configuration for foundry.toml:
[profile.default]
src = "src"
out = "out"
libs = ["lib"]
solc = "0.8.28"
evm_version = "cancun"
remappings = [
"account-abstraction/=lib/account-abstraction/contracts/",
"@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/"
]
\ These remappings specify where Forge should locate imported contracts. Without them, imports such as account-abstraction/core/BaseAccount.sol will not resolve correctly.
Starting Anvil — the local Ethereum node included with Foundry:
\
anvil
\ The terminal displays test accounts with balances of 10,000 ETH and their private keys. The first account serves as the bundler, and the second as the wallet owner.
At the center of ERC-4337 lies the EntryPoint — a singleton contract that coordinates the entire Account Abstraction flow. It acts as the execution hub between three key actors: bundlers, who collect and submit operations; smart accounts, which validate and execute them; and paymasters, who optionally sponsor gas.
The EntryPoint operates through a structured, multi-phase process designed for safety, efficiency, and deterministic behavior.
When a bundler submits a batch of UserOperations, the EntryPoint begins by validating each one.
During this phase, it calls the smart account’s validateUserOp() function. The validation must complete within strict gas limits and can only access predefined storage slots. These constraints protect bundlers from malicious operations that might consume unbounded gas or rely on state that could change before execution.
Inside validation, the account verifies the user’s signature — whether it’s ECDSA, a passkey, or a multi-sig approval — checks the nonce to prevent replay attacks, and confirms gas funding. The gas can be preloaded from the account’s EntryPoint deposit or covered by a paymaster.
If validation fails for any operation, the EntryPoint halts that UserOperation before it reaches the execution phase.
After successful validation, the EntryPoint executes each approved operation in sequence.
It calls the account’s execute() (or executeBatch() for multiple actions) with the user’s intended payload — sending ETH, calling another contract, or performing a complex DeFi transaction.
Each operation is isolated: if one fails, the rest of the batch continues unaffected. This isolation ensures predictable execution even in mixed batches submitted by bundlers.
Throughout the process, the EntryPoint precisely tracks gas consumption. Every smart account and paymaster must maintain a deposit with the EntryPoint to cover execution costs.
When operations run, the actual gas used is deducted from the respective deposit. The bundler is reimbursed — including a priority fee — guaranteeing that bundlers never lose ETH even if an operation reverts.
Stake requirements for paymasters and factories are also enforced at this level to protect the network from denial-of-service attacks.
All accounting — gas tracking, compensation, and refunds — happens atomically within the same transaction, ensuring complete consistency.
EntryPoint v0.8 is a non-upgradable contract responsible for managing all UserOperations.
It uses a deterministic address across every network:
The EntryPoint version 0.8 is a non-upgradable contract that handles all UserOperations. It has a deterministic address across all networks:
0x4337084d9e255ff0702461cf8895ce9e3b5ff108
\ This canonical address is deployed via the CREATE2 opcode through a deterministic deployment factory.
The factory itself lives at:
0x4e59b44847b379578588920ca78fbf26c0b4956c
and is available on most Ethereum networks, including Anvil by default.
The most reliable way to deploy EntryPoint is by using the official eth-infinitism repository, which provides the reference implementation for ERC-4337.
Clone the repository and install its dependencies with yarn or npm.
Then deploy the EntryPoint contract using the built-in scripts:
yarn hardhat deploy --network dev
\ After a successful deployment, the output should look similar to:
deploying "EntryPoint" (tx: 0x456b31559abf2560e9968663e4a73f0db03d1a0ff73019f71b61dcc6846f5f0c)...: deployed at 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108 with 5034766 gas
==entrypoint addr= 0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108
\
Ensure that the deployed EntryPoint matches the canonical address:
0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108
\ This deterministic address guarantees compatibility with existing Account Abstraction infrastructure — including bundlers, paymasters, and simulation tools.
Any deviation can cause UserOperations to fail validation or be rejected by bundler nodes.
The EntryPoint contract exposes a well-defined interface that different participants in the ERC-4337 flow interact with — bundlers, smart accounts, and paymasters. Each category of function has a distinct role in coordinating validation, execution, and gas management.
The main function used by bundlers is handleOps().
It processes a batch of UserOperations within a single transaction, acting as the operational core of ERC-4337.
function handleOps(
PackedUserOperation[] calldata ops,
address payable beneficiary
) external;
\ Here’s what happens behind the scenes:
Bundlers collect UserOperations from the ERC-4337 mempool, group them into an array, and submit them to the EntryPoint along with a beneficiary address — usually their own — where the gas reimbursement will be sent after successful execution.
The EntryPoint then:
In practice, this means multiple smart accounts can have their transactions executed atomically in a single Ethereum transaction, improving efficiency and reducing overhead for bundlers.
For scenarios that involve many signatures — such as multi-user applications or rollup-style batching — ERC-4337 introduces handleAggregatedOps():
function handleAggregatedOps(
UserOpsPerAggregator[] calldata opsPerAggregator,
address payable beneficiary
) external;
Signature aggregation is an advanced optimization that combines multiple cryptographic signatures into a single aggregated proof, reducing gas consumption.
For example, BLS signatures can represent 100 distinct signatures as one aggregated value, allowing the EntryPoint to verify them collectively rather than individually.
This approach is especially useful for large-scale systems such as wallet relayers or account networks where many users perform operations simultaneously.
Although aggregation won’t be implemented in our minimal setup, it’s an important part of ERC-4337’s scalability roadmap — a feature designed to make smart accounts as efficient as EOAs, even when executing at scale. \n
Smart accounts and paymasters interact with the EntryPoint through a built-in deposit system that ensures smooth gas accounting and prevents bundlers from taking on risk.
Each account or paymaster maintains a balance within the EntryPoint contract.
This balance is used to pay for gas whenever a UserOperation is executed.
function depositTo(address account) external payable;
function balanceOf(address account) external view returns (uint256);
function withdrawTo(address payable withdrawAddress, uint256 withdrawAmount) external;
\ When a smart account is deployed, a small amount of ETH is deposited to cover its operations.
The EntryPoint tracks these balances and automatically deducts the actual gas cost after each UserOperation.
Any unused funds can be withdrawn at any time.
This system keeps the payment process atomic and trustless: bundlers are reimbursed instantly, and accounts retain full control over their deposits.
To prevent replay attacks, each account has a nonce system:
function getNonce(address sender, uint192 key) external view returns (uint256);
The getUserOpHash function computes the hash that accounts must sign. It uses EIP-712 typed data hashing, which incorporates the EntryPoint address and chain ID into the hash. This prevents replay attacks—a UserOperation signed for one chain or EntryPoint instance cannot be replayed on another. The getNonce function retrieves the current nonce for an account with a specific key—ERC-4337 supports parallel nonce tracking so accounts can submit multiple independent UserOperation sequences.
With the EntryPoint interface in place, it’s time to see how it actually works in practice. Let’s build a minimal smart account — just enough logic to validate ECDSA signatures from a single owner.
This version isn’t production-ready. It’s intentionally simple — stripped down to the essentials — so we can focus on the mechanics of how smart accounts communicate with the EntryPoint. The contract extends BaseAccount from the official account-abstraction library and uses a hardcoded EntryPoint address for clarity. It’s the bare minimum setup, but it forms the foundation for everything that comes next.
In future iterations, we’ll evolve this base into a full smart wallet — adding WebAuthn for passkey authentication, paymasters for gas abstraction, and recovery logic for better UX. For now, simplicity wins. This minimal implementation is exactly what’s needed to understand how the pieces fit together.
A smart account is a contract that implements the IAccount interface, which requires a single method:
\
function validateUserOp(
PackedUserOperation calldata userOp,
bytes32 userOpHash,
uint256 missingAccountFunds
) external returns (uint256 validationData);
\
When the EntryPoint processes a UserOperation, it calls this method on the account contract. The account checks the signature, verifies the operation is authorized, and returns validation data. If validation succeeds, the EntryPoint then calls the account's execute method with the actual operation to perform. Note that execute() is not part of the IAccount interface itself—it's provided by the BaseAccount implementation, which also includes executeBatch() for multiple operations.
\n Our customSimpleAccount contract extends BaseAccount from the account-abstraction library, which provides the core implementation including the validateUserOp method and execution logic. Here's the complete implementation:
\
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.28;
import "account-abstraction/core/BaseAccount.sol";
import "account-abstraction/core/Helpers.sol";
import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
contract SimpleAccount is BaseAccount {
address public constant ENTRY_POINT_ADDRESS =
0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108;
address public owner;
constructor(address _owner) {
owner = _owner;
}
receive() external payable {}
function entryPoint() public view override returns (IEntryPoint) {
return IEntryPoint(ENTRY_POINT_ADDRESS);
}
function _validateSignature(
PackedUserOperation calldata userOp,
bytes32 userOpHash
) internal override returns (uint256) {
if (owner != ECDSA.recover(userOpHash, userOp.signature))
return SIG_VALIDATION_FAILED;
return SIG_VALIDATION_SUCCESS;
}
}
\ This implementation stores a single owner address and validates that UserOperations are signed by this owner using standard ECDSA signature verification. The EntryPoint address is hardcoded as a constant for simplicity. The account can execute arbitrary calls, transfer ETH, and manage its deposit with the EntryPoint through methods inherited from BaseAccount.
\n Now that we have our SimpleAccount contract, let's deploy it. Create a deployment script at
script/DeploySimpleAccount.s.sol:
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.28;
import "forge-std/Script.sol";
import "../src/SimpleAccount.sol";
contract DeploySimpleAccount is Script {
function run() external {
uint256 deployerPrivateKey = vm.envUint("PRIVATE_KEY");
address owner = vm.addr(deployerPrivateKey);
vm.startBroadcast(deployerPrivateKey);
SimpleAccount account = new SimpleAccount(owner);
console.log("SimpleAccount deployed:", address(account));
console.log("Owner:", owner);
vm.stopBroadcast();
}
}
Run the deployment:
forge script script/DeploySimpleAccount.s.sol --rpc-url http://localhost:8545 --broadcast
Note the deployed address—you'll need it for the next steps. In a real-world scenario, wallets are typically deployed through a UserOperation that includes factory initCode, allowing the wallet to be created and used in a single operation. We'll explore this pattern in the following articles
Before sending UserOperations, the account needs an EntryPoint deposit to pay for gas. Since our custom SimpleAccount is minimal and doesn't include helper methods like addDeposit(), we'll directly call the EntryPoint's depositTo() function:
First, export the necessary variables from your deployment:
# Export the account address from your deployment output
export ACCOUNT_ADDRESS=<your_deployed_account_address>
export OWNER_PRIVATE_KEY=<your_owner_private_key>
export ENTRYPOINT=0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108
Now fund the account:
# Send ETH to your smart account (for the account to hold directly)
cast send $ACCOUNT_ADDRESS --value 1ether --private-key $OWNER_PRIVATE_KEY
# Fund the EntryPoint balance by calling depositTo on the EntryPoint
cast send $ENTRYPOINT \
"depositTo(address)" $ACCOUNT_ADDRESS \
--value 0.5ether \
--private-key $OWNER_PRIVATE_KEY
# Check the account's deposit balance
cast call $ENTRYPOINT \
"balanceOf(address)(uint256)" $ACCOUNT_ADDRESS
The account can now pay for UserOperation execution from its EntryPoint deposit.
Let's create a simple UserOperation that transfers ETH. In a production environment, you'd use a bundler service, but for learning, we'll act as the bundler ourselves. This means we'll construct the UserOperation, simulate it to check validity, then submit it by calling handleOps directly from an EOA.
Understanding UserOperations
A UserOperation is the ERC-4337 equivalent of a transaction. Instead of being processed directly by the blockchain, it's submitted to bundlers who package it into an actual transaction. Here's the structure:
struct PackedUserOperation {
address sender; // The smart account
uint256 nonce; // Anti-replay protection
bytes initCode; // Factory address + creation data (empty for existing accounts)
bytes callData; // Data to pass to account's execute() function
bytes32 accountGasLimits; // Packed: verificationGasLimit || callGasLimit
uint256 preVerificationGas; // Gas overhead for bundler
bytes32 gasFees; // Packed: maxPriorityFee || maxFeePerGas
bytes paymasterAndData; // Paymaster address + verification data (empty for self-pay)
bytes signature; // Signature for validation
}
The gas fields deserve attention. verificationGasLimit covers signature validation, callGasLimit covers execution, and preVerificationGas compensates the bundler for the overhead of including your operation. The accountGasLimits and gasFees fields pack two values into one bytes32 for gas efficiency.
Create a TypeScript script send-userop.ts. The script will be built step by step.
Step 1: Setup and Configuration
First, configure the connection and wallets:
import { ethers } from "ethers";
import IEntryPoint from "./out/IEntryPoint.sol/IEntryPoint.json";
const ENTRYPOINT = "0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108";
const ACCOUNT = "0x..."; // Your deployed SimpleAccount
const OWNER_KEY = "0x...";
const BUNDLER_KEY =
"0xac0974bec39a17e36ba4a6b4d238ff944bacb478cbed5efcae784d7bf4f2ff80"; // Anvil #0
const provider = new ethers.JsonRpcProvider("http://localhost:8545");
const owner = new ethers.Wallet(OWNER_KEY, provider);
const bundler = new ethers.Wallet(BUNDLER_KEY, provider);
Step 2: Construct the UserOperation
Now build the UserOperation structure. We'll send 0.1 ETH to another address:
\
async function sendUserOp() {
// Setup EntryPoint contract
const entryPoint = new ethers.Contract(ENTRYPOINT, IEntryPoint.abi, bundler);
// Get nonce for replay protection
const nonce = await entryPoint.getNonce(ACCOUNT, 0);
// Encode the action: transfer 0.1 ETH
const recipient = "0x70997970C51812dc3A010C7d01b50e0d17dc79C8";
const value = ethers.parseEther("0.1");
const callData = new ethers.Interface([
"function execute(address,uint256,bytes)",
]).encodeFunctionData("execute", [recipient, value, "0x"]);
// Build UserOperation
const userOp = [
ACCOUNT, // sender
nonce, // nonce
"0x", // initCode
callData, // callData
ethers.solidityPacked(["uint128", "uint128"], [100000, 100000]), // accountGasLimits
50000n, // preVerificationGas
ethers.solidityPacked(["uint128", "uint128"], [1000000000, 1000000000]), // gasFees
"0x", // paymasterAndData
"0x", // signature (will be filled after signing)
];
// ... continue to next step
}
\ Step 3: Simulate the UserOperation
Before signing, bundlers simulate to verify the operation will succeed. The IEntryPointSimulations.simulateValidation() function executes validation logic but always reverts, even on success. This prevents state changes while returning diagnostic information in the revert data as a ValidationResult struct containing gas estimates and stake info.
The simulation calls your account's validateUserOp method (which we'll explore in depth in future articles) to check if the signature and other validation logic would pass. For now, understand that simulation is the bundler's safety net—it protects them from including invalid operations that would waste gas.
try {
const sim = new ethers.Contract(
ENTRYPOINT,
[
"function simulateValidation((address,uint256,bytes,bytes,bytes32,uint256,bytes32,bytes,bytes))",
],
bundler
);
await sim.simulateValidation.staticCall(userOp);
} catch (error: any) {
// Always reverts! Check if revert contains ValidationResult (success) or actual error
}
\ Step 4: Sign and Submit
\
After simulation confirms validity, sign the UserOperation and submit it to the EntryPoint:
async function sendUserOp() {
// ... previous code …
// Sign the UserOperation hash
// getUserOpHash returns an EIP-712 formatted hash - sign it directly without Ethereum message prefix
const userOpHash = await entryPoint.getUserOpHash(userOp);
const signature = owner.signingKey.sign(userOpHash).serialized;
// Update signature in the UserOperation array
userOp[8] = signature;
// Submit to EntryPoint as bundler
console.log("Submitting UserOperation...");
const tx = await entryPoint.handleOps([userOp], bundler.address);
const receipt = await tx.wait();
console.log("UserOperation executed:", receipt.hash);
}
sendUserOp().catch(console.error);
This step-by-step approach mirrors the real bundler workflow. Simulation is the key safety mechanism—it ensures bundlers never risk gas on invalid operations.
Now that we've sent a UserOperation and it executed successfully, we can verify that the gas payment mechanism worked correctly. The bundler's ETH balance should have increased (they received gas compensation from the EntryPoint), while the fees were withdrawn from the account's deposit balance on the EntryPoint. Let's check the balances to confirm this: \n
# Check account's EntryPoint deposit (decreased)
cast call $ENTRYPOINT \
"balanceOf(address)(uint256)" $ACCOUNT_ADDRESS \
--rpc-url http://localhost:8545
# Check bundler balance (increased with gas compensation)
cast balance 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266 --rpc-url http://localhost:8545
\ The EntryPoint deducted gas costs from the account's deposit and paid the bundler. This atomic payment mechanism ensures bundlers never lose money, even if a UserOperation's execution reverts.
We explored the EntryPoint— the core contract behind ERC-4337 that makes account abstraction work.
It validates operations, manages gas, compensates bundlers, and keeps every step atomic.
We looked at its main interfaces — handleOps, deposit management, and nonce utilities — and saw how they connect smart accounts to the network.
To put theory into action, we built a minimal SimpleAccount, deployed it with Foundry, funded it through the EntryPoint, and executed our first UserOperation end-to-end.
This foundation unlocks the next step: factories, bundlers, paymasters, and advanced wallet features like passkeys and social recovery.
ERC-4337 isn’t just a protocol — it’s the blueprint for the next generation of smart wallets.
2025-11-19 03:21:30
\ \
This section outlines the design of the VP (Vulnerability Prevention) framework. The design is based on an analysis of its essential design requirements.
A. DEFINITIONS
Let us define the secure code review points and a taxonomy for classifying code changes in this study.
==Secure Code Review Points.== It shows the three types of events that can be used to automatically trigger our classifier:
(1) a code change is initially sent for code review (or marked as ready for review or pre-submit testing);
(2) a new patch set is sent;
(3) and a code change is submitted. Its use can be refined by extra conditions (e.g., triggering only when a reviewer is specified). The classifier can also be manually triggered in several ways (e.g., by adding a tag to the change description, clicking a UI button or checkbox in the code
review service, or executing a shell command for a specific code change available in the code review service).
\ ==Classification of Code Changes==. In this study, we classify code changes into the following categories:
ViC (Vulnerability-inducing Change) for a code change that originally induced a vulnerability.
VfC (Vulnerability-fixing Change) for a code change that fixed the existing vulnerability.
LNC (Likely Normal Change) for a code change unlikely to induce a vulnerability. Notably, it includes changes that have not be identified as a known ViC at the time of analysis.
Additionally, VfLs (Vulnerability-fixing Lines) are the specific subset of source code lines edited by a VfC where the edits are essential to resolving the vulnerability.
\ B. DESIGN GOALS
Our approach is devised for use cases meeting the following conditions:
The target project experiences frequent software vulnerabilities with high potential consequences (e.g., costly fixes, product reputational damage, and impact on users).
The target project serves as an upstream source for downstream software projects used to build many integrated, end-user products or services (e.g., AOSP for Android smartphones and TVs).
Downstream projects often lack rigorous security testing (e.g., system fuzzing with dynamic analyzers [19]) due to the associated cost, technical expertise, and tooling constraints.
\ By detecting and blocking vulnerable code changes in the upstream target project, security engineering costs are reduced for downstream projects. The reduction encourages continued use of the upstream project and attracts additional downstream adoption, incentivizing the upstream project owners to invest in vulnerability prevention practices.
\ Under the targeted conditions, a classifier that estimates the likelihood of a vulnerability in a given code change proves effective. When the estimated likelihood exceeds a threshold, the respective code change is flagged for further scrutiny via secure code review or rigorous security testing. Our approach facilitates the detection of vulnerable code changes (e.g., with failing security tests) and consequently prevents their integration into the repository.
\ Our approach also offers seamless integration into postsubmit, secure code review processes. Code changes flagged by the classifier undergo additional offline review by security engineers or domain experts. It increases the likelihood of vulnerability detection within those changes. By applying the classifier post-submission but pre-release, targeted security reviews can focus on the highest risk code changes (based on the estimated likelihood). Our approach, thus, optimizes the secure code review process, reducing the overall security costs, while maintaining a robust security posture.
\ Considering those use cases, the key design goals for the classifier are set as follows:
Reasonable recall (>75% for ViCs). It ensures that a significant majority (>75%) of vulnerable code changes is detected, substantially reducing the overall security risk.
High precision (>90% for ViCs). Since vulnerable code changes are rare, incorrectly flagging 1 out of 10 code changes is generally acceptable for the security reviewers.
Low false positive ratio ( Normal code changes should rarely be flagged in order to maintain a streamlined review process for developers.
Fast inference time (e.g., It is to enable smooth integration into a code review service without causing developer-visible delays.
Low inference cost. To operate within typical open source project budgets for security infrastructure and tools, the inference should be done without having to use powerful or specialized ML hardware devices.
Infrequent retraining. Because the cost for model retraining is also important, monthly retraining on up to about a million samples is considered acceptable. It is to balance the accuracy maintenance (vs. daily retraining) with the affordability for most open source projects.
\ C. FRAMEWORK
Our VP framework is applicable to three distinct use cases:
==Pre-submit Security Review== is to utilize VP for assessing every code change sent for code review and identify likely-vulnerable code changes for additional secure code review by security domain experts.
==Pre-submit Security Testing== is to employ VP for assessing every code change sent for code review and identify likely-vulnerable code changes for extra security testing (e.g., static analysis, dynamic analysis, or fuzzing) before submissions.
==Post-submit Security Review== is to apply VP to all code changes submitted within a predefined period (e.g., daily or weekly) and isolate a set of likelyvulnerable code changes for an additional in-depth a secure code inspection by security domain experts. This use case differs from the existing post-submit time, security testing.
\ The pre-submit security review use case scenario has the highest complexity. Compared with post-submit use cases, pre-submit use cases have stricter requirements for inference time and online retraining (e.g., directly visible to code change authors vs. quality assurance team). Compared with the pre-submit security testing use case, the pre-submit security review use case has stricter accuracy requirements
(e.g., false positives for security testing mean mostly extra testing costs). Thus, it is used as the primary target for the framework design. To address the selected use case, the VP (Vulnerability Prevention) framework leverages its following key subsystems as depicted in Figure 1:
\ ==Code Review Service.== Authors initiate the code review process by uploading their code changes to a designated code review service. They then assign reviewers for their changes (see step 1 in Figure 1). The review service automatically triggers one or more review bots in response to the request of an author or reviewer, or when the uploaded code changes satisfy predefined conditions.
\ ==Review Bot(s).== Triggered review bots access the specific edits made by a source code change, along with relevant metadata of the code change and the baseline source code. To conduct in-depth analysis, bots usually leverage backend services for compilation, analysis, and testing of the change against the baseline. The new VP review bot utilizes those capabilities and forwards the gathered data to the classifier service. The classifier service then determines if the given source code change is likely-vulnerable or not.
\ ==Classifier Service.== When the classifier service istriggered, it utilizes the feature extractors and the data from the VP review bot to extract the pertinent features of the given code change. Subsequently, it performs inference using a model in order to estimate how likely the code change has vulnerabilities.
\ The classifier model uses the extracted features asinput and generates a binary output signal (i.e., ‘1’ indicates likely-vulnerable and ‘0’ indicates likely-normal). The output signal guides if additional security review (or security testing) is beneficial for the code change. The classifier service has an option to employ multiple models, combining their results (e.g., through logical operators or majority voting) for better accuracy.
\ ==Notification Service==. When a code change is classified as a likely-vulnerable change, the notification service posts a comment on the code change in the code review service. The comment alerts the code change author and existing reviewers to the potential presence of vulnerabilities, urging extra scrutiny.
\ If the target project maintains a dedicated pool of security reviewers, the notification service can automatically assign a member of the pool as a required reviewer for the target code change. The selected reviewer can be a primary engineer on a rotation or chosen through heuristics (e.g., round robin) for balanced distribution of security review workload.
\ D. EXTENSIONS
The VP framework supports extension for security testing and post-submit use cases:
==Selective Security Testing.== To extend the VP framework for selective, pre-submit security testing, an asynchronous test execution service is further employed. The execution service patches the given code change into the baseline code, builds artifacts (e.g., binaries), and executes relevant security tests against the build artifacts.
\ The execution service supports customization of security test configurations, including parameter tuning to target specific functions and adjust the maximum testing time. In implementation, a review bot is extended to generate tailored testing parameters. The extended bot leverages both the source code delta of the target code change and the vulnerability statistics of the target project. The resulting data-driven method allows the bot to use either the default parameter values or dynamically generate new ones, helping to optimize the balance between the security testing coverage and associated costs.
\ ==Post-Submit Use Case.== To extend the VP framework for post-submit time use cases, a replay mechanism is needed to process submitted code changes and invoke the VP review bot with the relevant input data. In particular, it requires tracking the code change identifiers from the git commit hashes if the used version control system is git. It uses the classification results to select a subset of code changes for further comprehensive security review.
:::info Author:
:::
:::info This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license.
:::
\
2025-11-19 03:21:18
:::info Author:
:::
\
This paper presents a framework that selectively triggers security reviews for incoming source code changes. Functioning as a review bot within a code review service, the framework can automatically request additional security reviews at pre-submit time before the code changes are submitted to a source code repository. Because performing such secure code reviews add cost, the framework employs a classifier trained to identify code changes with a high likelihood of vulnerabilities.
\ The online classifier leverages various types of input features to analyze the review patterns, track the software engineering process, and mine specific text patterns within given code changes. The classifier and its features are meticulously chosen and optimized using data from the submitted code changes and reported vulnerabilities in Android Open Source Project (AOSP). The evaluation results demonstrate that our Vulnerability Prevention (VP) framework identifies approximately 80% of the vulnerability-inducing code changes in the dataset with a precision ratio of around 98% and a false positive rate of around 1.7%.
\ We discuss the implications of deploying the VP framework in multi-project settings and future directions for Android security research. This paper explores and validates our approach to code change-granularity vulnerability prediction, offering a preventive technique for software security by preemptively detecting vulnerable code changes before submission.
The free and open source software (FOSS) supply chains for the Internet-of-Things devices (e.g., smartphones and TVs) present an attractive, economic target for security attackers (e.g., supply-chain attacks [20][21][28]). It is for instance because they can submit seemingly innocuous code changes containing vulnerabilities without revealing their identities and motives. The submitted vulnerable code changes can then propagate quickly and quietly to the end-user devices.
\ Targeting specific, widely used open source projects (e.g., OS kernels, libraries, browsers, or media players) can maximize the impact, as those projects typically underpin a vast array of consumer products. The fast software update cycles of those products can quickly take vulnerabilities in the latest patches of their upstream FOSS projects if rigorous security reviews and testing are not implemented before each software update or release. As a result, those vulnerable code changes can remain undetected and thus unfixed, reaching a large number of end-user devices.
\ From a holistic societal perspective, the overall security testing cost can be optimized by identifying such vulnerable code changes early at pre-submit time, before those changes are submitted to upstream, open source project repositories. Otherwise, the security testing burden is multiplied across all the downstream software projects that depend on any of the upstream projects.
\ Those downstream projects cannot rely on the first downstream projects to find and fix the merged, upstream vulnerabilities because the timeframe for such fixes and their subsequent upstreaming is unpredictable (e.g., in part due to the internal policies [22]). Thus, it is desirable to prevent vulnerable code submissions in the upstream projects.
\
A naïve approach of requiring comprehensive security reviews for every code change cause an unrealistic cost for many upstream open source project owners. It is especially true for FOSS projects receiving a high volume of code changes or requiring specialized security expertise for reviews (e.g., specific to the domains). To this end, this paper presents a Vulnerability Prevention (VP) framework that automates vulnerability assessment of code changes using a machine learning (ML) classifier.
\ The classifier model estimates the likelihood that a given code change contains or induces at least one security vulnerability. Code changes exceeding a threshold mean likely-vulnerable. The model is trained on the historical data generated by using a set of associated analysis tools. The model uses the common features used for software defect prediction as well as four types of novel features that capture:
(1) the patch set complexity,
(2) the code review patterns,
(3) the software development lifecycle phase of each source code file, and
(4) the nature of a code change, as determined by analyzing the edited source code lines. In total, this study comprehensively examines 6 types of classifiers using over 30 types of feature data to optimize the accuracy of the ML model.
\ To generate the training and test data, we leverage the security bugs discovered and fixed in the Android Open Source Project (AOSP)1 . It specifically targets the AOSP media project2 (i.e., for multimedia data processing) that was extensively fuzz-tested and thus revealed many security defects. A set of specialized tools is designed and developed as part of this study to:
(1) identify vulnerability-fixing change(s) associated with each target security bug, and
(2) backtrack vulnerability-inducing change(s) linked to each of the identified vulnerability-fixing changes. All the identified vulnerability-inducing changes are then manually analyzed and verified before being associated with the respective security bugs. The associated vulnerability-inducing changes are labeled as ‘1’, while all the other code changes submitted to the target media project are labeled as ‘0’ in the dataset.
\
The N-fold evaluation using the first year of data identifies random forest as the most effective classifier based on its accuracy. The classifier identifies ~60% of the vulnerabilityinducing code changes with a precision of ~85%. It also identifies ~99% of the likely-normal code changes with a precision of ~97% when using all the features for the training and testing.
\ The VP framework is then used as an online model retrained monthly on data from the previous month. When it is applied to about six years of the vulnerability data3 , the framework demonstrates an approximately 80% recall and an approximately 98% precision for vulnerability-inducing changes, along with a 99.8% recall and a 98.5% precision for likely-normal changes. This accuracy result surpasses the results achieved in the N-fold validation in large part because the online deployment mode can better utilize the underlying temporal localities, casualties, and patterns within the feature data.
\ In summary, 7.4% of the reviewed and merged code changes are classified as vulnerability-inducing. On average, the number of likely-normal changes requiring additional attention during their code reviews is around 7 per month. This manageable volume (less than 2 code changes per week) justifies the cost, considering the high recall (~80%) and precision (~98%) for identifying vulnerability-inducing changes.
\ The main contributions of this study include:
We explore and confirm the possibility of code change-granularity vulnerability prediction that can be used to prevent vulnerabilities by flagging likelyvulnerable code changes at pre-submit time.
We present the Vulnerability Prevention (VP) framework that automates online assessment of software vulnerabilities using a machine learning classifier.
We devise novel feature types to improve the classifier accuracy and reduces the feature data set by evaluating the precision and recall metrics.
We present the specialized tools to label code changes in AOSP, facilitating robust training and testing data collection.
We demonstrate a high precision (~98%) and recall (~80%) of the VP framework in identifying vulnerability-inducing changes, showing the potential as a practical tool to reduce security risks.
We discuss the implications of deploying the VP framework in multi-project settings. Our analysis data suggests two focus areas for future Android security research: optimizing the Android vulnerability fixing latency and more efforts to prevent vulnerabilities.
\ The rest of this paper is organized as follows. Section II provides the background information. Section III analyzes the design requirements and presents the VP framework design. Section IV details the design of the ML model, including the classifier and features for classifying likelyvulnerable code changes. Section V describes the tools developed to collect vulnerability datasets for model training and testing.
\ Section VI describes the data collection process using the tools, and characterizes the vulnerability issues, vulnerability-fixing changes, and vulnerability-inducing changes in an AOSP sub-project. Section VII presents the evaluation of the VP framework using an N-fold validation. Section VIIII extends the framework for real-time, online classification. Section IX discusses the implications and threats to validity. Section IX reviews the related works before concluding this paper in Section X.
\
This section outlines the code review and submission process of an open source software project, using AOSP (Android Open Source Project) as a case study. AOSP is chosen, considering its role as an upstream software project with the significant reach, powering more than 3 billion, active enduser products.
\ ==Code Change====.== A code change (simply, change) consists of a set of added, deleted, and/or edited source code lines for source code files in a target source code repository (e.g., git). A typical software engineer sends a code change to a code review service (e.g., Gerrit4 ) for mandatory code reviews prior to submission. A code change is attributed to an author who has an associated email address in AOSP. The change can also have one or more code reviewers. Both the author and reviewers have specific permissions within each project (e.g., project ownership status and review level).
\ During the code review process, a code change can undergo multiple revisions, resulting in one or more patch sets. Each patch set uploaded to the code review service represents an updated version of the code change. The final, approved patch set of the change can then be submitted and merged into the target source code repository.
\ ==Code Review.== The code change author can revise and resend the change as a new patch set for further review or approval by designated code reviewer(s). The key reviewer permissions include: a score of +1 to indicate the change looks good to the reviewer, a score of +2 to approve the code change, a score of -1 to tell that the change does not look good (e.g., a minor issue), and a score of -2 to block the code change submission.
\ Projects (e.g., git repositories or subdirectories in a git repository) can have custom permissions and review rules. For example, a custom review rule is to enable authors to mark their code changes ready for presubmit testing because often authors upload non-final versions to the code review service (e.g., to inspect the diffs5 and preliminary feedback).
\
:::info This paper is available on arxiv under CC by 4.0 Deed (Attribution 4.0 International) license.
:::
\
