Allow native SOL to be represented as a token #67
Conversation
| /// 0. `[signer]` Owner of the token account. | ||
| /// 1. `[writable]` Token account to release. | ||
| /// 2. `[writable]` Destination account to receive the full SOL balance of the account. | ||
| ReleaseAccount, |
There was a problem hiding this comment.
ReleaseAccount works for non-wrapped token accounts as well, and thus is effectively a replacement for Burn(u64) but also:
- Prevents a zero-balance token account that floats around forever
- Assumes that we'll redefine the
supplyfield according to Add rent awareness to spl-token #66 (comment) such that it never decreases
There was a problem hiding this comment.
If we don't have the requirement to partial burn tokens from an account then we should remove the burn instruction :-)
There was a problem hiding this comment.
Yeah, totally agree! And you can still do a partial burn by transferring to a new token account then ReleaseAccounting it.
There was a problem hiding this comment.
Though that is a two-step process (one transaction), will have a performance impact depending on how fast folks want to burn stuff
There was a problem hiding this comment.
I feel this is unlikely to be an issue, but let's see what comes out of that slack thread.
There was a problem hiding this comment.
Ok fine, no changes to Burn since partial burns seem to be a little popular.
For a normal non-wrapped token, we could:
- Consider
ReleaseAccountto also act as a fullBurn - Require the non-wrapped token have a zero token balance before
ReleaseAccountcan be called on it - Only allow
ReleaseAccounton wrapped tokens, which means a rent-exempt non-wrapped token account will always live forever.
I prefer 1.
token/src/instruction.rs
Outdated
| @@ -85,6 +85,17 @@ pub enum TokenInstruction { | |||
| /// 2. `[writable]` Token being burned. | |||
| /// 3. Optional: `[writable]` Source account if key 1 is a delegate account. | |||
| Burn(u64), | |||
|
|
|||
| /// Wrap SOL into a token account. The full lamport balance in the new account will be wrapped | |||
| /// 0. `[writable]` New wrapped account being created. | |||
There was a problem hiding this comment.
Note: I dropped the signer requirement (NewAccount should do the same IMO). Requiring a signer here means the token account can't be a derived account (aka CreateAccountWithSeed).
There was a problem hiding this comment.
You can wrap my account without permission?
There was a problem hiding this comment.
Yes but only if you leave it in as State::Unallocated (ie, you don't create and initialize your account in an atomic transaction)
There was a problem hiding this comment.
That footgun should probably be well documented
There was a problem hiding this comment.
Yeah, I'll add a comment here. The Rust/JS bindings should do the right thing. Note that Vote and Stake account initialization behave this way too.
There was a problem hiding this comment.
I added a comment, also renamed to InitializeWrappedAccount since it's not actually creating the account but only initializing it
There was a problem hiding this comment.
+1 for Initialize. This feels a lot more consistent with our native programs.
| @@ -0,0 +1,3 @@ | |||
|
|
|||
| /// The token type for wrapped native SOL | |||
| solana_sdk::declare_id!("So11111111111111111111111111111111111111111"); | |||
There was a problem hiding this comment.
There's no Mint account for wrapped SOL. But the Account::token value is set to So11111111111111111111111111111111111111111 so that the Transfer instruction can do the right thing if it's wrapped and for RPC inspection.
|
Replaced by #112 |
* fix ci solana version (solana-labs#67) * Update switchboard-program to v0.2.0 (solana-labs#66) * oracleless repay (solana-labs#64) * oracleless repay * lint * the easy way * updated test to make sure interest accumulates before repay Co-authored-by: 0xkiplet <98113383+0xkiplet@users.noreply.github.com>
TODO:
NewAccount(file a follow-up issue)