Is your feature request related to a problem? Please describe.
Some blockchain teams have noted that precision may be lost for int64 numbers in some clients (like JS) if a number greater than 2^53 is populated since JSON defines numbers as float64.
Example (BlockIdentifier): https://github.com/coinbase/rosetta-specifications/blob/439b881859b0982bb6baf34a9666db1018d419f9/models/BlockIdentifier.yaml#L22-L27
Describe the solution you'd like
Unfortunately, int64 is highest precision number type you can specify in OpenAPI (also not possible to use uint64). To remedy this issue, we would need to encode all int64 numbers as string.
Fortunately, this issue only will affect BlockIdentifer.Index and Block.Timestamp as all other "number-like" values that could come close to 2^53 are already encoded as strings (ex: Amount.Value). Operation.Index (which is also encoded in int64) shouldn't run into this issue as it is relative to the Transaction where an Operation is present in, not a global index.
Is your feature request related to a problem? Please describe.
Some blockchain teams have noted that precision may be lost for
int64numbers in some clients (like JS) if a number greater than2^53is populated since JSON defines numbers asfloat64.Example (
BlockIdentifier): https://github.com/coinbase/rosetta-specifications/blob/439b881859b0982bb6baf34a9666db1018d419f9/models/BlockIdentifier.yaml#L22-L27Describe the solution you'd like
Unfortunately,
int64is highest precision number type you can specify in OpenAPI (also not possible to useuint64). To remedy this issue, we would need to encode allint64numbers asstring.Fortunately, this issue only will affect
BlockIdentifer.IndexandBlock.Timestampas all other "number-like" values that could come close to2^53are already encoded as strings (ex:Amount.Value).Operation.Index(which is also encoded inint64) shouldn't run into this issue as it is relative to theTransactionwhere anOperationis present in, not a global index.