---
title: "OTP-005: Argument-addressable contracts"
description: "This proposal defines a way to address contracts by their arguments instead of their initial data"
sidebar:
  order: 5
---

This proposal defines a way to address contracts by their arguments instead of by their initial data.

## Motivation

Initial data can differ significantly from the arguments. This proposal allows us to avoid executing untrusted code from another contract in the context of the current one or executing TVM code off-chain for deployment, which could be risky in some cases.

## Specification

This specification defines a way to write arguments into an initial data cell to be read by the contract code during deployment.

### Prefix

The prefix is defined by the smart contract itself, but by default it is assumed to be a `single zero bit`. This prefix is used by the contract code to distinguish between deployed and not-deployed states.

### Arguments encoding

Arguments are encoded using [Auto Encoder](/ref/evolution/otp-004).

### Contract Requirements

- A contract MUST expose a `lazy_deployment_completed` get method that returns `true` if the contract is deployed and `false` otherwise.
- A contract MUST expose the `org.ton.deploy.lazy.v0` interface.

## Drawbacks

- Contracts could be in a semi-deployed state.
- There are multiple ways to write arguments, resulting in different initial data and different addresses.
- You can deploy a pre-initialized contract that would have a different address despite being fully functional.
- Gas usage upon deployment is unpredictable. Deployments are usually expensive, but this proposal makes them even more expensive.
