Hi friends,

We are thrilled to announce our D3CAF Protocol V1 for developer beta testing,
coupled with a bounty to encourage issue reporting.

Introduction

D3CAF, short for "D3 Contract Address Foundry", is a smart contract service by D3Serve Labs designed to bolster the trustworthiness
of developers' contracts. It achieves this by calculating the salt in
CREATE2 to foundry a contract address with more zeroes. This strategy raises the barrier for potential fraudsters
attempting to deceive contract users.

Background

The number of smart contracts is on the rise as more DEX applications are
deployed.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

With more addresses, the risk of misidentification becomes significantly higher.

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

There are more and more scams and phising for address:

Image Not Showing Possible Reasons
  • The image was uploaded to a note which you don't have access to
  • The note which the image was originally uploaded to has been deleted
Learn More →

(Etherescan Link)

The contract address of EVM is determined by its deployment method. Two
instructions that deploy contracts exist: CREATE and CREATE2.

In particular, CREATE2 enables developers to deterministically compute the
address before executing the deployment transaction.

addr = hash(0xff ++ sender ++ salt ++ hash(bytecode))[12:]

In this equation, salt can be set arbitrarily, and hash refers to the
keccak256 function.

For any cryptographically secure hash function, changing salt can effectively
pseudo-randomize the output addr.

When we randomize the salt, there's a 50% chance of the first bit being zero.
Similarly, there's a 50% chance of the second bit being zero, and so on for each
bit, each considered independent. Consequently, each time we manipulate salt,
the odds of obtaining the first 16 bits (2 bytes) as zeros stand at

1/216.
So, if we try this
216
times, we anticipate one instance where the first 2 bytes
of the address are all zeros, denoted as 0x00 00.

More leading zeros imply more attempts at randomizing the output to achieve these
zeros.

This strategy is demonstrated in the ENS deployment which established its root registry at the address 0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e.

As observed, there are 00 00 00 00 00 0 equating to

5.5bytes=44bits.
This suggests that the team deploying ENS made approximately
244
, or around
1013
attempts.

Other noteworthy implementations of this approach include:

  1. The Eth2.0 deposit contract:
    0x00000000219ab540356cbb839cbe05303d7705fa
  2. Uniswap's Permit2:
    0x000000000022d473030f116ddee9f6b43ac78ba3,
    indicating roughly 2^40 ~= 10^12 attempts.
  3. The Blur.io NFT marketplace:
    0x0000000000A39bb272e79075ade125fd351887Ac
  4. OpenSea:
    0x00000000000000adc04c56bf30ac9d3c0aaf14dc

The D3CAF Service

The D3CAF service provides a mechanism for developers aiming to deploy a smart
contract with a lower address to enlist help from others in calculating salt
for them ("contract address foundrying"). Incentives are offered to reward these helpers, thereby potentially
creating a market for this service.

Here is a breakdown of our V1 service functionality:

Registering a Request

The service begins with a D3CAFRequest being registered in our D3CAFServiceV1 using
this data structure:

struct D3CAFRequest {
    address factory;        // The address of the factory.
    bytes32 bytecodeHash;   // The hash of the bytecode.
    uint256 expireAt;       // After this block, the request is considered expired and reward can be claimed.
    bytes32 initSalt;       // Initial salt
    RewardType rewardType;  // The type of reward.
    uint256 rewardAmount;   // The reward amount for the request. For Ethers the unit will be `wei`.
    address rewardToken;    // The reward token address. For ETH, this is Zero. Non-Zeros are reserved for ERC20 and future extensions.
    address payable refundReceiver;  // The address of the refund receiver.
}

The service request will be registered via registerCreate2Request. The information will
be checked in this function, the reward will be locked in the D3CAFService contract, and an
event OnRegisterD3CAFRequest will be emitted for any interested parties to monitor new
requests.

Registering a Response

Once the service request is registered and before it expires, the service request is
up for grabs for anyone who calculates the smallest contract.

