What is ERC-8087? Understanding Encrypted Hashed Arguments for Privacy-Preserving Smart Contracts

Privacy remains one of blockchain's most challenging paradoxes. The transparency that makes decentralized systems trustworthy also exposes every transaction detail to public scrutiny. For applications requiring confidentiality, this creates fundamental barriers to adoption.

ERC-8087 introduces a standardized approach for executing smart contract functions with encrypted arguments through a decryption oracle pattern. This proposal addresses real-world needs like privacy-preserving order books and confidential transaction flows while maintaining the verifiability that makes blockchain valuable.

ERC-8087 defines a system where smart contracts can request function execution with encrypted arguments, optionally keeping the call descriptor itself confidential until execution. The standard separates two distinct components: reusable encrypted arguments and call descriptors that specify what function to execute and under what conditions.

The encrypted arguments structure bundles three essential elements. A hash commitment to the plaintext arguments provides on-chain verification. An identifier for the public key used in encryption enables proper decryption. The ciphertext itself contains the encrypted argument payload. This separation allows encrypted arguments to be stored on-chain, passed between contracts, and reused independently of specific function calls.

Call descriptors define execution parameters including the target contract address, function selector, and optional validity constraints like expiration blocks. These descriptors can remain plaintext or be encrypted depending on application requirements. When encrypted, only the decryption oracle can see which function gets called until fulfillment occurs.

The decryption oracle operates through a request-and-fulfill pattern. Users submit requests with encrypted arguments, triggering on-chain event emissions. An off-chain oracle service monitors these events, decrypts payloads according to access control policies, and calls back to execute the requested function. This design keeps decryption off-chain while maintaining on-chain verification and settlement.

The request phase begins when a user or smart contract calls the oracle with encrypted arguments and a call descriptor. The oracle assigns a unique request identifier and emits events that off-chain services monitor. This phase remains computationally cheap since no decryption occurs on-chain.

During the fulfill phase, the off-chain oracle operator decrypts the arguments, validates any access control requirements, and calls back into the on-chain oracle contract. The oracle then executes the target function with decrypted arguments, passing them alongside the request identifier. This pattern ensures that computationally expensive decryption happens off-chain while maintaining on-chain execution guarantees.

Target contracts receiving decrypted arguments can verify authenticity by checking the hash commitment. When arguments were initially encrypted, a hash of the plaintext was computed and stored. Upon receiving decrypted arguments, the contract recomputes the hash and compares it to the stored value. This verification ensures the decrypted arguments match what was originally committed, preventing oracle manipulation.

The standard supports an optional second factor parameter that enables advanced decryption schemes. In scenarios like sealed-bid auctions, this second factor prevents even the oracle operator from decrypting arguments before the reveal phase. Trust shifts from keeping secrets forever to ensuring timely and correct fulfillment.

Order book construction presents a compelling use case for ERC-8087. In traditional on-chain order books, every submitted order becomes immediately visible. This transparency enables front-running attacks where observers can insert competing orders ahead of legitimate ones.

ERC-8087 enables a confidential order submission phase where participants encrypt their proposals and submit them on-chain. During this phase, orders remain encrypted and unreadable. Once the submission window closes, the oracle decrypts all orders and builds the order book in a single transaction. This prevents front-runners from observing and exploiting individual orders.

The hash commitment mechanism ensures order integrity throughout the process. When submitting an encrypted order, the participant also provides a hash of the order details. After decryption, the smart contract verifies that the decrypted order matches the original commitment. This prevents the oracle from modifying orders or submitting fake ones.

Access control through the eligible caller list adds another protection layer. When encrypting arguments, producers can specify which addresses are allowed to request decryption. The off-chain oracle enforces this list, preventing unauthorized parties from decrypting captured orders. Combined with time-based validity constraints, this creates robust protection for order book construction.

Delivery versus payment transactions require coordinating asset transfers conditionally. Traditional implementations struggle with the timing problem where one party must transfer first, creating counterparty risk. Atomic swaps solve this but expose trading terms to front-runners and MEV extractors.

ERC-8087 enables confidential DvP flows where transaction parameters remain encrypted until execution conditions are met. A party can commit to delivering assets at a specific price without revealing the terms publicly. Once conditions trigger, the oracle decrypts and executes the transaction in a single block, eliminating front-running windows.

The standard's flexibility around call descriptors becomes particularly valuable here. Sensitive DvP flows might encrypt not just the amounts but also the target contract and function being called. This prevents observers from even knowing what type of transaction is pending until fulfillment occurs.

Reusable encrypted arguments support complex multi-party workflows. A single set of encrypted arguments representing payment terms could be referenced by multiple contracts. As the transaction progresses through different stages, each stage verifies the arguments match the original commitment without requiring re-encryption.

