You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
The text was updated successfully, but these errors were encountered:
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 than2^53
is 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,
int64
is highest precision number type you can specify in OpenAPI (also not possible to useuint64
). To remedy this issue, we would need to encode allint64
numbers asstring
.Fortunately, this issue only will affect
BlockIdentifer.Index
andBlock.Timestamp
as all other "number-like" values that could come close to2^53
are 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 theTransaction
where anOperation
is present in, not a global index.The text was updated successfully, but these errors were encountered: