---
title: "Proposal: Introduction of parameters_ty to Transaction manager operation"
tags: protocol, tickets, memos
---

# Introduction of `parameters_ty` field to `Transaction` manager operation

## Motivation

Currently, `Transaction` does not specify the Michelson type of the value in `parameters` field. This information is not useful because of two reasons.
- For transactions to originated contracts, the type of `parameters` is always deduced from the `parameters` node in the contract script.
- For transactions to implicit accounts, the type of `parameters` is by conventions always `unit`.

However, there comes inconvience when we consider some future upgrades proposed against the protocol.
- Transferring tickets to implicit account. `Transaction` is a natural option to use for transferring tickets to implicit account. However, the type of the ticket content is an essential piece of information in order to perform ticket accounting. Without specification of this type in the manager operation itself, other options are possible but remains quirky.
- Upgradable contracts. There is an interest in upgrading contract scripts including the `parameters` type of a contract. Without explicit type declaration in `Transaction` in view of upgradable contracts, users may pass parameters of out-dated types without noticing.

This proposal aims at introduction of a venue for type ascription of the `parameters`, in a way that is backward compatible and provides a good foundation for introduction of features, including but not limited to those mentioned above, in the future.

## An optional `parameters_ty` field

We will introduce an optional `parameters_ty` field in the `Transaction` manager operation _in serialization_.

type _ manager_operation =
  (* ... *)
  | Transaction : {
      amount : Tez.tez;
      parameters : Script.lazy_expr;
      entrypoint : Entrypoint.t;
      destination : Contract.t;
      parameters_ty : Script.lazy_expr option;
    }
      -> Kind.transaction manager_operation
  (* ... *)

When submitting a `Transaction` manager operation with `parameters_ty`, it is expected to contain a Micheline node that can be parsed into a Michelson type.

### Type-checking in the prospective protocol

#### Transaction to implicit accounts
- When `destination` points to a `Contract (Implicit pkh)` and `entrypoint` is `default`, `parameters_ty` can be either `None` or `Some ty` where `ty` must be parsed into `unit`.
- As an illustrative example, say `destination` points to a `Contract (Implicit pkh)` and `entrypoint` is `receive_ticket`, the transfer is then a transfer with a ticket. In this case, `parameters_ty` must be `Some ty` where `ty` must be parsed into a Michelson `comparable_ty` type.
- Otherwise, the manager operation shall be rejected. This is subject to changes in future protocol upgrades where new case analysis can be applied to support more kinds of transfers.

#### Transaction to originated contracts
- When `destination` points to a `Contract (Originated pkh)`, `parameters_ty` can be either `None` which implies that `parameters` shall be parsed against the `parameters` type of the current contract script; or `Some ty` where `ty` must be parsed into a Michelson type and type equality between this `ty` and the existing parameter type under the given `entrypoint` must be satisfiable.

### Past `Transaction` manager operations
There shall be no migration necessary for past `Transaction` manager operations. Unspecified `parameters_ty` values in those operations are taken as `None`. The handling of those operations is backward compatible since we have covered this in the case analysis earlier.