If a worker calculates a new salt that yields a better result than the current bestSalt,
they can optionally submit the salt to be recorded on-chain by calling registerResponse,
which includes the following information:

   /**
     * @dev Registers a response for a request.
     * @param requestId The request ID.
     * @param salt The salt value.
     */
    function registerResponse(bytes32 requestId, bytes32 salt) external payable {
        ...
    }

Here, requestId comes from the OnRegisterD3CAFRequest event emitted during request
registration.

salt is the salt used in CREATE2.

The function will validate that newAddress was correctly generated from salt using
the CREATE2's computeAddress formula.

The sender will be retrieved from the request with requestId.

Salt and Source Salt

To avoid front-running for claiming reward, D3CAF requires the salt to be
computed from keccak256(abi.encodePacked(rewardReceiver, sourceSalt));

where the rewardReceiver is the address of receiver when rewards need to be claimed.

A convinient method was also provided by the deployed contract
computeSalt

It is important that such salt is computed from sourceSalt with this method to ensure the reward can be claimed.

Permissionless Competition for Responses

Once a response is registered, it becomes the current winner.
Anyone can register new responses so long as their new salt satisfy the following two conditions:

  1. The request has not expire yet.
  2. The new salt results in a new address that is less or equal to 1/16 to the latest best calculated address, which means the new addres is at leaset one more 0 in its heximal string representation.

Claiming the Reward

When the expireAt block numbrer is reached, the reward is ready to be claimed.

To claim the reward, the claimant must submit their receiving address in the

 function claimReward(
    function claimReward(
        bytes32 requestId, 
        address payable winner, 
        bytes32 sourceSalt
    )

Here, the stored salt will be checked to ensure it equals

bytes32 salt = computeSalt(winner, sourceSalt);

Once the validation is complete, the request will be cleared and the reward transferred.

Caveats, Limitations, and Future Work

Version 1 serves as a proof of concept. There are many other functionalities we believe
could enhance the service, such as:

  1. Creating more complete and persistent incentives for participation, which might lead to tokenomics
  2. Natively support collaboration and reward sharing via future versions of salt
    calculation.
  3. Employ several methods to support different contract bytecodes to deploy for the
    same bytecodeHash.
  4. Support other tokens as reward
  5. Support deploy contract right from this protocol.

Disclaimer

The D3CAF Protocol V1 contracts has not been thoroughly audited,
there might be critial bugs or fetal errors.
We greatly appreciate bugs reports. See bug-bounty for more information.

Deployment

Ethereum Mainnet

Contract Address
D3CAF 0x000000000000c826e64c795924eb735a892bd44b
ImplV1 0xcFbD663cf943ACE12646A0f92c53F5B21Db32833
ProxyAdmin 0x85Be40f281E31c5B01D5E172bbA472bb27C2b240

Goerli Testnet

Contract Address
D3CAF 0xd5e892d06b6933d93e74a4ac4ea9be84c99b2cd2
ImplV1 0xc509ac56d04545b83f2e6fea160760f3307dea42
ProxyAdmin 0x26c9e4c75e740d9f771c0339dc48d893858add2a

Bounty Program

The D3Serve Labs also provide a bug bounty for the following
reward for reporting bugs or security flaws.

Level Bounty Reward Explain
Kudo 0.1ETH Fixes are nice to have or minor improvements
Essential 0.3ETH Bugs that are affecting usage or security but don't require urgent upgrade for fixing it.
Critical 1ETH Bugs that requires an urgent upgrade
Fatal 20% of Fund Recovered Bugs or security flaws that requires recovery of fund

Concluding Remarks

The D3CAF Protocol was developed by D3Serve Labs Inc. The source code is publicly at its Github repo, and verified on Etherscan.

Please join our Discord for questions, feedback or contributions. We look forward to hear from you.

Zainan Victor Zhou, founder & CEO of D3ServeLabs

Reference