The EncryptedHashedArguments structure provides the foundation for ERC-8087's privacy features. It contains three fields that work together to enable verifiable encrypted execution. The argsHash field stores a commitment to plaintext arguments, computed as the keccak256 hash of the ABI-encoded argument payload. The publicKeyId identifies which public key was used for encryption, enabling proper key rotation and management. The ciphertext field holds the encrypted ArgsDescriptor.

The ArgsDescriptor structure that gets encrypted contains two components. An eligibleCaller array specifies addresses allowed to request decryption, with an empty array meaning any requester is permitted. The argsPlain field contains the actual argument payload that will be passed to the target function. This structure gets ABI-encoded and encrypted before being stored in the ciphertext field.

Producers of encrypted arguments must follow specific normative requirements. They compute argsHash as the keccak256 of the ABI-encoded arguments. They encrypt the complete ArgsDescriptor structure under the specified public key. They set the publicKeyId to identify the encryption key used. These requirements ensure different implementations can interoperate correctly.

The encryption algorithm and key management remain implementation-specific, similar to the approach taken by ERC-7573. This flexibility allows oracle operators to choose cryptographic schemes appropriate for their security models and performance requirements. Implementations should document how publicKeyId derives from underlying key material to enable proper key rotation and disaster recovery.

Call descriptors specify execution parameters independently from arguments. The CallDescriptor structure defines which contract and function will be called along with any validity constraints. It includes the target contract address, a 4-byte function selector, and an optional block number for expiration. Zero values for validUntilBlock indicate no explicit expiry.

Plain call descriptors remain readable on-chain from the moment of submission. This transparency works for applications where function calls themselves are not sensitive, only the arguments. Observers can see what contract and function will be called but cannot access the encrypted arguments until fulfillment.

Encrypted call descriptors wrap the CallDescriptor in an EncryptedCallDescriptor structure. This contains a publicKeyId identifying the encryption key and ciphertext holding the encrypted descriptor. The encryption must be of the exact ABI-encoded CallDescriptor structure. This level of encryption hides even the target contract and function until the oracle fulfills the request.

The choice between plain and encrypted call descriptors depends on application privacy requirements. Privacy-preserving applications requiring maximum confidentiality should encrypt call descriptors. Applications where the function being called is not sensitive but arguments are should use plain descriptors to reduce gas costs and complexity.

The oracle exposes four primary functions for managing encrypted calls. The requestCall function accepts a plain CallDescriptor, encrypted arguments, and an optional second factor. It returns a request identifier for tracking. The requestEncryptedCall function works similarly but accepts an encrypted call descriptor for maximum privacy.

Fulfillment functions allow the off-chain oracle to execute requested calls after decryption. The fulfillEncryptedCall function receives the request ID, plaintext call descriptor, and decrypted arguments. The fulfillCall function works with requests that had plain call descriptors. Both functions must be restricted so only the oracle operator can call them.

The oracle can reject requests through the rejectCall function, providing a reason code and optional details. Rejections might occur due to policy violations, failed access control checks, or technical errors. This explicit rejection mechanism prevents requests from hanging indefinitely.

Target contracts implement callback functions to receive decrypted arguments. The callback signature must be a function accepting uint256 requestId and bytes argsPlain parameters. The requestId enables correlation with the original request. The argsPlain contains the decrypted argument payload for verification and decoding.

The hash commitment mechanism provides security against oracle manipulation. When encrypted arguments are created, a hash of the plaintext arguments is computed and stored. This hash becomes part of the on-chain state before decryption occurs. After the oracle decrypts and submits arguments, the target contract recomputes the hash and compares it to the stored value.

A typical implementation stores a mapping from request IDs to argument hashes. When making the oracle request, the calling contract stores the argsHash associated with the new request ID. This happens in the same transaction to prevent race conditions where fast oracle operators could fulfill before the hash is stored.

The callback function receiving decrypted arguments performs verification. It looks up the stored hash using the request ID, recomputes the hash from the received argsPlain bytes, and requires they match. If verification passes, the function decodes argsPlain to extract typed arguments for business logic.

This pattern enables trustless verification even though decryption happens off-chain. The oracle operator cannot modify arguments because any changes would cause hash mismatches. The on-chain contract can trust the decrypted arguments are exactly what was originally committed, despite relying on an off-chain decryption service.

Many applications need to integrate ERC-8087 with contracts that cannot be modified. These contracts might use specific function signatures that don't match the standard callback pattern. Router contracts solve this integration challenge by acting as intermediaries.

A router contract implements the standard callback signature accepting requestId and argsPlain. It performs hash verification against stored commitments just like direct implementations. After verification, it decodes argsPlain into the typed arguments needed by the existing contract. Finally, it calls the original contract with its expected function signature.

