Looking at the tests, I didn’t see a test for 1 yoctoNEAR deposit, which is quite common pattern in NEAR to require the transaction to be signed with a full access key. There are also a few other corner cases, so here is the list of suggested test cases for the NEAR amounts:

• 1 yoctoNEAR (function call)
• 1M NEAR - often used in delegation to stake (function call, transfer, stake actions)
• 0.00001 NEAR - often used to deposit for storage (function call)
• 1234.56 NEAR - often used for regular transfers

Various

• #2

Existing functionality

• congruent behaviour on INS_GET_PUBLIC_KEY and INS_GET_WALLET_ID - #4
• #5 , assert_eq!(mem::size_of::<Transfer>, 16)
• assert_eq!(mem::size_of::<TransactionPrefix>, 224)
• question: should public_key, nonce, block_hash fields of transaction prefix be displayed as well
• #6 , assert_eq!(mem::size_of::<CreateAccount>, 0)
• question: can AccountId be Secp256K1PublicKey representation as hex string 128 bytes long?
• #7 , assert_eq!(mem::size_of::<DeleteAccount>, 76)
• #8, assert_eq!(mem::size_of::<DeleteKey>, 65)
• #9, assert_eq!(mem::size_of::<Stake>, 88)
• #10, assert_eq!(mem::size_of::<AddKey>, 88), assert_eq!(mem::size_of::<FunctionCallPermission>, 328)
• #11
• #12, assert_eq!(mem::size_of::<DeployContract>, 56)
  • TODO: add print of contract Vec<u8> SHA256 in near-cli-rs
• #13, assert_eq!(mem::size_of::<FunctionCallCommon>, 88), assert_eq!(mem::size_of::<CappedString<200>>, 212)
• #14
• #18
  • #20

advantages as compared to app-near

• unlimited size of transactions
• normal support of batch transactions, test, screenshots of 2/12 action , none of the details of actions are shown in app-near

comparison of details shown with app-near

• CreateAccountAction
  • no change
• DeleteAccountAction
  • cargo run --example sign_delete_account_{short,long}
    • Beneficiary ID action field not displayed in app-near
• DeleteKeyAction
  • cargo run --example sign_delete_key_{ed25519/secp256k1}
    • Public Key action field not displayed in app-near
• StakeAction
  • cargo run --example sign_stake
    • Stake and Public Key fields of action not displayed in app-near
• TransferAction
  • cargo run --example sign_transfer
    • no change
• AddKeyAction
  • cargo run --example sign_add_key_fullaccess
    • Public Key field and access_key.Nonce field of action is not displayed in app-near
  • cargo run --example sign_add_key_functioncall
    • app-near displays this case identical to Full Access one (Public Key field and access_key.Nonce field of action is not displayed, no details show on Function Call Permission)
• DeployContractAction
  • cargo run --example sign_deploy_contract
    • code field of action not displayed in app-near; sha256 of code field is displayed in app-near-rs
• FunctionCallAction
  • gas field of action isn't displayed in app-near (string args argument)
  • gas field of action isn't diplayed, binary args argument displayed as blank in app-near

New functionality

• #15
• #16
• #19
  • #21

nep-413 message protocol

The protocol is similar to regular transaction signing, which has 20 bytes of 5-component BIP32Path followed by borsh serialization of transaction transferred over multiple apdu messages. There're two differences:

1. instruction byte in all of apdu headers is changed from 2 -> 7

const INS_SIGN_TRANSACTION: u8 = 2; // Instruction code to sign a transaction on the Ledger
const INS_SIGN_NEP413_MESSAGE: u8 = 7; // Instruction code to sign a nep-413 message with Ledger

2. 20 bytes of 5-component BIP32Path are followed by borsh serialization of NEP413Payload:

pub struct NEP413Payload {
    pub messsage: String,
    pub nonce: [u8; 32],
    pub recipient: String,
    pub callback_url: Option<String>,
}

Sample code which forms and sends such a message is targeted by this link.

nep-366 message protocol

The protocol is similar to regular transaction signing, which has 20 bytes of 5-component BIP32Path followed by borsh serialization of transaction transferred over multiple apdu messages. There're two differences:

1. instruction byte in all of apdu headers is changed from 2 -> 8

const INS_SIGN_TRANSACTION: u8 = 2; // Instruction code to sign a transaction on the Ledger
const INS_SIGN_NEP366_DELEGATE_ACTION: u8 = 8; // Instruction code to sign a nep-366 delegate action with Ledger

2. 20 bytes of 5-component BIP32Path are followed by borsh serialization of DelegateAction:

pub struct DelegateAction {
    /// Signer of the delegated actions
    pub sender_id: AccountId,
    /// Receiver of the delegated actions.
    pub receiver_id: AccountId,
    /// List of actions to be executed.
    ///
    /// With the meta transactions MVP defined in NEP-366, nested
    /// DelegateActions are not allowed. A separate type is used to enforce it.
    pub actions: Vec<NonDelegateAction>,
    /// Nonce to ensure that the same delegate action is not sent twice by a
    /// relayer and should match for given account's `public_key`.
    /// After this action is processed it will increment.
    pub nonce: Nonce,
    /// The maximal height of the block in the blockchain below which the given DelegateAction is valid.
    pub max_block_height: BlockHeight,
    /// Public key used to sign this delegated action.
    pub public_key: PublicKey,
}
pub type Nonce = u64;
pub type BlockHeight = u64;

Sample code which forms and sends such a message is targeted by this link.

CI/Ragger tests

Encountered issues:

• LedgerHQ/ledger-device-rust-sdk#122
• non-ASCII chars aren't supported by SDK: as indicated by LedgerHQ/ledger-device-rust-sdk#120 (comment), attempting to work with non-ASCII strings will undeterministically result in either app crashes or displaying blanks instead of parts of strings. Suggestion was made to declare explicit support of ASCII-only in LedgerHQ/ledger-device-rust-sdk#124.
  • non-ASCII chars not supported by C sdk as well
  • SDK works with newlines present in msgs, but appears to be skipping small chunks of msgs, when newlines are present
    • this was formally described by issue LedgerHQ/ledger-device-rust-sdk#146

These LedgerHQ/ledger-device-rust-sdk#124 and LedgerHQ/ledger-device-rust-sdk#146 haven't been resolved yet, but have been worked around by #47

Looking at the tests, I noticed that gas is printed as a long number that is hard to reason about. It is not critical to see exact amount of gas when signing a transaction, so I suggest we display it with TGas precision (100 TGas, 10.5 TGas)