Hi @Moglu I think you are receiving the actual signature encoded as an hex string in hex_bytes. I think the idea of this endpoint is to get the signatures sent and the usigned transaction and combine them (ie, serialize them) in a way it can be broadcasted to the network.
That being said, I’m not part of the rosetta team so I might be wrong.
The Construction API was very purposely designed to never have access to private keys (unlike a traditional blockchain SDK). At scale, integrators end up maintaining n versions of the same signing logic for each SDK that uses the same curve:signature scheme (i.e. one for each blockchain using secp256k1:ECDSA and/or edwards25519:ed25519). When designing Rosetta, we felt very strongly about only allowing detached, “curve-based signing” so that it would be possible to support n blockchains with only 1 implementation per curve:signature scheme (greatly reducing the attack surface).
To get a high-level view of what this paradigm looks like, I recommend taking a look at the flow chart on the website that walks through the flow of the Construction API (make sure to click the “see more” button to see the signing step).
We hope to release an implementation of Bitcoin and/or Ethereum signing in the next month or so that you can reference while building (sorry for the delay)!
So i don’t understand the api how to sign a transaction.
In short, anyone using the Construction API must use their own signer (like the keys package) to create standardized signatures that will be combined and converted to a network-compatible transaction using /construction/combine. You can view an implementation of this flow in the rosetta-cli (used for automated Construction API testing).
The supported CurveTypes and SignatureTypes are defined in the rosetta-specifications (along with the required format).
If a curve or signature you use is not supported, follow these instructions!