JSON-RPC spec supports string, number, boolean, null, but the Ethereum JSON-RPC API does not (I believe). For most of its payloads it only supports numbers hex encoded as a string. I think there are a few places where it accepts/excepts an actual number, but it is unclear where these are other than by poking at it.
If this is going to be a thin wrapper around the Ethereum JSON-RPC API then you are right, it is probably best to have
ethereum.send just be an
// JSON-RPC requests
ethereum.send(method, params): Promise<result: Object?, error: Error?>
I think this should change to
// JSON-RPC requests
ethereum.send(method: string, params: Array<any>): Promise<any>;
Note in particular that it returns a promise of
any. If an error occurs during processing, then the promise will be rejected with an
Error from the provider. If an error comes back from the JSON-RPC API call, then
response.error will be wrapped in a JS
Error and the promise rejected with that. If no errors occurs then the promise will resolve with whatever was in the JSON-RPC
response.result. (all of this should be spelled out clearly using MUST wording like:
If the Ethereum JSON-RPC API returns response object that contains an
error property then the Promise MUST be rejected with an Error object containing the
response.error.message as the Error message,
response.error.code as a
code property on the error and
response.error.data as a
data property on the error.
If an error occurs during processing, such as an HTTP error or internal parsing error then the Promise MUST be rejected with an Error object containing a human readable string message describing the error and SHOULD populate
data properties on the error object with additional error details.
If there is no
error on the response and there is a
result on the response then the promise MUST resolve with the
response.result object untouched by the implementing wrapper.
Though, after typing the above I realize that some providers may not be interfacing with an external JSON-RPC API provider and instead may be fulfilling requests themselves, so someone should probably reword that to indicate that the above apply only if your provider is wrapping external calls, and if your wrapper is not talking to an external JSON-RPC API provider then it should ensure that the promise is rejected with an
Error that matches the above shape in the case of an error or it should resolve with an object that matches the JSON-RPC API object as specified in the Ethereum JSON-RPC documentation.