API V1 suggestions

[ItsNickBarry]

Looks like you're still maintaining this based on recent activity. I'm updating my Hardhat plugin for Hardhat V3, and cleaning up some of the code that integrates with your API. I think this would be a good opportunity to release an API V1, with a few changes to help with standardization. Params like contractAddress and a fn called sendTransaction are non-standard, and make integration more difficult.

Example

This schema allows the query data to be passed through to the wallet essentially as-is, with just a few validations. Txn data encoding is also obviously still needed, but can be simplified by inferring the abi from the fnSignature parameter.

type QueryData = {
  fnSignature: string;
  fnArgs?: string[];
};

type Query = {
  chainId: string;
  to: string;
  value?: string;
  data?: Data | string;
};

const q: Query = parseQueryString(...);

const { chainId, to } = q;
const value = BigInt(q.value ?? 0);

let data: string;

if (typeof q.data === 'undefined') {
    data = '0x';
    // display message about sending tx with no data; if value > 0, display message about native token transfer
} else if (typeof q.data === 'string') {
    data = q.data;
    // display message about sending arbitrary data; maybe include a warning that the txn could be malicious
} else {
    const abi = generateAbi([q.data.fnSignature]);
    const args = q.data.fnArgs ?? [];
    data = abi.encode(q.data.fnSignature, args);
    // display function name and list of parameters for user to review
}

// pass this to wallet provider
const txn = {
    chainId,
    to,
    value,
    data,
}

Query type

chainId

ID of chain on which to send transaction. Should be processed as a hex string, to match behavior of JSON-RPC (eth_chainId), but can support dec strings in the URL query string.

to

Recipient address. No distinction between contract and EOA.

value

Native token to include. Parse string as BN, default to 0n if undefined.

data

Transaction data, with a few supported formats:

• undefined: no data, most likely a value transfer or a call to a contract fallback function
• string: pre-encoded data, just forward as-is
• QueryData object: minimal ABI data required to encode a contract function call (see below)

QueryData type

fnSignature

Full signature of contract function, formatted like transfer(address,uint256).

Could also support named parameters, like transfer(address to, uint256 amount).

Both formats preclude the need for ABI lookup, and if I were maintaining this I would drop that feature completely. However, it could still be useful for looking up parameter names if they're not included.

Bare function name (transfer) should not be supported because function overloading makes it ambiguous.

fnArgs

Array of function arguments. Default to empty array if undefined. Create an ABI using the fnSignature param and validate array length and contents.

[dawsbot]

Thanks for the thoughts on this @ItsNickBarry, I don't have the capacity to evaluate this atm but would love to in the coming weeks. Feel free to PR any partial code if you're able otherwise I'll get around eventually