I initially started implementing Rosetta 1.3 spec which only had the API to fetch the metadata and to submit a transaction blob it is quite straightforward as it has a minimal touching surface between the NEAR internal representation and Rosetta specification. Rosetta 1.4 introduced a whole lot of features and I wonder what is the minimal meaningful set there, e.g. would it be enough to have only transfer operations first (NEAR has the following operations [a.k.a. actions]: transfer tokens, stake, create an account, delete an account, add a key, delete a key, deploy a contract, call a method on a contract)
My take on this is:
- Implement /construction/submit and /construction/hash (it is quite straightforward as it just receives a blob of a signed transaction)
- Implement /construction/combine (again, it is quite straightforward as it applies a signature to an unsigned transaction blob and returns another blob)
- Implement /construction/derive (if needed) and /construction/metadata (it is straightforward as there are no requirements from Rosetta side)
- Implement /construction/preprocess and /construction/payloads (they are the most problematic as they require some translation of the intent expressed in Rosetta operations into native blockchain actions)
Does this make sense?
This is a great question @frolvlad! We do not have much documentation on this point so I’ll over-communicate here for the benefit of others.
We recommend implementing the Construction API endpoints in the following order:
The recommended order here is not based on difficulty, rather by hierarchy of design decisions required. In other words, coming up with an approach for converting
Operations into network-specific representations usually makes the design decisions for the following endpoints more or less trivial (as it is clear what network-specific info you will have to work with).
If you opt to implement more network-specific endpoints first (like
/construction/metadata), you may find that you will need to refactor your previous work to take into account additional data you found you needed during construction.
The recommended approach for supporting E2E flows is as follows:
- Account creation (if applicable)
- Staking (if applicable)
- Governance (if applicable)
- Anything else!
We highly recommend prioritizing basic functionality before diving into more complex chain interactions. In our experience, we’ve found that teams have a much better experience getting a basic flow working E2E and adding additional functionality iteratively instead of doing all planned functionality at once.
It may be more clearer if the order of the endpoints in the document is consistent with the order you listed. @patrick.ogrady
Yeah, we’ve gotten this feedback a lot. Apologize for any confusion! We are working on a “quick start guide” that provides much more guidance on how to approach implementation. In the meantime, I think this message is the best reference.
I look forward to the “quick start guide” very much, and it will be very helpful to the implementation.