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](https://ethereum.org/en/developers/docs/evm/opcodes/) 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.


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


There are more and more scams and phising for address:


([Etherescan Link](https://etherscan.io/address/0xa7bf48749d2e4aa29e3209879956b9baa9e90570#tokentxns))

The contract address of EVM is determined by its deployment method. Two
instructions that deploy contracts exist: [`CREATE`](https://www.evm.codes/#f0?fork=shanghai) and [`CREATE2`](https://www.evm.codes/#f5?fork=shanghai).

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/{2^{16}}$.
So, if we try this $2^{16}$ 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](https://docs.ens.domains/ens-deployments) which established its root registry at the address `0x00000000000C2E074eC69A0dFb2997BA6C7d2e1e`.

As observed, there are `00 00 00 00 00 0` equating to $5.5bytes = 44 bits$.
This suggests that the team deploying ENS made approximately $2^{44}$, or around
$10^{13}$ attempts.

Other noteworthy implementations of this approach include:

1. The Eth2.0 deposit contract:
[`0x00000000219ab540356cbb839cbe05303d7705fa`](https://etherscan.io/address/0x00000000219ab540356cbb839cbe05303d7705fa#code)
2. Uniswap's Permit2:
[`0x000000000022d473030f116ddee9f6b43ac78ba3`](https://docs.uniswap.org/contracts/v3/reference/deployments),
indicating roughly `2^40 ~= 10^12` attempts.
3. The Blur.io NFT marketplace:
[`0x0000000000A39bb272e79075ade125fd351887Ac`](https://etherscan.io/address/0x0000000000a39bb272e79075ade125fd351887ac)
4. OpenSea:
[`0x00000000000000adc04c56bf30ac9d3c0aaf14dc`](https://etherscan.io/address/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:

<!-- TODO: Insert a diagram of the Requester-Worker protocol -->
### Registering a Request

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

<pre>
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.
}
</pre>

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:

<pre>
/**
* @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 {
...
}
</pre>

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](https://etherscan.io/address/0x13ad7efAfAcd463740222186f0f3DE6AD04B6787#readProxyContract#F3)

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

<pre>
function claimReward(
function claimReward(
bytes32 requestId,
address payable winner,
bytes32 sourceSalt
)
</pre>

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

<pre>
bytes32 salt = computeSalt(winner, sourceSalt);
</pre>

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`](https://etherscan.io/address/0x000000000000c826e64c795924eb735a892bd44b#code) |
| ImplV1 | [`0xcFbD663cf943ACE12646A0f92c53F5B21Db32833`](https://etherscan.io/address/0xcFbD663cf943ACE12646A0f92c53F5B21Db32833#code) |
| ProxyAdmin | [`0x85Be40f281E31c5B01D5E172bbA472bb27C2b240`](https://etherscan.io/address/0x85Be40f281E31c5B01D5E172bbA472bb27C2b240#code) |

### Goerli Testnet

| Contract | Address |
| -------- | -------- |
| D3CAF | [`0xd5e892d06b6933d93e74a4ac4ea9be84c99b2cd2`](https://goerli.etherscan.io/address/0xd5e892d06b6933d93e74a4ac4ea9be84c99b2cd2#code) |
| ImplV1 | [`0xc509ac56d04545b83f2e6fea160760f3307dea42`](https://goerli.etherscan.io/address/0xc509ac56d04545b83f2e6fea160760f3307dea42#code) |
| ProxyAdmin | [`0x26c9e4c75e740d9f771c0339dc48d893858add2a`](https://goerli.etherscan.io/address/0x26c9e4c75e740d9f771c0339dc48d893858add2a#code) |

## 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](https://github.com/d3servelabs/d3caf), and [verified on Etherscan](https://etherscan.io/address/0xcFbD663cf943ACE12646A0f92c53F5B21Db32833#code).

Please join our [Discord](https://discord.gg/EfVdm8YwDJ) for questions, feedback or contributions. We look forward to hear from you.

Zainan Victor Zhou, founder & CEO of D3ServeLabs

## Reference

- [0xdeadbeef: Tool used for computing vanity Safe addresses](https://github.com/nlordell/deadbeef)
-