Skip to content

Commit

Permalink
Fix doc formatting and rendering
Browse files Browse the repository at this point in the history
  • Loading branch information
@cedelavergne-ledger
cedelavergne-ledger committed Sep 28, 2023
1 parent 399d4b0 commit e9ff3ed
Showing 1 changed file with 17 additions and 16 deletions.
33 changes: 17 additions & 16 deletions doc/xrpapp.asc
View file
Original file line number Diff line number Diff line change
@@ -1,11 +1,12 @@
XRP application : Common Technical Specifications
XRP application : Common Technical Specifications
=======================================================
Ledger Firmware Team <hello@ledger.fr>
Application version 2.0 - January 2020

Copyright (c) 2020 Towo Labs

== 2.0

- Support for all transaction types:
- AccountSet
- AccountDelete
Expand All @@ -31,14 +32,14 @@ Copyright (c) 2020 Towo Labs
- Support for multi-signing
- Unified UI across Ledger Nano S and Ledger Nano X

== 1.0
== 1.0
- Initial release

== About

This application describes the APDU messages interface to communicate with the XRP application.
This application describes the APDU messages interface to communicate with the XRP application.

The application covers the following functionalities, either on secp256k1 or ed25519 :
The application covers the following functionalities, either on secp256k1 or ed25519 :

- Retrieve a public XRP address given a BIP 32 path
- Sign a basic XRP Payment transaction given a BIP 32 path
Expand All @@ -62,7 +63,7 @@ The address can be optionally checked on the device before being returned.

[width="80%"]
|==============================================================================================================================
| *CLA* | *INS* | *P1* | *P2* | *Lc* | *Le*
| *CLA* | *INS* | *P1* | *P2* | *Lc* | *Le*
| E0 | 02 | 00 : return address

01 : display address and confirm before returning
Expand Down Expand Up @@ -114,15 +115,15 @@ The input data is the serialized according to XRP internal serialization protoco

[width="80%"]
|==============================================================================================================================
| *CLA* | *INS* | *P1* | *P2* | *Lc* | *Le*
| *CLA* | *INS* | *P1* | *P2* | *Lc* | *Le*
| E0 | 04 | 00 : first and only transaction data block

01 : last transaction data block

80 : first of many transaction data blocks

81 : intermediate transaction data block (neither first nor last)
|
|
40 : use secp256k1 curve (bitmask)

80 : use ed25519 curve (bitmask) | variable | variable
Expand Down Expand Up @@ -155,7 +156,7 @@ The input data is the serialized according to XRP internal serialization protoco
|==============================================================================================================================
| *Description* | *Length*
| DER encoded signature (secp256k1) or EDDSA signature (ed25519) | variable
|======================================================================================================
|==============================================================================================================================

=== GET APP CONFIGURATION

Expand All @@ -169,7 +170,7 @@ This command returns specific application configuration

[width="80%"]
|==============================================================================================================================
| *CLA* | *INS* | *P1* | *P2* | *Lc* | *Le*
| *CLA* | *INS* | *P1* | *P2* | *Lc* | *Le*
| E0 | 06 | 00 | 00 | 00 | 04
|==============================================================================================================================

Expand All @@ -182,8 +183,8 @@ None
[width="80%"]
|==============================================================================================================================
| *Description* | *Length*
| Flags
| Flags

RFU

| 01
Expand All @@ -197,9 +198,9 @@ None

=== General transport description

Ledger APDUs requests and responses are encapsulated using a flexible protocol allowing to fragment large payloads over different underlying transport mechanisms.
Ledger APDUs requests and responses are encapsulated using a flexible protocol allowing to fragment large payloads over different underlying transport mechanisms.

The common transport header is defined as follows :
The common transport header is defined as follows :

[width="80%"]
|==============================================================================================================================
Expand Down Expand Up @@ -232,7 +233,7 @@ APDU Command payloads are encoded as follows :
| Optional APDU data | var
|==============================================================================================================================

APDU payload is encoded according to the APDU case
APDU payload is encoded according to the APDU case

[width="80%"]
|=======================================================================================
Expand Down Expand Up @@ -264,11 +265,11 @@ A similar encoding is used over BLE, without the Communication channel ID.

The application acts as a GATT server defining service UUID D973F2E0-B19E-11E2-9E96-0800200C9A66

When using this service, the client sends requests to the characteristic D973F2E2-B19E-11E2-9E96-0800200C9A66, and gets notified on the characteristic D973F2E1-B19E-11E2-9E96-0800200C9A66 after registering for it.
When using this service, the client sends requests to the characteristic D973F2E2-B19E-11E2-9E96-0800200C9A66, and gets notified on the characteristic D973F2E1-B19E-11E2-9E96-0800200C9A66 after registering for it.

Requests are encoded using the standard BLE 20 bytes MTU size

== Status Words
== Status Words

The following standard Status Words are returned for all APDUs - some specific Status Words can be used for specific commands and are mentioned in the command description.

Expand Down

0 comments on commit e9ff3ed

Please sign in to comment.