MESH
- Introduction
- POSTCreate a Request to Fetch Metadata
- POSTCreate Network Transaction from Signatures
- POSTDerive an AccountIdentifier from a PublicKey
- POSTGenerate an Unsigned Transaction and Signing Payloads
- POSTGet Metadata for Transaction Construction
- POSTGet the Hash of a Signed Transaction
- POSTParse a Transaction
- POSTSubmit a Signed Transaction
- POST
curl --request POST \
--url https://example.com/construction/combine \
--header 'Content-Type: application/json' \
--data '
{
"network_identifier": {
"blockchain": "bitcoin",
"network": "mainnet",
"sub_network_identifier": {
"network": "shard 1",
"metadata": {
"producer": "0x52bc44d5378309ee2abf1539bf71de1b7d7be3b5"
}
}
},
"unsigned_transaction": "<string>",
"signatures": [
{
"signing_payload": {
"hex_bytes": "<string>",
"address": "<string>",
"account_identifier": {
"address": "0x3a065000ab4183c6bf581dc1e55a605455fc6d61",
"sub_account": {
"address": "0x6b175474e89094c44da98b954eedeac495271d0f",
"metadata": {}
},
"metadata": {}
},
"signature_type": "ecdsa"
},
"public_key": {
"hex_bytes": "<string>",
"curve_type": "secp256k1"
},
"signature_type": "ecdsa",
"hex_bytes": "<string>"
}
]
}
'{
"signed_transaction": "<string>"
}Create Network Transaction from Signatures
Combine creates a network-specific transaction from an unsigned transaction and an array of provided signatures. The signed transaction returned from this method will be sent to the /construction/submit endpoint by the caller.
curl --request POST \
--url https://example.com/construction/combine \
--header 'Content-Type: application/json' \
--data '
{
"network_identifier": {
"blockchain": "bitcoin",
"network": "mainnet",
"sub_network_identifier": {
"network": "shard 1",
"metadata": {
"producer": "0x52bc44d5378309ee2abf1539bf71de1b7d7be3b5"
}
}
},
"unsigned_transaction": "<string>",
"signatures": [
{
"signing_payload": {
"hex_bytes": "<string>",
"address": "<string>",
"account_identifier": {
"address": "0x3a065000ab4183c6bf581dc1e55a605455fc6d61",
"sub_account": {
"address": "0x6b175474e89094c44da98b954eedeac495271d0f",
"metadata": {}
},
"metadata": {}
},
"signature_type": "ecdsa"
},
"public_key": {
"hex_bytes": "<string>",
"curve_type": "secp256k1"
},
"signature_type": "ecdsa",
"hex_bytes": "<string>"
}
]
}
'{
"signed_transaction": "<string>"
}Body
ConstructionCombineRequest is the input to the /construction/combine endpoint. It contains the unsigned transaction blob returned by /construction/payloads and all required signatures to create a network transaction.
The network_identifier specifies which network a particular object is associated with.
Show child attributes
Show child attributes
"bitcoin"
If a blockchain has a specific chain-id or network identifier, it should go in this field. It is up to the client to determine which network-specific identifier is mainnet or testnet.
"mainnet"
In blockchains with sharded state, the SubNetworkIdentifier is required to query some object on a specific shard. This identifier is optional for all non-sharded blockchains.
Show child attributes
Show child attributes
SigningPayload is signed by the client with the keypair associated with an AccountIdentifier using the specified SignatureType. SignatureType can be optionally populated if there is a restriction on the signature scheme that can be used to sign the payload.
Show child attributes
Show child attributes
Hex-encoded string of the payload bytes.
[DEPRECATED by account_identifier in v1.4.4] The network-specific address of the account that should sign the payload.
The account_identifier uniquely identifies an account within a network. All fields in the account_identifier are utilized to determine this uniqueness (including the metadata field, if populated).
Show child attributes
Show child attributes
The address may be a cryptographic public key (or some encoding of it) or a provided username.
"0x3a065000ab4183c6bf581dc1e55a605455fc6d61"
An account may have state specific to a contract address (ERC-20 token) and/or a stake (delegated balance). The sub_account_identifier should specify which state (if applicable) an account instantiation refers to.
Show child attributes
Show child attributes
The SubAccount address may be a cryptographic value or some other identifier (ex: bonded) that uniquely specifies a SubAccount.
"0x6b175474e89094c44da98b954eedeac495271d0f"
If the SubAccount address is not sufficient to uniquely specify a SubAccount, any other identifying information can be stored here. It is important to note that two SubAccounts with identical addresses but differing metadata will not be considered equal by clients.
Blockchains that utilize a username model (where the address is not a derivative of a cryptographic public key) should specify the public key(s) owned by the address in metadata.
SignatureType is the type of a cryptographic signature. * ecdsa: r (32-bytes) || s (32-bytes) - 64 bytes * ecdsa_recovery: r (32-bytes) || s (32-bytes) || v (1-byte) - 65 bytes * ed25519: R (32-byte) || s (32-bytes) - 64 bytes * schnorr_1: r (32-bytes) || s (32-bytes) - 64 bytes (schnorr signature implemented by Zilliqa where both r and s are scalars encoded as 32-bytes values, most significant byte first.) * schnorr_poseidon: r (32-bytes) || s (32-bytes) where s = Hash(1st pk || 2nd pk || r) - 64 bytes (schnorr signature w/ Poseidon hash function implemented by O(1) Labs where both r and s are scalars encoded as 32-bytes values, least significant byte first. https://github.com/CodaProtocol/signer-reference/blob/master/schnorr.ml )
ecdsa, ecdsa_recovery, ed25519, schnorr_1, schnorr_poseidon PublicKey contains a public key byte array for a particular CurveType encoded in hex. Note that there is no PrivateKey struct as this is NEVER the concern of an implementation.
Show child attributes
Show child attributes
Hex-encoded public key bytes in the format specified by the CurveType.
CurveType is the type of cryptographic curve associated with a PublicKey. * secp256k1: SEC compressed - 33 bytes (https://secg.org/sec1-v2.pdf#subsubsection.2.3.3) * secp256r1: SEC compressed - 33 bytes (https://secg.org/sec1-v2.pdf#subsubsection.2.3.3) * edwards25519: y (255-bits) || x-sign-bit (1-bit) - 32 bytes (https://ed25519.cr.yp.to/ed25519-20110926.pdf) * tweedle: 1st pk : Fq.t (32 bytes) || 2nd pk : Fq.t (32 bytes) (https://github.com/CodaProtocol/coda/blob/develop/rfcs/0038-rosetta-construction-api.md#marshal-keys)
secp256k1, secp256r1, edwards25519, tweedle SignatureType is the type of a cryptographic signature. * ecdsa: r (32-bytes) || s (32-bytes) - 64 bytes * ecdsa_recovery: r (32-bytes) || s (32-bytes) || v (1-byte) - 65 bytes * ed25519: R (32-byte) || s (32-bytes) - 64 bytes * schnorr_1: r (32-bytes) || s (32-bytes) - 64 bytes (schnorr signature implemented by Zilliqa where both r and s are scalars encoded as 32-bytes values, most significant byte first.) * schnorr_poseidon: r (32-bytes) || s (32-bytes) where s = Hash(1st pk || 2nd pk || r) - 64 bytes (schnorr signature w/ Poseidon hash function implemented by O(1) Labs where both r and s are scalars encoded as 32-bytes values, least significant byte first. https://github.com/CodaProtocol/signer-reference/blob/master/schnorr.ml )
ecdsa, ecdsa_recovery, ed25519, schnorr_1, schnorr_poseidon Response
Expected response to a valid request
ConstructionCombineResponse is returned by /construction/combine. The network payload will be sent directly to the construction/submit endpoint.
Was this page helpful?