stellar · janewang · Mar 19, 2024 · Mar 19, 2024 · Mar 19, 2024 · Mar 19, 2024
diff --git a/docs/learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx b/docs/learn/encyclopedia/liquidity-on-stellar-sdex-liquidity-pools.mdx
@@ -6,7 +6,7 @@ import { CodeExample } from "@site/src/components/CodeExample";
 
 :::note
 
-Liquidity on Stellar will look a lot different with the introduction of smart contracts. This section is a work in progress.
+This section is scoped specifically to liquidity regarding the AMM and SDEX built into the Stellar protocol and does not include information regarding smart contracts.
 
 :::
 

diff --git a/docs/learn/fundamentals/networks.mdx b/docs/learn/fundamentals/networks.mdx
@@ -12,7 +12,7 @@ Stellar has three networks: the public network (Mainnet, also called Pubnet or t
 - Validator nodes are run by the public
 - SDF offers a free [Horizon instance](https://horizon.stellar.org/) to interact with the Mainnet with a limited set of history, or you can [run your own](/network/core-node/admin-guide) or use an instance offered by an infrastructure provider.
 - You need to fund your account with XLM from another account
-- Mainnet is limited to 1,000 operations per ledger and will be limited to a maximum of 30 smart contract transactions per ledger (the precise amount of smart contract txs per ledger can vary greatly depending on transaction [resource limits](../smart-contract-internals/fees-and-metering.mdx#resource-limits))
+- Mainnet is limited to 1,000 operations per ledger and will be limited to a maximum of 100 smart contract transactions per ledger (the precise amount of smart contract txs per ledger can vary greatly depending on transaction [resource limits](../smart-contract-internals/fees-and-metering.mdx#resource-limits))
  - See more detailed smart contract network settings in the section on [Fees and Metering](../smart-contract-internals/fees-and-metering.mdx)
 - No publicly available RPC, see RPC service providers [here](/network/soroban-rpc/rpc-providers)
 

diff --git a/docs/reference/resource-limits-fees.mdx b/docs/reference/resource-limits-fees.mdx
@@ -11,33 +11,27 @@ Resource limitations and fees only apply to smart contract transactions. Read mo
 
 ## Resource Limits
 
-Soroban introduces smart contracts, marking the most transformative upgrade to the Stellar network to date. To maintain network performance, the ecosystem has decided to upgrade the network in a phased approach where network capacity is increased gradually over time. See [this blog post](https://stellar.org/blog/developers/the-stellar-network-s-phased-rollout-of-smart-contracts-the-road-to-mainnet) for more details and [Discord](https://discord.com/invite/zVYdY3ktTn) for current status.
-
-| Network Setting | Phase 0 | Phase 1 (current) |
-| :-- | :-- | :-- |
-| Soroban Txn per ledger | 1 | 100 |
-| Max CPU Instructions per Txn | 2.5 million (2M instructions for max Wasm) | 100 million (VM instantiation consumes up to 23M for a 64KB Wasm, and 46M for multiple Wasms of 130KB) |
-| Memory limit per Txn | 2 MB | 40 MB |
-| Ledger entry size (including Wasm entries) per Txn | 2 KB | 64 KB |
-| Read/Write Ledger entries per Txn | 3 read; 2 write | 40 read; 25 write |
-| Read/Write bytes per Txn | 3.2 KB read; 3.2 KB write | 130 KB read; 65 KB write |
-| Transaction size | 10 KB | 70 KB |
-| Persistent entry minimal/initial lifetime | 4,096 ledgers (~5.68 hours) | 120 days |
-| Temporary entry minimal/initial lifetime | 16 ledgers | 1 day |
-| Max ledger entry expiration bump | 61 days | 6 months |
-| Events+return value size bytes | 200 B | 8 KB |
+| Network Setting | Value |
+| --- | --- |
+| Soroban Txn per ledger | 100 |
+| Max CPU Instructions per Txn | 100 million |
+| Memory limit per Txn | 40 MB |
+| Ledger entry size (including Wasm entries) per Txn | 64 KB |
+| Read/Write Ledger entries per Txn | 40 read; 25 write |
+| Read/Write bytes per Txn | 130 KB read; 65 KB write |
+| Transaction size | 70 KB |
+| Persistent entry minimal/initial lifetime | 120 days |
+| Temporary entry minimal/initial lifetime | 1 day |
+| Max ledger entry expiration bump | 6 months |
+| Events+return value size bytes | 8 KB |
 
 ## Resource Fees
 
 Note that write fees grow linearly from empty ledger to ledger "target size", and then grow linearly, but with a 1000x factor after exceeding the target. This is to bound the ledger size growth.
 
 The ledger rent cost ('Write 1KB' entries in the table) is based on the write fee, rent period and some coefficient. For the temporary storage, the coefficient is 10 months (in ledgers), thus 1 month of temporary entry rent is 1/10 of the rent fee. For persistent storage the coefficient is 1 month (in ledgers) and thus 1 month of rent is equivalent to the write fee.
 
-### Phase 1 (current) {#phase-1}
-
-Phase 1 is meant for network operators to monitor network performance under use. While you'll be able to deploy contracts, Mainnet in Phase 1 has limited throughput. You should not expect more than 1 smart contract transaction per ledger. You can expect throughput to be gradually increased based on network performance and user (your) feedback. See [this blog post](https://stellar.org/blog/developers/the-stellar-network-s-phased-rollout-of-smart-contracts-the-road-to-mainnet) for more details and share your feedback in [Discord](https://discord.com/invite/zVYdY3ktTn).
-
-| Network setting | Phase 1 Cost (stroops) |
+| Network Setting | Cost (stroops) |
 | :-- | :-- |
 | 10,000 instructions | 25 (250,000/max tx) |
 | Read 1 ledger entry | 6,250 (250,000/max tx) |
@@ -48,47 +42,10 @@ Phase 1 is meant for network operators to monitor network performance under use.
 | 1KB of Events/return value | 10,000 (80,000/max tx) |
 | “Target” ledger size | 13 GB |
 | Fee multiplier after reaching the target size | 1,000 |
-| Write 1KB to ledger, stroops (empty) | -1,234,673 (the write cost is always positive; this value is used only for the effective write fee computations) |
+| Write 1KB to ledger, stroops (empty) | -193,153 (the write cost is always positive; this value is used only for the effective write fee computations) |
 | Write 1KB to ledger, stroops (current, 12 GB) | 11,539 (750,000/max tx) |
-| Write 1KB to ledger, stroops (target, 13 GB) | 115,390 (7,500,000/max tx) |
+| Write 1KB to ledger, stroops (target, 12.5 GB) | 57,695 (7,500,000/max tx) |
 | Temp entry rent period, ledgers | 2,804 |
 | Persistent entry rent period, ledgers | 1,402 |
 | Minimum persistent entry TTL, ledgers | 2,073,600 (120 days) |
 | Minimum temp entry TTL, ledgers | 17,280 (~1 day) |
-
-#### Phase 1 Examples
-
-Here are some examples to put things in perspective (the fees are computed at "current" ledger size and would grow as ledger size increases):
-
-| Scenario | Phase 1 Cost |
-| :-- | :-- |
-| Upload a new 64KB Wasm (includes 120 day rent payment) | 109.2 XLM |
-| 1 year of 64KB Wasm storage rent | 327.7 XLM |
-| Bump 64KB Wasm rent by 1 day | 0.91 XLM |
-| Modify 64 KB contract data entry without increasing the size | 0.075 XLM |
-| Create 100 byte contract data entry, e.g. user balance (includes 120 day rent payment) | 0.17 XLM |
-| 1 year of 100 byte storage rent | 0.512 XLM |
-| Modify 100 byte contract data entry without increasing the size | 1150 stroops |
-
-### Phase 0
-
-Phase 0 is meant for network operators to observe and ensure network stability. While you may be able to deploy simple contracts, Mainnet in Phase 0 is not designed for contract development or deployment. Testnet is better suited for this purpose.
-
-| Network Setting | Phase 0 Cost (stroops) |
-| :-------------------------------------------- | :---------------------- |
-| 10,000 instructions | 100 (1,000,000/tx) |
-| Read 1 ledger entry | 1,000 (20,000/tx) |
-| Write 1 ledger entry | 3,000 (30,000/tx) |
-| Read 1KB from ledger | 1,000 (127,000/tx) |
-| 1KB of transaction (bandwidth) | 500 (34,000/tx) |
-| 1KB of transaction (history) | 5,000 (340,000/tx) |
-| 1KB of Events/return value | 300 (1,500/tx) |
-| “Target” ledger size | 14.5 GB |
-| Fee multiplier after reaching the target size | 1,000 |
-| Write 1KB to ledger (empty) | 1,000 |
-| Write 1KB to ledger (current, 12 GB) | 0.356 XLM (17.4 XLM/tx) |
-| Write 1KB to ledger (target, 14 GB) | 0.4 XLM (2.26 XLM/tx) |
-| Temp entry rent period | 10 months |
-| Persistent entry rent period | 1 month |
-| 1 KB of temp storage per month | 400,000 |
-| 1 KB of persistent storage per month | 4,000,000 |
diff --git a/docs/reference/software-versions.mdx b/docs/reference/software-versions.mdx
@@ -14,6 +14,69 @@ Release candidates are software releases that are also released to the [Testnet]
 
 [testnet]: ./networks.mdx
 
+## Protocol 20: Soroban Phase 2 (March 19, 2024)
+
+### Software
+
+| Software | Version |
+| --- | --- |
+| XDR | [3da6ebcbd8afa01d5c94dbc7f0475f4c00089420](https:/stellar/rs-stellar-xdr/commit/3da6ebcbd8afa01d5c94dbc7f0475f4c00089420) |
+| Soroban Environment | `v20.2.2` |
+| Soroban Interface Version | `0` |
+| Soroban Resource Limits | [Phase 2 Limits](./resource-limits-fees.mdx#resource-limits) |
+| Soroban Resource Fees | [Phase 2 Fees](./resource-limits-fees.mdx#phase-1) |
+| Stellar Core | `v20.3.0` |
+| Soroban Rust SDK | `v20.4.0` |
+| Soroban CLI | `v20.3.1` |
+| Soroban RPC | `v20.3.3` |
+| Stellar Horizon | `v2.28.3` |
+| Stellar Friendbot | `TBD` |
+| Stellar Quickstart | `docker.io/stellar/quickstart:latest@sha256:1a82b17a4fae853d24189dd25d4e6b774fa7a1b6356a993e618c6e9bd2f3e04c` |
+| Stellar JS Stellar Base | [`v11.0.0`](https:/stellar/js-stellar-base/releases/tag/v11.0.0) |
+| Stellar JS Stellar SDK | [`v11.2.2`](https:/stellar/js-stellar-sdk/releases/tag/v11.2.2) |
+| Freighter | `v5.17.0` |
+| Laboratory | `v4.1.0` |
+| Soroban React Payment dapp | `TBD` |
+| Soroban Mint Token dapp | `TBD` |
+| Soroban Swap Token dapp | `TBD` |
+| Futurenet Network Passphrase | `Test SDF Future Network ; October 2022` |
+| Testnet Network Passphrase | `Test SDF Network ; September 2015` |
+| Mainnet Network Passphrase | `Public Global Stellar Network ; September 2015` |
+
+### Changelog
+
+#### Core
+
+- Remove use of C99 that looks like Cxx20 designated initializers
+- Reduce scan size in phase1
+- Add simulate subcommand to network survey script
+- Continue to capture SCP messages for previous ledger in database
+- Rewrite state loading path on startup
+- Add support for debug-tx-set in dump-xdr
+- Bucket cleanup
+- Update phase1 settings
+- Fix compile error (Visual C++)
+- Update soroban settings files and utils
+- Add new throttling metrics
+- Adds CLI tool to print BucketList archival stats
+- Update denominators
+- Set key size to initial value
+- Update max_entries_to_archive to be 1000.
+- Restrict "prev" test to just the voting path, to allow catchup.
+- Strkey update
+- Add scripts/extract-wasms.sh
+- Bump overlay min version to 32
+- Fix noisy eviction scan warnings
+- Early initialization of soroban metrics
+
+#### Soroban Rust SDK
+
+- Display String contents in Debug implementation
+- Add Bytes to_buffer and to_alloc_vec
+- Move the Env testutil internal types into a single type
+- Add option to disable test snapshots on Env
+- Bump version to 20.4.0
+
 ## Protocol 20: Soroban Phase 1 (February 27, 2024)
 
 ### Software

diff --git a/docs/tools/sdks/library.mdx b/docs/tools/sdks/library.mdx
@@ -3,7 +3,7 @@ title: "SDK Library"
 sidebar_position: 10
 ---
 
-Interact with the Stellar network using the SDK in your preferred language. The JavaScript, Java, Go, and Rust SDKs are maintained by SDF and the rest are maintained by dedicated community developers. All SDKs are open-source; file a GitHub issue or pull request in the specific SDK repository if you have questions or suggestions.
+Interact with the Stellar network using the SDK in your preferred language. The JavaScript, Go, and Rust SDKs are maintained by SDF and the rest are maintained by dedicated community developers. All SDKs are open-source; file a GitHub issue or pull request in the specific SDK repository if you have questions or suggestions.
 
 Each SDK has its own source code and documentation. Learn how to use a specific SDK by referring to the documentation- most docs offer practical examples that demonstrate how to construct and submit transactions and interact with Horizon endpoints.
 
@@ -91,9 +91,9 @@ This SDK is maintained by dedicated community developers, kommitters Open Source
 
 ### Java SDK
 
-[Java SDK](https:/stellar/java-stellar-sdk) | [Docs](https://stellar.github.io/java-stellar-sdk/)
+[Java SDK](https:/lightsail-network/java-stellar-sdk) | [Docs](https://lightsail-network.github.io/java-stellar-sdk/)
 
-`java-stellar-sdk` provides APIs to build transactions and connect to Horizon, it also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Soroban RPC Server.
+`java-stellar-sdk` provides APIs to build transactions and connect to Horizon and also provides functionality to deploy and invoke Soroban smart contracts and communicates with the Soroban RPC Server.
 
 ### Go
 

diff --git a/docusaurus.config.js b/docusaurus.config.js
@@ -206,7 +206,7 @@ const config = {
  },
  {
  type: 'html',
- value: '<hr><small>SDF Platforms</small>',
+ value: '<hr><small>Platforms</small>',
  className: 'subtitle',
  },
  {

diff --git a/meeting-notes/2024-02-29.mdx b/meeting-notes/2024-02-29.mdx
@@ -0,0 +1,21 @@
+---
+title: '2024-02-29'
+authors: naman
+tags: [protocol]
+---
+
+<iframe
+ src="https://drive.google.com/file/d/1zKvUx74UqvfmpNvU8BJt5RAqj-XHyBke/preview"
+ width="640"
+ height="360"
+ allow="autoplay"
+></iframe>
+
+[Discord agenda thread](https://discord.com/channels/897514728459468821/1212118102565855243)
+
+1. Tommaso (@tdep) proposed a core change to allow for extending instance and code TTL with separate values on the host environment to allow for more cost-efficient designs
+ a. Proposal and discussion are captured in github discussions [stellar-core#1447](https:/stellar/stellar-protocol/discussions/1447)
+2. Tommaso receieved feedback on the proposal as well as implementation. Since it didn't require a metering change, core devs thought it to be a quick change. 
+3. The ecosystem voted in favor of the proposal by upvoting the post on Github Discussions. 13 votes were [recorded](https:/stellar/stellar-protocol/discussions/).
+4. As next steps, a CAP will be authored to capture the proposal and put forth for approval from CAP Core Team.
+
diff --git a/meeting-notes/2024-03-14.mdx b/meeting-notes/2024-03-14.mdx
@@ -0,0 +1,25 @@
+---
+title: '2024-03-14'
+authors: naman
+tags: [protocol]
+---
+
+<iframe
+ src="https://drive.google.com/file/d/1Gztue3zvZBQzVPshM0_Yy8ntYh7Bk33d/preview"
+ width="640"
+ height="360"
+ allow="autoplay"
+></iframe>
+
+[Discord agenda thread](https://discord.com/channels/897514728459468821/1217193723612368926)
+
+1. CAP Core Team deliberated over the latest proposals put forth by the Stellar ecosystem to advance stellar-core. 
+2. Nicholas and David from the CAP Core Team listened to the following proposals and discussed the proposals with the authors.
+ a. CAP Core team will deliver their vote over email. 
+3. Proposals discussed: 
+ a. [CAP-51](https:/stellar/stellar-protocol/blob/master/core/cap-0051.md): add support for secp256r1 verification; by @leigh 
+ b. [CAP-53](https:/stellar/stellar-protocol/blob/master/core/cap-0053.md): create separate functions for extending the time-to-live for contract instance and contract code; by @tdep 
+ c. [CAP-54](https:/stellar/stellar-protocol/blob/master/core/cap-0054.md): lower total costs by refining the Soroban cost model used for VM instantiation into multiple separate and more-accurate costs; by @graydon 
+ d. [CAP-55](https:/stellar/stellar-protocol/blob/master/core/cap-0055.md): lower total costs by linking fewer host functions during VM instantiation in Soroban; by @graydon 
+ e. [CAP-56](https:/stellar/stellar-protocol/blob/master/core/cap-0056.md): lower total costs by caching parsed Wasm modules within a Soroban transaction; by @graydon
+
diff --git a/meeting-notes/2024-03-21.mdx b/meeting-notes/2024-03-21.mdx
@@ -0,0 +1,21 @@
+---
+title: '2024-03-21'
+authors: kalepail
+tags: [developer]
+---
+
+<iframe
+ src="https://drive.google.com/file/d/1vSkQFbdg80548ShpjOpyD9scnQjebkQi/preview"
+ width="640"
+ height="360"
+ allow="autoplay"
+></iframe>
+
+[Discord agenda thread](https://discord.com/channels/897514728459468821/1219381314931917000)
+
+1. There's a discussion on a TX meta change increasing visibility and analytics within the Stellar network. (https:/stellar/stellar-xdr/pull/175)
+2. Read-only invocations for contracts is explained, focusing on ensuring certain functions remain read-only without side effects. (https:/stellar/stellar-protocol/discussions/1454) (https:/stellar/stellar-protocol/discussions/1456) (https:/stellar/stellar-protocol/discussions/1464)
+3. Enabling contract discovery is introduced to enhance the visibility and authenticity of smart contracts within the Stellar ecosystem.
+4. The implementation of a standardized contract meta data schema is proposed to link contracts to source code and enhance contract discoverability.(https://docs.rs/soroban-sdk/latest/soroban_sdk/macro.contractmeta.html)
+5. Issues related to inclusion fees in the Stellar network, highlighting the importance of monitoring fees closely and understanding the implications of surge pricing. (https://developers.stellar.org/docs/learn/smart-contract-internals/fees-and-metering#transaction-fee)
+6. Plans are discussed for designing a new RPC endpoint to provide developers with better visibility and information on setting inclusion fees, aiming to improve transparency and decision-making regarding fee trade-offs.
diff --git a/meeting-notes/authors.yml b/meeting-notes/authors.yml
@@ -5,6 +5,6 @@ kalepail:
  image_url: https:/kalepail.png
 naman:
  name: Naman Kumar
- title: Senior Product Manager
+ title: Product Manager
  url: https:/namankumar
  image_url: https:/namankumar.png
diff --git a/network/horizon/README.mdx b/network/horizon/README.mdx
@@ -3,6 +3,15 @@ title: Introduction
 sidebar_position: 10
 ---
 
+:::info
+Please note, starting July 15, 2024, SDF will be truncating historical data on
+SDF-owned Horizon to one year. This update allows us to optimize performance and
+ensure a streamlined experience for all users. We encourage you to also explore
+[third party ecosystem providers of Horizon](./horizon-providers.mdx) whom may provide longer history
+retention window as well as other features.
+:::
+
+
 Horizon provides an HTTP API to data in the Stellar network. It ingests and re-serves the data produced by the Stellar network in a form that is easier to consume by the average application relative to the performance-oriented data representations used by Stellar Core. This API serves the bridge between apps and [Stellar Core](../core-node/README.mdx). Projects like wallets, decentralized exchanges, and asset issuers use Horizon to submit transactions, query an account balance, or stream events like transactions to an account.
 
 Horizon can be accessed via cURL, a browser, or one of the [Stellar SDKs](/docs/tools/sdks). To reduce the complexity of your project, we recommend you use an SDK instead of making direct API calls.