<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>Upgrades on wid@internet:~$ </title>
    <link>https://widnyana.web.id/en/tags/upgrades/</link>
    <description>Recent content in Upgrades on wid@internet:~$ </description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 05 May 2026 15:07:35 +0700</lastBuildDate>
    <atom:link href="https://widnyana.web.id/en/tags/upgrades/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Deploy, Upgrade, and the Buffer Account Pattern</title>
      <link>https://widnyana.web.id/en/posts/solana/solana-program-deploy-upgrade-buffer/</link>
      <pubDate>Sat, 02 May 2026 10:00:00 +0700</pubDate>
      <guid>https://widnyana.web.id/en/posts/solana/solana-program-deploy-upgrade-buffer/</guid>
      <description>Solana program deploys are not atomic. They are a multi-step dance involving a temporary Buffer account, chunked bytecode writes, and a final activation step that creates or replaces the program. This post walks through the full deploy and upgrade flows, explains why Buffer accounts exist, and shows how to recover SOL when a deploy fails midway.</description>
    </item>
    <item>
      <title>How Solana Programs Actually Live Onchain: The Two-Account Model</title>
      <link>https://widnyana.web.id/en/posts/solana/solana-program-lifecycle-two-account-model/</link>
      <pubDate>Sat, 25 Apr 2026 10:00:00 +0700</pubDate>
      <guid>https://widnyana.web.id/en/posts/solana/solana-program-lifecycle-two-account-model/</guid>
      <description>Solana programs aren&amp;#39;t stored in a single account. They&amp;#39;re split across two linked accounts managed by the BPF Loader: a tiny Program Account that acts as the identity, and a larger ProgramData Account that holds the bytecode. This post breaks down the two-account model, explains why program IDs never change across upgrades, and shows how this architecture makes hot-swappable code possible.</description>
    </item>
  </channel>
</rss>