This adapter pattern preserves compatibility with deployed contracts while adding ERC-8087 support. The router handles all ERC-8087-specific logic including verification and decoding. The original contract continues using its existing interface without modification. Users submit encrypted arguments through the router which coordinates with the oracle and final execution.

Router contracts can implement additional logic like access control, fee collection, or event emission. They serve as integration points where cross-chain intent systems could coordinate with privacy-preserving execution. The router pattern demonstrates how standards like ERC-8087 compose with existing DeFi infrastructure.

The optional second factor parameter enables sophisticated decryption schemes where not even the oracle operator can decrypt arguments before certain conditions are met. This proves particularly valuable for sealed-bid auctions and similar applications requiring absolute confidentiality until a reveal phase.

In threshold encryption schemes, multiple parties each hold a share of the decryption key. The encrypted arguments cannot be decrypted unless a threshold number of parties provide their shares. The second factor parameter can encode these key shares, allowing the oracle to combine them only when sufficient shares are provided.

Time-locked encryption uses the second factor to implement time-based decryption restrictions. Arguments might be encrypted in a way where decryption requires both the oracle's key and a time-specific value that only becomes available at a certain block height. This prevents premature decryption even by the oracle operator.

The encoding of second factors remains implementation-specific. Complex schemes might encode multiple factors as an array of bytes. Simple schemes might use a single value. The flexibility allows oracle implementations to support various cryptographic approaches while maintaining a standard interface.

Intent-based blockchain architectures represent users expressing desired outcomes rather than specifying exact execution paths. ERC-8087 complements intent systems by enabling private intent expression and fulfillment.

A user might express an intent to swap tokens at a certain rate without publicly revealing the rate until execution. The intent would include encrypted arguments specifying the rate and other parameters. Solvers competing to fulfill the intent would need to decrypt these arguments to determine if they can profitably execute the trade.

The access control mechanisms in ERC-8087 align well with solver competition models. Encrypted arguments can specify eligible solvers, preventing unauthorized parties from accessing intent details. This protects users from front-running while maintaining a competitive solver market.

Cross-chain intents particularly benefit from ERC-8087's privacy features. Moving assets across blockchains often reveals trading strategies and liquidity positions. Encrypting intent parameters allows stablecoin infrastructure to coordinate transfers confidentially until final settlement, improving both privacy and execution quality.

ERC-8087 requires trusting the oracle operator to decrypt correctly and fulfill requests faithfully. The on-chain contract can verify that decrypted arguments match hash commitments but cannot verify the decryption process itself. Applications must either trust the oracle operator or implement incentive mechanisms to ensure honest behavior.

Replay protection becomes important for preventing reuse of fulfilled requests. The validUntilBlock field in call descriptors provides one mitigation by expiring requests after specific block heights. Higher-level protocols should include nonces or sequence numbers in arguments to prevent replay across different contexts.

The standard explicitly avoids mixing or anonymization functionality. ERC-8087 defers argument disclosure until fulfillment but maintains full traceability after that point. On-chain indexers can correlate fulfilled requests with original requesters through request IDs. This design supports compliance and auditability while providing temporal privacy.

Access control enforcement happens off-chain at the oracle operator level. The eligibleCaller list inside ArgsDescriptor guides the oracle's decision to fulfill requests but cannot be enforced by on-chain logic. Applications requiring strong access control must trust the oracle operator to honor these restrictions or implement additional on-chain checks.

ERC-8087 operations involve several gas cost considerations. Request submission costs remain modest since they only store minimal on-chain state and emit events. The actual decryption happens off-chain where computational costs don't translate to gas fees. Fulfillment costs depend on the complexity of the target function being called.

Hash verification adds minimal overhead to callback functions. Computing keccak256 over the argument payload and comparing to stored values consumes only a few thousand gas. This makes verification practical even for complex argument structures.

Implementations may charge fees in ETH or ERC-20 tokens to cover oracle operational costs. Fee structures remain implementation-specific, allowing operators to price based on their cost models. Applications should account for these fees when designing user experiences.

Deployment addresses for test implementations exist on multiple networks including Ethereum mainnet, Polygon, and their testnets. These deployments enable developers to experiment with ERC-8087 without deploying their own oracle infrastructure.

ERC-8087 was designed to coexist with ERC-7573, an earlier decryption oracle standard focused on specific DvP use cases. Existing ERC-7573 implementations can be extended to support ERC-8087 without breaking compatibility with existing integrations.

This compatibility allows gradual adoption where applications can leverage ERC-8087's more flexible architecture while maintaining support for ERC-7573 workflows. Oracle operators can serve both standards from a single deployment, reducing infrastructure complexity.

The generic function execution mechanism in ERC-8087 represents a generalization of patterns from ERC-7573. Where ERC-7573 defined specific callbacks for DvP flows, ERC-8087 enables arbitrary function calls with encrypted arguments. This flexibility supports wider use cases while building on proven designs.

