stellar-deprecated · paulbellamy · Jan 27, 2023 · Jan 30, 2023 · Jan 30, 2023 · Jan 31, 2023
diff --git a/api/methods/getAccount.mdx b/api/methods/getAccount.mdx
diff --git a/api/methods/getEvents.mdx b/api/methods/getEvents.mdx
@@ -12,8 +12,7 @@ By default soroban-rpc retains the most recent 24 hours of events.
 
 ## Parameters
 
-- `startLedger`: `<string>` - Stringified ledger sequence number to fetch events after (inclusive).
-- `endLedger`: `<string>` - Stringified ledger sequence number to fetch events before (inclusive). endLedger must be less than or equal to startLedger + 4320 (about 6 hours of ledgers).
+- `startLedger`: `<string>` - Stringified ledger sequence number to fetch events after (inclusive). If `startLedger` is greater than the latest ledger seen by this node, this method will return an error.
 - `filters`: `<object[]>` - List of filters for the returned events. Events matching any of the filters are included. To match a filter, an event must match both a contractId and a topic. Maximum 5 filters are allowed per request.
   - `type`: `<"system"|"contract">` - (optional) Filter to only system or only contract type events. If omitted, return all.
   - `contractIds`: `<string[]>` - (optional) List of contract ids to query for events. If omitted, return events for all contracts. Maximum 5 contract IDs are allowed per request.
