chore: update programs.md

light-token/defi/programs.mdx

@@ -3,7 +3,7 @@
 description: "Build high-performance DeFi programs with rent-free accounts"
 ---
 
 The Light-SDK pays rent-exemption for your PDAs, token accounts, and mints (98%
 cost savings). Your program logic stays the same.
 
 ## What Changes
@@ -271,7 +271,7 @@
 </Accordion>
 
 ## Step 5: Instructions
 Replace `spl_token` with `light_token` instructions as you need. The API is a superset of SPL-token so switching is straightforward.
 
 Examples include: `MintToCpi`, `TransferCpi`, `TransferInterfaceCpi`,
 `CreateTokenAccountCpi`, and `CreateTokenAtaCpi`.
@@ -348,8 +348,8 @@
 
 ## Client SDK
 
-To make it easy for clients to integrate with your program, ship an SDK crate
-implementing the `LightProgramInterface` trait.
+To make it easy for clients to integrate with your program, implement the
+`LightProgramInterface` trait in your program's SDK crate.
 
 For a detailed example of how clients use this trait, check out the [Router Integration](./routers.mdx) page.
 
@@ -488,7 +488,7 @@
 The SDK pays the rent-exemption cost. Inactive (cold) accounts auto-compress. Your program only ever interacts with hot accounts. 
 Clients can load cold accounts back when needed via `create_load_instructions`.
 
 Under the hood, clients use `AccountInterface` - a superset of Solana's `Account` that unifies hot and cold state. See [Router Integration](./routers) for details.
 
 | | Hot (active) | Cold (inactive) |
 |---|---|---|
@@ -505,22 +505,22 @@
 
 ## FAQ
 
-<Accordion title="How does it prevent re-init attacks?"> When
-you create an account, under the hood, the SDK auto-provides a proof that
-verifies that the account does not yet exist in the compressed address space.
-The SVM takes care of uniqueness in the onchain space. This way both account
-spaces are covered, preventing re-init attacks. </Accordion>
+<Accordion title="How does it prevent re-init attacks?"> When creating an
+account for the first time, the SDK provides a proof that the account doesn't
+exist in the cold address space. The SVM already verifies this for the onchain
+space. Both address spaces are checked before creation, preventing re-init
+attacks, even if the account is currently cold. </Accordion>
 
 <Accordion title="Who triggers compression?"> Miners automatically compress when
 virtual rent is below threshold (eg 24h without write bump). </Accordion>
 
 <Accordion title="Can active pools get compressed?">
-No. Any write bumps the virtual rent balance. Active pools never compress.
+No. Any write bumps the virtual rent balance. Active accounts never compress.
 </Accordion>
 
-<Accordion title="Do I need to run infrastructure?">
-No. Helius and Triton run the Interface RPC endpoints, self-hosting the Photon indexer is optional. But Helius Labs maintains the Photon indexer implementation.
-</Accordion>
+<Accordion title="Do I need to run infrastructure?"> No. Helius and Triton run
+the Interface RPC endpoints, self-hosting the Photon indexer is optional. Helius
+Labs maintains the open-source Photon indexer implementation. </Accordion>
 
 <Accordion title="What if the indexer is down?"> 
 Hot markets work all the same as long as Solana is up. Cold accounts cannot be loaded into hot state until your indexer or RPC provider recovers.