SeametryOpen-AP ETF

The Key

Who can change the Hall today, what they can and cannot do with that power, and what the final program must carry once the Key is gone.

The Key is still in hand.

WarnDevnet Hall. Key still in hand.
Cluster
Solana devnet
Program
Upgrade authority

Observed at slot 518,500,749, Wed, 04 Nov 2026 07:25:58 GMT, from the Solana devnet RPC, upgradeable loader.

Devnet builds remain upgradeable while the Hall is being built. The mainnet ceremony follows a program audit and legal read. Until then, every surface says what the chain says now, and this page reads it on every visit.

Who can change the Hall right now?

On Solana, a program's code can be replaced only by its upgrade authority: one key, recorded on chain next to the program. That key is what Seametry calls the Key. While someone holds it, the program can be changed. Once it is set to none, the program can never change again, by anyone, including Seametry.

In practice: while the Key exists, the rules you checked today can be different tomorrow. Once it is set to none, the code you checked is the code that runs, permanently.

You do not have to take this page's word for it. The Solana command line reads the same record:

$ solana program show GB1hX1FXQcAUWU23Ji6RtvhTzCKz84ScUsBeD7CqQnjE --url devnet
Program Id: GB1hX1FXQcAUWU23Ji6RtvhTzCKz84ScUsBeD7CqQnjE
Owner: BPFLoaderUpgradeab1e11111111111111111111111
ProgramData Address: BGiRKybxqVitKLmZSsBx91ZxcsnKFvWAS8jfPV9Ptu9x
Authority: 6SfkBGEWrvfdqwHLM2CE3RwR974uq3VaDo6bJQvP1G5J
Last Deployed In Slot: 507481659
Read live by this page at slot 518,500,749, Wed, 04 Nov 2026 07:25:58 GMT, from the Solana devnet RPC, upgradeable loader. Run the command with the Solana CLI and compare.

What can the holder of the Key do, and what can't they?

The holder can replace the program's code. Nobody else can, and once the Key is thrown away, nobody can at all. Try both sides of that rule:

The upgrade is signed by
The Key
upgrade signed by   another wallet
upgrade authority   6SfkBG…1G5J
loader decision     REFUSED

Refused. The loader requires the upgrade authority's signature; any other wallet's upgrade fails before it touches the program.

A model of the upgradeable loader's rule, not a transaction. The authority shown is the one this page read from devnet.

That is why the Key matters more than any promise about behaviour. A promise can be broken by the next version of the code. A program with no upgrade authority has no next version.

What must the final Hall preserve?

Three guarantees. Every design decision in the Hall exists to make them literally true, and the final program must carry all three.

The melt always works. Delivery is each issuer's. Burning shares for a claim on the constituents can never be blocked by anyone. Delivering each constituent is subject to that constituent's issuer, and the Hall says so rather than pretending otherwise.

In practice: if an issuer freezes one stock, you can still Melt. The frozen stock stays yours as a named Claim, and the others are delivered. You can try it on How it works.

The Hall adds no prerogatives of its own. The share mint has no freeze authority, no permanent delegate, no pause, no hook. No instruction lets anyone alter a formula, move a holder's assets, or stop a melt.

In practice: the issuers of the stocks inside an Alloy keep their powers, and the Hall states them. The Hall itself adds none on top, so an Alloy share can never be frozen or taken by the Hall.

The Hall never needs a price. Strike and melt move quantities. No oracle, no quote, no NAV is an input to any instruction. Price manipulation cannot touch minting, and the Hall keeps working when every price source is down.

In practice: a Strike of 10 shares costs the same quantities whether prices are calm, moving fast, or unavailable.

Which instructions move constituents, and which only keep records:

instruction   what it does                                     moves a constituent
create        pulls exactly the required units, mints shares   yes, every leg, in
redeem        burns shares, credits a Claim on every leg       no
withdraw      delivers one leg of a Claim                      yes, that one leg, out
sync          reconciles one leg's records with its balance    no, reads only

Because redeem moves no constituent, a freeze, a pause or a transfer hook, which all act on transfers, has nothing to stop. That is the first guarantee, built into the instruction rather than promised beside it.

The Hall reads quantities.

Strike and Melt do not use an oracle, a quote or NAV as an instruction input.

What does "final" mean, if the Hall still needs to improve?

An upgrade path is an admin key with a better name. So the Hall never upgrades in place. Each version is its own program, made final once. Improving the Hall means deploying a new version beside the old one. The old Hall keeps working for whoever stays, and anyone can move across, because Melting is always open.

Walk through a move from one version to the next:

  1. 1You hold shares on Hall version 1
  2. 2Melt them on version 1
  3. 3Withdraw each leg
  4. 4Strike on version 2

Once made final, version 1 keeps its code for good. Nothing about your shares changes because a version 2 exists.

Your wallet after step 1
  • 10 Alloy shares, Hall version 1
Illustrative holder and quantities. The steps are the Hall's: a new version is a new deployment, and holders leave by Melting from one version and Striking into another (docs/prd/HALL.md, section 6).

Why is the Key not thrown away today?

Because the Hall is still on devnet, a test network, and still being built. Throwing the Key away fixes the code forever, so it happens once, on the mainnet Hall, after a program audit and a legal read. When it happens, this page will show the transaction that did it, and the panel at the top will read the authority as none.

Inspect the program