@@ -68,7 +67,6 @@ The examples below only returns two transfer events that took place to/from the
   "method": "getEvents",
   "params": {
     "startLedger": "227000",
-    "endLedger": "230200",
     "filters": [
       {
         "type": "contract",

diff --git a/api/methods/getHealth.mdx b/api/methods/getHealth.mdx
diff --git a/api/methods/getLatestLedger.mdx b/api/methods/getLatestLedger.mdx
@@ -15,6 +15,7 @@ For finding out the current latest known ledger of this node. This is a subset o
 ## Returns
 
 - `<object>`
-  - `id`: `<hash>` - hash of the latest ledger as a hex-encoded string
-  - `protocolVersion`: `<number>`
-  - `sequence`: `<number>`
+  - `id`: `<hash>` - Hash of the latest ledger as a hex-encoded string
+  - `protocolVersion`: `<number>` - Protocol version 
+  - `sequence`: `<number>` - Sequence number of the latest ledger
+  - `closeTime`: `<iso8601-string>` - Timestamp that the latest ledger was completed
diff --git a/api/methods/getLedgerEntry.mdx → api/methods/getLedgerEntries.mdx b/api/methods/getLedgerEntry.mdx → api/methods/getLedgerEntries.mdx
@@ -8,13 +8,14 @@ To fetch contract wasm byte-code, use the ContractCode ledger entry key.
 
 ## Parameters
 
-- `key`: `<xdr.LedgerKey>` - The key of the ledger entry you wish to retrieve (serialized in a base64 string)
+- `keys`: `[<xdr.LedgerKey>]` - Array of keys for ledger entries you wish to retrieve (each serialized in a base64 string)
 
 ## Return
 
 - `<object>`
-  - `xdr`: `<xdr.LedgerEntryData>` - The current value of the given ledger entry  (serialized in a base64 string)
-  - `lastModifiedLedgerSeq`: `<number>` - The ledger number of the last time this entry was updated (optional)
+  - `entries`: `<array>` - Array of ledger entry results. If a key was not found, it will be `null` in the array.
+    - `xdr`: `<xdr.LedgerEntryData>` - The current value of the given ledger entry  (each serialized in a base64 string)
+    - `lastModifiedLedgerSeq`: `<number>` - The ledger number of the last time this entry was updated (optional)
   - `latestLedger`: `<number>` - The current latest ledger observed by the node when this response was generated.
 
 ## Examples
@@ -25,9 +26,9 @@ To fetch contract wasm byte-code, use the ContractCode ledger entry key.
 {
   "jsonrpc": "2.0",
   "id": 8675309,
-  "method": "getLedgerEntry",
+  "method": "getLedgerEntries",
   "params": {
-    "key": "AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAABQAAAAdDT1VOVEVSAA=="
+    "keys": ["AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAABQAAAAdDT1VOVEVSAA=="]
   }
 }
 ```
@@ -39,8 +40,12 @@ To fetch contract wasm byte-code, use the ContractCode ledger entry key.
   "jsonrpc": "2.0",
   "id": 8675309,
   "result": {
-    "xdr": "AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAABQAAAAdDT1VOVEVSAAAAAAEAAAAD",
-    "lastModifiedLedgerSeq": "164986",
+    "entries": [
+      {
+        "xdr": "AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAABQAAAAdDT1VOVEVSAAAAAAEAAAAD",
+        "lastModifiedLedgerSeq": "164986"
+      }
+    ],
     "latestLedger": "179436"
   }
 }
@@ -134,15 +139,15 @@ print(get_ledger_key_contract_code(
 # OUTPUT: AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAAAwAAAAM=
 ```
 
-We then take our output from this function, and use it as the `key` parameter in our call to the `getLedgerEntry` method.
+We then take our output from this function, and use it as the `key` parameter in our call to the `getLedgerEntries` method.
 
 ```json
 {
   "jsonrpc": "2.0",
   "id": 8675309,
-  "method": "getLedgerEntry",
+  "method": "getLedgerEntries",
   "params": {
-    "key": "AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAAAwAAAAM="
+    "keys": ["AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAAAwAAAAM="]
   }
 }
 ```
@@ -154,8 +159,12 @@ And the response we get contains the `LedgerEntryData` that can be used to find
   "jsonrpc": "2.0",
   "id": 8675309,
   "result": {
-    "xdr": "AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAAAwAAAAMAAAAEAAAAAQAAAAcAAAAA1CpZRz0BSN27PmqtsmBhv+AAJJwHgmrvJNPrHRAl9l8=",
-    "lastModifiedLedgerSeq": "164303",
+    "entries": [
+      {
+        "xdr": "AAAABhv6ziOnWcVRdGMZjtFKSWnLSndMp9JPVLLXxQqAvKqJAAAAAwAAAAMAAAAEAAAAAQAAAAcAAAAA1CpZRz0BSN27PmqtsmBhv+AAJJwHgmrvJNPrHRAl9l8=",
+        "lastModifiedLedgerSeq": "164303"
+      }
+    ],
     "latestLedger": "246819"
   }
 }
@@ -191,9 +200,9 @@ Now, finally we have a `LedgerKey` that correspond to the WASM byte-code that ha
 {
   "jsonrpc": "2.0",
   "id": 8675309,
-  "method": "getLedgerEntry",
+  "method": "getLedgerEntries",
   "params": {
-    "key": "AAAAB9QqWUc9AUjduz5qrbJgYb/gACScB4Jq7yTT6x0QJfZf"
+    "keys": ["AAAAB9QqWUc9AUjduz5qrbJgYb/gACScB4Jq7yTT6x0QJfZf"]
   }
 }
 ```
@@ -205,12 +214,16 @@ And the response we get contains (even more) `LedgerEntryData` that we can decod
   "jsonrpc": "2.0",
   "id": 8675309,
   "result": {
-    "xdr": "AAAABwAAAADUKllHPQFI3bs+aq2yYGG/4AAknAeCau8k0+sdECX2XwAAAakAYXNtAQAAAAEXBWABfgF+YAJ+fgF+YAABfmABfwBgAAACEwMBbAEwAAABbAExAAABbAFfAAEDBgUCAwQEBAUDAQAQBhkDfwFBgIDAAAt/AEGAgMAAC38AQYCAwAALBzUFBm1lbW9yeQIACWluY3JlbWVudAADAV8ABwpfX2RhdGFfZW5kAwELX19oZWFwX2Jhc2UDAgrAAQWhAQMBfwF+AX8jgICAgABBEGsiACSAgICAAAJAAkBC2YP9sqDNAxCAgICAAEIVUg0AAkBC2YP9sqDNAxCBgICAACIBQg+DQgFSDQAgAUIEiKchAgwCCyAAQQhqEISAgIAAAAtBACECCwJAIAJBAWoiAg0AEIWAgIAAAAtC2YP9sqDNAyACrUIEhkIBhCIBEIKAgIAAGiAAQRBqJICAgIAAIAELCQAQhoCAgAAACwkAEIaAgIAAAAsEAAAACwIACwAeEWNvbnRyYWN0ZW52bWV0YXYwAAAAAAAAAAAAAAAbAC8OY29udHJhY3RzcGVjdjAAAAAAAAAACWluY3JlbWVudAAAAAAAAAAAAAABAAAAAQAAAA==",
-    "lastModifiedLedgerSeq": "164302",
+    "entries": [
+      {
+        "xdr": "AAAABwAAAADUKllHPQFI3bs+aq2yYGG/4AAknAeCau8k0+sdECX2XwAAAakAYXNtAQAAAAEXBWABfgF+YAJ+fgF+YAABfmABfwBgAAACEwMBbAEwAAABbAExAAABbAFfAAEDBgUCAwQEBAUDAQAQBhkDfwFBgIDAAAt/AEGAgMAAC38AQYCAwAALBzUFBm1lbW9yeQIACWluY3JlbWVudAADAV8ABwpfX2RhdGFfZW5kAwELX19oZWFwX2Jhc2UDAgrAAQWhAQMBfwF+AX8jgICAgABBEGsiACSAgICAAAJAAkBC2YP9sqDNAxCAgICAAEIVUg0AAkBC2YP9sqDNAxCBgICAACIBQg+DQgFSDQAgAUIEiKchAgwCCyAAQQhqEISAgIAAAAtBACECCwJAIAJBAWoiAg0AEIWAgIAAAAtC2YP9sqDNAyACrUIEhkIBhCIBEIKAgIAAGiAAQRBqJICAgIAAIAELCQAQhoCAgAAACwkAEIaAgIAAAAsEAAAACwIACwAeEWNvbnRyYWN0ZW52bWV0YXYwAAAAAAAAAAAAAAAbAC8OY29udHJhY3RzcGVjdjAAAAAAAAAACWluY3JlbWVudAAAAAAAAAAAAAABAAAAAQAAAA==",
+        "lastModifiedLedgerSeq": "164302"
+      }
+    ],
     "latestLedger": "246883"
   }
 }
 ```
 
 [`increment` example contract]: </docs/examples/storing-data>
-["View XDR" page of the Stellar Laboratory]: <https://laboratory.stellar.org/#xdr-viewer?type=LedgerEntryData&network=futurenet>
+["View XDR" page of the Stellar Laboratory]: <https://laboratory.stellar.org/#xdr-viewer?type=LedgerEntryData&network=futurenet>
diff --git a/api/methods/getLedgers.mdx b/api/methods/getLedgers.mdx
@@ -0,0 +1,21 @@
+---
+sidebar_position: 7
+---
+
+:::note
+The `getLedgers` method is proposed but not yet implemented.
+:::
+
+
+Clients can request a list of ledgers. Soroban-RPC will support querying within a maximum 24 hours of recent ledgers.
+
+## Parameters
+
+- `startLedger`: `<string>` - Stringified ledger sequence number to fetch events after (inclusive).
+- `endLedger`: `<string>` - Stringified ledger sequence number to fetch events before (inclusive). endLedger must be less than or equal to startLedger + 720 (about 1 hour of ledgers).
+
+## Returns
+
+- `<object>`
+  - `ledgers`: `<object[]>`
+    - TODO: Figure out the object returned here.
diff --git a/api/methods/getNetwork.mdx b/api/methods/getNetwork.mdx
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 7
+sidebar_position: 6
 ---
 
 :::note
@@ -15,5 +15,6 @@ General info about the currently configured network.
 ## Returns
 
 - `<object>`
+  - `friendbotUrl`: `<string>` (optional) - The URL of this network's "friendbot" faucet
   - `passphrase`: `<string>` - Network passphrase configured
   - `protocolVersion`: `<string>` - Protocol version of the latest ledger
diff --git a/api/methods/getTransactionStatus.mdx b/api/methods/getTransactionStatus.mdx
@@ -33,6 +33,7 @@ Clients will poll this to tell when the transaction has been completed.
     - `code`: `<string>` - Short unique string representing the type of error
     - `message`: `<string>` - Human friendly summary of the error
     - `data`: `<object>` - (optional) More data related to the error if available
+  - `eta`: `<iso8601-string>` - (optional) A rough estimate of the soonest time this transaction could be included in a ledger. Only present if the transaction is "pending".
 
 ## Examples
 
@@ -59,7 +60,8 @@ Clients will poll this to tell when the transaction has been completed.
   "id": 8675309,
   "result": {
     "id": "d70916f8b8aa55c13d5974a38e32a3efe440ef6870c0f0a07075d1c128d23698",
-    "status": "pending"
+    "status": "pending",
+    "eta": "2023-01-27T16:54:52Z"
   }
 }
 ```

diff --git a/api/methods/requestAirdrop.mdx b/api/methods/requestAirdrop.mdx
diff --git a/api/methods/sendTransaction.mdx b/api/methods/sendTransaction.mdx
@@ -24,6 +24,7 @@ This supports all transactions, not only smart contract-related transactions.
     - `success`
     - `error`
   - `error`: `<object>` -  (optional) If the transaction was rejected immediately, this will be an error object. See [`getTransactionStatus`](getTransactionStatus) for format.
+  - `eta`: `<iso8601-string>` - A rough estimate of the soonest time this transaction could be included in a ledger.
 
 ## Possible Errors
 
@@ -55,9 +56,10 @@ The following example request uses a transaction to invoke the `increment` metho
   "result": {
     "id": "d70916f8b8aa55c13d5974a38e32a3efe440ef6870c0f0a07075d1c128d23698",
     "status": "pending",
-    "error": null
+    "error": null,
+    "eta": "2023-01-27T16:54:52Z"
   }
 }
 ```
 
-[`increment` example contract]: </docs/examples/storing-data>
+[`increment` example contract]: </docs/examples/storing-data>
diff --git a/api/methods/simulateTransaction.mdx b/api/methods/simulateTransaction.mdx
@@ -14,7 +14,7 @@ Submit a trial contract invocation to get back return values, expected ledger fo
   - `cost`: `<object>` - Information about the fees expected, instructions used, etc.
     - `cpuInsns`: `<string>` - Stringified-number of the total cpu instructions consumed by this transaction
     - `memBytes`: `<string>` - Stringified-number of the total memory bytes allocated by this transaction
-  - `footprint`: `<xdr.LedgerFootprint>` -Array of ledger keys expected to be written by this transaction. (serialized in base64)
+  - `footprints`: `<xdr.LedgerFootprint[]>` - Array of xdr.LedgerFootprints (one per operation) expected to be read/written by this transaction. (each serialized in base64)
   - `results`: `<object[]>` - If error is present then results will not be in the response
     - `xdr`: `<xdr.ScVal>` - (optional) Only present on success. xdr-encoded return value of the contract call
   - `latestLedger`: `<string>` - Stringified-number of the current latest ledger observed by the node when this response was generated.
@@ -49,7 +49,9 @@ The example transaction below invokes the `increment` function from the [`increm
         "xdr": "AAAAAQAAAAY="
       }
     ],
-    "footprint": "AAAAAgAAAAYb+s4jp1nFUXRjGY7RSklpy0p3TKfST1Sy18UKgLyqiQAAAAMAAAADAAAAB9QqWUc9AUjduz5qrbJgYb/gACScB4Jq7yTT6x0QJfZfAAAAAQAAAAYb+s4jp1nFUXRjGY7RSklpy0p3TKfST1Sy18UKgLyqiQAAAAUAAAAHQ09VTlRFUgA=",
+    "footprints": [
+      "AAAAAgAAAAYb+s4jp1nFUXRjGY7RSklpy0p3TKfST1Sy18UKgLyqiQAAAAMAAAADAAAAB9QqWUc9AUjduz5qrbJgYb/gACScB4Jq7yTT6x0QJfZfAAAAAQAAAAYb+s4jp1nFUXRjGY7RSklpy0p3TKfST1Sy18UKgLyqiQAAAAUAAAAHQ09VTlRFUgA="
+    ],
     "cost": {
       "cpuInsns": "163642",
       "memBytes": "1506"
@@ -59,4 +61,4 @@ The example transaction below invokes the `increment` function from the [`increm
 }
 ```
 
-[`increment` example contract]: </docs/examples/storing-data>
+[`increment` example contract]: </docs/examples/storing-data>