Skip to content

Commit 0b43467

Browse files
committed
Initial draft.
1 parent 4b1eaaf commit 0b43467

File tree

1 file changed

+101
-0
lines changed

1 file changed

+101
-0
lines changed
Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
---
2+
simd: '0164'
3+
title: ExtendProgramChecked loader-v3 instruction
4+
authors:
5+
- Alexander Meißner
6+
category: Standard
7+
type: Core
8+
status: Review
9+
created: 2025-08-05
10+
feature: '2oMRZEDWT2tqtYMofhmmfQ8SsjqUFzT6sYXppQDavxwz'
11+
---
12+
13+
## Summary
14+
15+
Adds `ExtendProgramChecked` which is the same as `ExtendProgram`, but checks
16+
that the authority signed.
17+
18+
## Motivation
19+
20+
Currently anybody can extend (increase the size and funds of) programs, which
21+
they do not control (have no authority over). This has basically no effect on
22+
the programs as many choose to deploy with max length anyway, so tailing zeros
23+
are generally not an issue. Additionally, doing so requires transferring funds,
24+
which people rarely do for no gain. However, for the sake of consistency all
25+
program management instructions should require the authority to sign.
26+
27+
## Alternatives Considered
28+
29+
Ignoring it and waiting for loader-v4 as that does not have this issue.
30+
31+
## New Terminology
32+
33+
None
34+
35+
## Detailed Design
36+
37+
Existing instructions should not be changed (so transaction parsers remain
38+
stable), thus a new instruction needs to be added, similar to `SetAuthority`
39+
and `SetAuthorityChecked`.
40+
41+
Adds a new instruction `ExtendProgramChecked` to loader-v3 which:
42+
43+
- The following instruction accounts:
44+
- 0. `[writable]` The program data account.
45+
- 1. `[writable]` The program account.
46+
- 2. `[signer]` The authority.
47+
- 3. `[]` System program, optional, used to transfer lamports from the payer
48+
to the ProgramData account.
49+
- 4. `[signer]` The payer account, optional, that will pay necessary rent
50+
exemption costs for the increased storage size.
51+
- The following instruction data:
52+
- The enum discriminant `8`.
53+
- `u32` (little endian): Number of bytes to extend the program with.
54+
55+
`ExtendProgramChecked` behaves exactly the same as `ExtendProgram`, except
56+
that:
57+
58+
- It is initially disabled. The associated feature gate must then enable
59+
`ExtendProgramChecked` and disable `ExtendProgram`.
60+
- It is available to be invoked via CPI.
61+
- It expects the instruction account at index 2 to be the authority and
62+
the two optional parameters are shifted up by one each.
63+
- Immediately after the check that the program is not finalized
64+
(which throws `Immutable`) it additionally must check (in that order) that:
65+
- the provided authority matches the one stored in the program data account,
66+
otherwise throwing `IncorrectAuthority`
67+
- the provided authority is a signer, otherwise throwing
68+
`MissingRequiredSignature`
69+
70+
`InvalidInstructionData` must be thrown when a disabled instruction is invoked.
71+
72+
## Impact
73+
74+
A program is usually extended for a subsequent upgrade / redeployment which
75+
does require an upgrade authority anyway. Thus the additional requirement of a
76+
upgrade authority should not impose any new requirements on the extend-upgrade-
77+
workflow.
78+
79+
For programs which do self upgrade (have their own upgrade authority) via a CPI
80+
call, they will have to first upgrade themselves to support the send the
81+
`ExtendProgramChecked` instruction, before the feature of this SIMD becomes
82+
active. We recommend to also add support for the loader-v3 `Migrate` (to
83+
loader-v4) instruction and the new loader-v4 program management instructions
84+
while at it.
85+
86+
For programs which are upgraded by an external upgrade authority via the CLI,
87+
there should be no noticable difference for dApp developers. The CLI will check
88+
the active feature set and either send `ExtendProgram` or
89+
`ExtendProgramChecked` accordingly.
90+
91+
Independently of which upgrade path is used, one can opt to preemptively extend
92+
the program to maximum size before the feature of this SIMD becomes active,
93+
provided they are willing to lock the required rent exemption funds. Loader-v3
94+
does not support truncation / shrinking of programs, but loader-v4 does. Thus,
95+
after a program is migrated to loader-v4 it is possible to undo this and
96+
retrieve the locked funds, sending them to a recipient of your choosing,
97+
provided the programs authority signs.
98+
99+
## Security Considerations
100+
101+
None.

0 commit comments

Comments
 (0)