Metadata Price/KB?

No sure where to put this.

I was reading about adding metadata to transactions and could not determine the price/KB. Anyone know? I saw the min’s in the post, but not the price/KB.

I just found this in Education/Transaction Fees
0,155381 Ada + 0,000043946 Ada/byte × 200 byte = 0,1641702 Ada.

So it looks like the min byte cost is also the cost/byte.

Also curious, is this how the price of a smart contract will be determined?


Only normal transactions and native scripts (multisig) have this storage based fee, the non-native scripts (smart contracts i.e. Plutus Core) will have execution fee on top of the storage fee.

Thanks for the clarification regarding the non-native script fee structure.

So I assume now that the storage fee for smart contracts will be will be calculated the same as normal transactions.

During the life of a smart contract that will require user input, such as deposit/payment or accept/decline, the contract will have to be called or run several different times as the contract proceeds. I am assuming there will be an execution fee for each of these user input interactions plus fees for internal logic.

Do you know how the execution fees will be applied/totaled and at what ADA rate?

I would appreciate any further info regarding the execution fees or directing me in a direction to query.


I am trying to explain it as simple as I can.
You need to think of abt running/executing a smart contract on chain as validating a transaction which only want money from a non-native script based input of transaction. So, a transaction which only pays to a smart-contract wont execute the smart-contract (sorry) and therefore only storage fee applied.

Secondly, also you need to think about it from a user perspective. E.g. using a wallet which must have that smart contract locally (off chain or grabbed from on-chain) for creating that type of transaction. That wallet can calculate the execution fee “off the chain”. Real validation must use a normal non-script input (or inputs that in sum have enough amount) for paying the execution when node validates that transaction.
So, at least two inputs, one for the reference to a past script payment UtxO, and one normal UtxO for paying the fee for the execution of the script and of course at least one output i.e. an address with the amount of ADA you want get from the smart contract.

And when the nodes validate that transaction, they run the script and that script which must be attached to that transaction to be run; as a transaction is stateless and have no clue about ledger state and only knows some protocol parameters and the current UtxO state i.e. all the UtxOs of the current validating node, which can differ slightly.

The validation i.e. running the script will use 3 parameters, the cost model, the budget from the paying inputs(s) and the data parameters. So, execution fee can be different to every user/transaction due to the possible difference in the user’s data parameter the script will use for its run.

The rate (cost model) is not decided yet, but it will be added in the goguen genesis file as two parameter, one for memory fee and the other for the execution steps.



Thank you very much for the detailed explanation.

I was not aware the cost model has not been set.

I was envisioning a smart contract loader of some type to drop the contract onto the chain, I did not realize it will be built into the Daedalus Wallet which will calculate the cost.

Again, thanks for your time to help me understand this new landscape.


The smart contracts wont built into Daedalus. Daedalus will use any smart contract created, it will just estimates its execution fee for creating a proper tx that the Cardano network (the nodes) will accept.

The smart contracts will be stored on the chain, to be precise: in transactions when they introduced to the network, i.e. a payment in a tx is referring to a smart contract address (as script hash), that smart contract (the whole script of which hash is equal to the to the script address) must be added to the transaction itself.

But, it can be created anywhere out of the chain (even Daedalus can have some feature, in the future, to create a smart-contract in itself), and it can be stored in Daedalus (as an imported or embedded/predefined script) or even it just can be just published on a webpage or in some github repo etc. So, there are lot of possibilities.
So, smart contracts can be verified off-the-chain, by any party.

Also, as I said, Daedalus must calculate the execution cost in advance, and only full-nodes are capable of doing that (atm) due to the fact that smart contracts (non-native scripts) currently only implemented as Plutus Core script (which is a Haskell derivative). iOS based wallet implementations cannot have this feature as Plutus Core use TemplateHaskell for converting Data structures between off-chain and on-chain. Android might have this feature enabled if they build that Haskell code as a library on a Haskell Stage2 (or 3 I cannot recall) android GHC compiler.

I am not sure how a complex smart contract could be fee-estimated in advance based on the user data (redeem Data) on non-full-nodes based wallets. I assume IOG will introduce some API for the relevant packages/tools/packages.

So, you need to distinguish between 3 parties:

  1. the validation nodes, which validate the tx-es that contain one or more smart-contracts (the transaction validation is stateless, have no clue about the global Ledger state so they need every info locally to be able to validate the script, that’s why the scrip together with it’s reference (the script address, in the input which is an UtxO, which is the hash of the script and some prefix) is included. This is not really accurate but leave it as it is now for simplicity
  2. The developers (who use Haskell capable tools for creating contract like Plutus Application Platform, playground etc.), who create the smart contracts.
  3. The users who use the already created smart contracts using some wallet-capable tools (directly for example Daedalus full-node wallet with some embeded, imported etc scripts or indirectly by for example a light wallet such as Yoroi through some API or similar or any mix and match. Who is aware of the Ledger state.


So informative, again thanks for this tutorial covering the basic mechanisms of utilizing smart contracts on Cardano.

As a newb to the the platform, so much to learn.