/construction/combine validations


There is some extra information in /construction/validations that’s strictly not required (at least to us) to build combine the witnesses and the unsigned tx in order to get a signed transaction. For example:

  • signing_payload
  • public_key
  • signature_type

Are we supposed to verify the transaction? If so, isn’t that the purpose of /construction/parse?


I’m going to answer this question with the assumption you are talking about /construction/combine based on the title of the topic.

When you say these fields “aren’t strictly required”, I assume you mean you can infer this information from the unsigned_transaction or there is only 1 way to do something (i.e. only one valid signature_type). In some implementations, this information is required so we always pass it along (instead of using a separate config to specify what we should send…we felt this was less confusing).

That being said, we highly recommend verifying wherever possible. If you know that certain public_keys, signing_payloads, or signature_types aren’t valid, you should error aggressively. The rosetta-cli does not do any fuzzing yet but it is something we are scoping for the next month or so to see if we can create invalid transactions. For example, does manipulating the unsigned_transaction cause an error or is it silently passed?

You are correct, /construction/parse does do its own set of validations independent of this (comparing the constructed transaction’s intent with the intent provided to /construction/preprocess). This should catch most issues related to incorrectly creating the transaction. However, it won’t catch any errors that manifest in ways not represented by Operations or Signers (as this isn’t visible to /construction/parse).

1 Like

Hi @patrick.ogrady, we are revisiting our validartions and there is a question regarding

Most of the construction endpoints (actually all of them besides metadata) are supposed to work offline, does that include querying for data to our local DB (which is running inside the single Docker image). For example, let’s suppose we want to validate the amount corresponds to the coin_identifier, can we do it? It’s offline in the sense that no request is going to be routed outside the container although it will query for data that was downloaded in the past.


You will not be able to query any DB (even the one running inside your Docker image) from any of the “offline” Construction API endpoints. I wrote about this on the website here:

You can check this information in your call to /construction/metadata as the operations used for construction are provided to /construction/preprocess (the Options returned can include directives to perform certain lookups in /construction/metadata). In our Bitcoin implementation, I check that the provided coin_identifiers are unspent, for example.

1 Like