Signing Intents
Last updated
Last updated
After creating intents, they must be signed before submission to the Verifier contract via the execute_intents function. This section explains the signing process.
As discussed in the , accounts in the Verifier contract are identified by their NEAR account (whether implicit, being derived from a public key, or named, like alice.near). Every account can add an arbitrary number of public keys. Every public key in a user's account can be used to produce signatures that authorize intents for that user. Proper key management is essential.
Digital signature algorithms vary significantly in design and application. Key differences include:
Key Generation: The type of the public/private key generation mechanisms, like RSA vs elliptic curves
Curve types: The type of curve within the elliptic curve, being a NIST curve, like secp256k1 from Bitcoin and Ethereum, or some Montgomery curve, like Ed25519
Message (payload) construction for verification: Given a payload and a specific algorithm, how do we construct the message so that anyone can verify it with the public key?
Given that the goal with NEAR Intents, with any choice from the above, is to make it as easy as possible to integrate other wallets and services, we have allowed on how to verify payloads. Each signature type corresponds to a wallet or service capable of verifying it.
For example, from the , you see ERC-191. This exists because Ethereum wallets, like Metamask, support the for off-chain data signing.
In the following subsections, we will discuss more available signature types.
A signed intent that is ready to be submitted to the blockchain looks something like this:
Nonce: base64 public_key: prefixed with the key type, then base58 signature: prefixed with the key type, then base58
signature: prefixed with the key type, then base58
Note that there is no public key, as the public key can be recovered from the signature and the data.
public_key: prefixed with the key type, then base58 signature: prefixed with the key type, then base58
The object uses the following encoding
authenticator_data: base64, url-safe
challenge: base64, url-safe
signature: prefixed with key type, being p256 or ed25519, following by the signature in base58 encoding
public_key: prefixed with the key type, then base58
public_key: prefixed with the key type, then base58 signature: prefixed with the key type, then base58
To support additional key or signature types, please contact the Near Intents team.
This object conforms to the enum. A signed intent can be one of the possibilities provided by this enum.
The object above follows the NEP-413 . This is an off-chain message signing standard that is recognized by NEAR wallets.
The object of this type is compliant with the for off-chain message signing.
This is a standard used by .
This object type is meant to be used with with . An object of this type looks as follows:
The can use either .
TonConnect follows the on TON.