[SNIP] Deployer Contract Interface

📜 Development Proposals SNIPs
1

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 has been deployed (mainnet, goerli, goerli2, and integration), many teams from wallets to SDKs have already integrated it (Argent, starknet.py, starknet.js, nile, starknet-devnet, protostar, starknet-rs) which means they are exposing deployment functionalities to their users by calling this function:

@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:

@event
func ContractDeployed(
    address: felt,
    deployer: felt,
    unique: felt,
    classHash: felt,
    calldata_len: felt,
    calldata: felt*,
    salt: felt
) {
}
46 Likes
2

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.

22 Likes
3

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.

23 Likes
4

I guess the question belongs to the UDC proposal, 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

23 Likes
5

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

20 Likes
6

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 “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

18 Likes
7

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 ¯\(ツ)/¯

27 Likes