# \[SNIP\] Deployer Contract Interface

**URL:** <https://community.starknet.io/t/snip-deployer-contract-interface/2772>\
**Category:** SNIPs\
**Created:** [November 12, 2022, 12:01am UTC](https://community.starknet.io/t/snip-deployer-contract-interface/2772 "2022-11-12T00:01:23Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![martriay](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/martriay/32/25_2.png) [@martriay](https://community.starknet.io/u/martriay)\
**Post date:** [November 12, 2022, 12:01am UTC](https://community.starknet.io/t/snip-deployer-contract-interface/2772/1 "2022-11-12T00:01:23Z")

</div>

> This will be properly formatted, written, and formulated later. This is a working draft to get the conversation going.

### Short

Let’s standardize the UDC interface so SDKs and wallets can easily support alternative deployer contracts.

### Long

Now that the [UDC](https://community.starknet.io/t/universal-deployer-contract-proposal/1864) has been deployed ([mainnet](https://starkscan.co/contract/0x041a78e741e5af2fec34b695679bc6891742439f7afb8484ecd7766661ad02bf), [goerli](https://testnet.starkscan.co/contract/0x041a78e741e5af2fec34b695679bc6891742439f7afb8484ecd7766661ad02bf), [goerli2](https://testnet-2.starkscan.co/contract/0x041a78e741e5af2fec34b695679bc6891742439f7afb8484ecd7766661ad02bf), and [integration](https://integration.starkscan.co/contract/0x041a78e741e5af2fec34b695679bc6891742439f7afb8484ecd7766661ad02bf)), many teams from wallets to SDKs have already integrated it ([Argent](https://github.com/argentlabs/argent-contracts-starknet/commit/acfc9154d7107777d9396c49b8f99db9c4465a73), [starknet.py](https://github.com/software-mansion/starknet.py/pull/464/commits/8841841ec3f1c4425932a95bdf4510088ca78103), [starknet.js](https://github.com/0xs34n/starknet.js/pull/379), [nile](https://github.com/OpenZeppelin/nile/pull/207/files#diff-8ec97b3a1c3f7fc3e205808742ef74f16501c22b45d31bd3481ef9087b815ac4R117-R122), [starknet-devnet](https://github.com/Shard-Labs/starknet-devnet/issues/296), [protostar](https://github.com/software-mansion/protostar/issues/1062), [starknet-rs](https://github.com/xJonathanLEI/starknet-rs/issues/232)) which means they are exposing deployment functionalities to their users by calling this function:

```cairo
@external
func deployContract{
    syscall_ptr: felt*,
    pedersen_ptr: HashBuiltin*,
    range_check_ptr
}(
    classHash: felt,
    salt: felt,
    unique: felt,
    calldata_len: felt,
    calldata: felt*
) -> (address: felt) {
}

```

But the UDC standard is also a unique, singleton contract with specific deployment requirements: `deployed_from_zero=True` and `salt=0`. Any other contract would not be the UDC, let alone “UDC compliant”.

Therefore, we should standardize the UDC interface into a more flexible Deployer Contract Interface that supports alternative deployer contracts (e.g. a factory that restricts by `classHash`). By doing so, any SDK or wallet supporting the UDC can immediately support alternative deployer contracts by simply accepting an address.

For completeness, deployer contracts following this standard MUST also emit the following event:

```cairo
@event
func ContractDeployed(
    address: felt,
    deployer: felt,
    unique: felt,
    classHash: felt,
    calldata_len: felt,
    calldata: felt*,
    salt: felt
) {
}

```

---

<div class="post-metadata">

**Author:** ![martriay](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/martriay/32/25_2.png) [@martriay](https://community.starknet.io/u/martriay)\
**Post date:** [November 12, 2022, 12:17am UTC](https://community.starknet.io/t/snip-deployer-contract-interface/2772/2 "2022-11-12T00:17:02Z")

</div>

The case for fixed-classhash factories to also follow this interface is to streamline SDK/wallet adoption as well as emitting the expected event. the `classHash` argument of the deployment function can simply be ignored.

---

<div class="post-metadata">

**Author:** ![ClementWalter](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/clementwalter/32/85516_2.png) [@ClementWalter](https://community.starknet.io/u/ClementWalter)\
**Post date:** [November 14, 2022, 7:58pm UTC](https://community.starknet.io/t/snip-deployer-contract-interface/2772/3 "2022-11-14T19:58:44Z")

</div>

I don’t understand the need for such a contract (the UDC) to be deployed. Why isn’t it enough to have deploy function in the account contract?  
Like multicalls were deployed contracts and they’re in Starknet integrated into the account contract.

---

<div class="post-metadata">

**Author:** ![martriay](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/martriay/32/25_2.png) [@martriay](https://community.starknet.io/u/martriay)\
**Post date:** [November 14, 2022, 10:00pm UTC](https://community.starknet.io/t/snip-deployer-contract-interface/2772/4 "2022-11-14T22:00:07Z")

</div>

I guess the question belongs to [the UDC proposal](https://community.starknet.io/t/universal-deployer-contract-proposal/1864), not here. In the context of this thread, I take the broader question: why deployer contracts instead of implementing `deploy` on accounts?

It’s a design choice to minimize account responsibilities in the spirit of keeping them simple as a proxy of safety (\*). Under this mindset, adding a `deploy` function didn’t seem mandatory, as external contracts might fulfill that role, such as specialized factories or the UDC.

Account developers can always implement deployment functions if they want so, deployer contracts support the ones that don’t.

(\*) not always true, hence _proxy_

---

<div class="post-metadata">

**Author:** ![Hazakura](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/hazakura/32/1398_2.png) [@Hazakura](https://community.starknet.io/u/Hazakura)\
**Post date:** [November 15, 2022, 2:42am UTC](https://community.starknet.io/t/snip-deployer-contract-interface/2772/5 "2022-11-15T02:42:23Z")

</div>

I agree with the message of the person above! don’t understand the need for such a contract (the UDC) to be deployed.

---

<div class="post-metadata">

**Author:** ![ClementWalter](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/clementwalter/32/85516_2.png) [@ClementWalter](https://community.starknet.io/u/ClementWalter)\
**Post date:** [November 15, 2022, 7:45am UTC](https://community.starknet.io/t/snip-deployer-contract-interface/2772/6 "2022-11-15T07:45:03Z")

</div>

my bad, my question was actually belonging to the original proposal that I missed when it passed. But I still don’t understand the rational behind all these proposals, neither the original one nor this one. I recognize myself in this comment [Universal Deployer Contract proposal 🪄 - #10 by milan](https://community.starknet.io/t/universal-deployer-contract-proposal/1864/10) “UDC is just a syscall wrapped in a smart contract”

In any case, it looks like others do recon the interest of the UDC, so I may just step aside from this discussion

---

<div class="post-metadata">

**Author:** ![martriay](https://dub1.discourse-cdn.com/flex005/user_avatar/community.starknet.io/martriay/32/25_2.png) [@martriay](https://community.starknet.io/u/martriay)\
**Post date:** [November 15, 2022, 8:14pm UTC](https://community.starknet.io/t/snip-deployer-contract-interface/2772/7 "2022-11-15T20:14:32Z")

</div>

_It is_ a syscall wrapped in a smart contract. And its purpose is to support all those contracts that do not implement a `deploy` function. This could be an account implementation aiming for simplicity/minimal responsibilities, or any other contract. maybe a DAO ¯\_(ツ)_/¯