Developers implementing ERC-8087 support should start by generating encrypted hashed arguments off-chain. Oracle implementations may provide command-line tools or API endpoints for this purpose. The encryption process takes plaintext arguments, computes their hash, encrypts them with the appropriate public key, and outputs the EncryptedHashedArguments structure.

Smart contracts receiving encrypted arguments should store the argsHash immediately. This storage must happen before or during the transaction that requests decryption to prevent race conditions. The stored hash enables later verification when the oracle fulfills the request.

Callback functions must implement the standard signature accepting requestId and argsPlain parameters. These functions should retrieve the stored hash, verify it matches the received arguments, decode the arguments into typed values, and execute business logic. Error handling should account for mismatched hashes and unknown request IDs.

Testing should cover both successful fulfillment paths and error cases. Verify that hash mismatches properly revert transactions. Test access control enforcement through different calling patterns. Validate expiration handling for time-sensitive requests. Consider using testnets before deploying to mainnet.

Beyond order books and DvP flows, ERC-8087 enables several emerging use cases. Privacy-preserving DeFi applications can leverage encrypted arguments for confidential lending, private voting in governance, and anonymous donation systems.

Decentralized identity systems could use ERC-8087 to verify credentials without revealing underlying data. A user might prove they meet age requirements by submitting encrypted identity attributes. The oracle verifies the claim and executes relevant on-chain logic without exposing the user's actual age or identity documents.

Supply chain applications benefit from ERC-8087's ability to keep commercial terms confidential while maintaining on-chain settlements. Companies can commit to purchase orders with encrypted pricing and delivery terms. When goods are delivered, the oracle fulfills the order, revealing terms only to parties involved in settlement.

Future extensions might incorporate zero-knowledge proofs for additional privacy guarantees. Rather than trusting the oracle operator, cryptographic proofs could verify correct decryption without revealing arguments. This would transform ERC-8087's trust model while maintaining its flexible architecture.

ERC-8087 provides a practical standard for privacy-preserving smart contract execution. By separating reusable encrypted arguments from call descriptors and using a request-fulfill pattern with hash commitments, it enables applications requiring confidentiality without sacrificing verifiability.

The standard's flexibility in supporting both plain and encrypted call descriptors allows applications to balance privacy requirements against implementation complexity. The optional second factor enables advanced decryption schemes suitable for sealed-bid scenarios. Router patterns provide integration paths for existing contracts.

While ERC-8087 requires trusting oracle operators for decryption, the hash commitment mechanism ensures argument integrity. The standard makes clear its scope: deferring argument disclosure until fulfillment while maintaining full traceability afterward. This transparency about limitations helps developers make informed decisions.

As blockchain infrastructure matures to support real-world applications requiring confidentiality, standards like ERC-8087 become essential building blocks. The proposal demonstrates how thoughtful cryptographic design can add privacy features to transparent blockchains without compromising their fundamental strengths.

What makes ERC-8087 different from general-purpose encryption in smart contracts?

ERC-8087 standardizes the complete workflow for encrypted execution including argument structure, oracle interface, and verification patterns. Rather than just encrypting data, it defines how contracts request decryption, how oracles fulfill requests, and how targets verify decrypted arguments match commitments. This standardization enables interoperability between different oracle implementations and applications.

Can the oracle operator see my encrypted arguments before I submit them on-chain?

No. Arguments are encrypted off-chain by the user before submission. The oracle operator cannot decrypt them until a request is submitted that includes any required second factors. For sealed-bid applications, the second factor prevents decryption even by the oracle operator until the reveal phase, creating cryptographic enforcement of confidentiality periods.

How does ERC-8087 prevent front-running attacks?

By keeping arguments encrypted until execution, ERC-8087 prevents observers from seeing order details that could be front-run. The hash commitment ensures the oracle cannot modify arguments for its own benefit. Time-based validity constraints prevent orders from being executed at opportunistic moments. The combination protects against both external front-runners and potentially malicious oracles.

What happens if the oracle operator never fulfills my request?

Requests can include validUntilBlock parameters that automatically expire after certain block heights. Applications should implement timeout handling and potentially refund mechanisms for expired requests. The rejectCall function provides explicit rejection notifications. For critical applications, consider monitoring fulfillment times and implementing fallback execution paths or oracle redundancy.

Is ERC-8087 compatible with cross-chain applications?

Yes, ERC-8087 works well with cross-chain architectures. Each chain can host its own oracle instance. Cross-chain intent systems can use encrypted arguments to specify confidential transfer parameters. Router contracts can coordinate between ERC-8087 oracles and cross-chain messaging protocols, enabling private intent fulfillment across multiple blockchains while maintaining security.