geolocation: add program scaffolding and ProgramConfig instructions by nikw9944 · Pull Request #3083 · malbeclabs/doublezero

nikw9944 · 2026-02-23T22:15:28Z

Summary of Changes

Add the doublezero-geolocation onchain program with InitProgramConfig and UpdateProgramConfig instructions
Foundation allowlist authorization via CPI to the serviceability program's GlobalState
Upgrade authority verification for program config initialization and updates
Borsh-derived instruction enum with pack/unpack serialization
Workspace and Makefile integration for build, lint, and test

Diff Breakdown

Category	Files	Lines (+/-)	Net
Core logic	12	+609 / -0	+609
Tests	4	+177 / -0	+177
Config/build	5	+93 / -9	+84
Docs	1	+33 / -0	+33

Part 1 of 3 for RFC16 geolocation verification — program scaffolding and ProgramConfig management only; GeoProbe CRUD and parent device instructions follow in subsequent PRs.

Key files (click to expand)

smartcontract/programs/doublezero-geolocation/src/state/program_config.rs — ProgramConfig account state with Borsh serialization, field-by-field deserialization, and validation
smartcontract/programs/doublezero-geolocation/src/processors/program_config/update.rs — UpdateProgramConfig processor with upgrade authority verification and partial field updates
smartcontract/programs/doublezero-geolocation/src/processors/program_config/init.rs — InitProgramConfig processor with PDA creation and upgrade authority check
smartcontract/programs/doublezero-geolocation/src/serializer.rs — Generic account create/write helpers using doublezero-program-common utilities
smartcontract/programs/doublezero-geolocation/src/instructions.rs — Borsh-derived GeolocationInstruction enum with 2 variants
smartcontract/programs/doublezero-geolocation/src/error.rs — GeolocationError enum with thiserror derives and ProgramError conversion
smartcontract/programs/doublezero-geolocation/src/processors/mod.rs — check_foundation_allowlist shared validation via serviceability CPI

Testing Verification

10 unit tests covering instruction pack/unpack roundtrips, PDA determinism, ProgramConfig serialization, error code mappings, and account type validation
Clippy clean with -Dclippy::all -Dwarnings
Formatting verified with nightly rustfmt

karl-dz · 2026-02-24T02:39:04Z

smartcontract/programs/doublezero-geolocation/src/processors/program_config/update.rs

+    let (expected_pda, _) = get_program_config_pda(program_id);
+    if program_config_account.key != &expected_pda {
+        msg!("Invalid ProgramConfig Pubkey");
+        return Err(ProgramError::InvalidSeeds);
+    }


This actually isn't needed when updating the program config since there is only one account that can be the program config (the one you initialized the program with). The discriminator defines this account, so the try_from below ensures that this account is the program config.

It doesn't hurt to have this check. But it doesn't add any safety, either

karl-dz · 2026-02-24T02:39:57Z

smartcontract/programs/doublezero-geolocation/src/processors/mod.rs

+    let (expected_config_pda, _) = get_program_config_pda(program_id);
+    if program_config_account.key != &expected_config_pda {
+        msg!("Invalid ProgramConfig PDA");
+        return Err(ProgramError::InvalidSeeds);
+    }


karl-dz · 2026-02-24T02:40:32Z

smartcontract/programs/doublezero-geolocation/src/processors/mod.rs

+    // Verify serviceability GlobalState PDA address
+    let (expected_gs_pda, _) =
+        doublezero_serviceability::pda::get_globalstate_pda(serviceability_program_id);
+    if serviceability_globalstate_account.key != &expected_gs_pda {
+        msg!("Invalid Serviceability GlobalState PDA");
+        return Err(ProgramError::InvalidSeeds);
+    }


Same as your program config, there is only one global state on the Serviceability program

karl-dz · 2026-02-24T02:43:49Z

smartcontract/programs/doublezero-geolocation/src/state/program_config.rs

+use core::fmt;
+use solana_program::{account_info::AccountInfo, msg, program_error::ProgramError};
+
+#[derive(BorshSerialize, Debug, PartialEq, Clone)]


You should probably derive BorshDeserialize or BorshDeserializeIncremental

karl-dz · 2026-02-24T02:44:45Z

smartcontract/programs/doublezero-geolocation/src/state/program_config.rs

+        let out = Self {
+            account_type: BorshDeserialize::deserialize(&mut data).unwrap_or_default(),
+            bump_seed: BorshDeserialize::deserialize(&mut data).unwrap_or_default(),
+            version: BorshDeserialize::deserialize(&mut data).unwrap_or_default(),
+            min_compatible_version: BorshDeserialize::deserialize(&mut data).unwrap_or_default(),
+        };


If you derive either borsh deserialize traits, you wouldn't have to deserialize each element like this

karl-dz · 2026-02-24T02:45:56Z

smartcontract/programs/doublezero-geolocation/src/state/program_config.rs

+            min_compatible_version: 1,
+        };
+        let err = val.validate();
+        assert!(err.is_err());


unwrap_err below will panic if this line were false

karl-dz · 2026-02-24T02:46:03Z

smartcontract/programs/doublezero-geolocation/src/state/program_config.rs

+    fn test_state_programconfig_try_from_invalid_account_type() {
+        let data = [AccountType::None as u8];
+        let result = GeolocationProgramConfig::try_from(&data[..]);
+        assert!(result.is_err());


karl-dz · 2026-02-24T02:49:08Z

smartcontract/programs/doublezero-geolocation/src/instructions.rs

+impl GeolocationInstruction {
+    pub fn pack(&self) -> Vec<u8> {
+        borsh::to_vec(&self).unwrap()
+    }
+
+    pub fn unpack(data: &[u8]) -> Result<Self, ProgramError> {
+        borsh::from_slice(data).map_err(|_| ProgramError::InvalidInstructionData)
+    }
+}


These don't seem necessary since they're light wrappers around the borsh methods

karl-dz · 2026-02-24T02:50:02Z

smartcontract/programs/doublezero-geolocation/src/pda.rs

+#[cfg(test)]
+mod tests {
+    use super::*;
+
+    fn test_program_id() -> Pubkey {
+        Pubkey::new_unique()
+    }
+
+    #[test]
+    fn test_program_config_pda_is_deterministic() {
+        let program_id = test_program_id();
+        let (pda1, bump1) = get_program_config_pda(&program_id);
+        let (pda2, bump2) = get_program_config_pda(&program_id);
+        assert_eq!(pda1, pda2);
+        assert_eq!(bump1, bump2);
+    }
+
+    #[test]
+    fn test_program_config_pda_differs_by_program_id() {
+        let (pda1, _) = get_program_config_pda(&Pubkey::new_unique());
+        let (pda2, _) = get_program_config_pda(&Pubkey::new_unique());
+        assert_ne!(pda1, pda2);
+    }
+}


You can probably do away with these tests since these seem to just exercise Pubkey::find_program_address

karl-dz · 2026-02-24T02:51:13Z

smartcontract/programs/doublezero-geolocation/tests/update_program_config_test.rs

+    let mut data = Vec::with_capacity(45);
+    data.extend_from_slice(&3u32.to_le_bytes());
+    data.extend_from_slice(&0u64.to_le_bytes());
+    data.push(1); // Some
+    data.extend_from_slice(upgrade_authority.as_ref());


Like when you deserialize the upgradeable state, you should be able to serialize it with bincode, too

smartcontract/programs/doublezero-geolocation/tests/update_program_config_test.rs

karl-dz · 2026-02-24T02:55:06Z

smartcontract/programs/doublezero-geolocation/tests/update_program_config_test.rs

+    )
+    .await;
+    assert!(
+        result.is_err(),


Are you expecting a specific error? Or are you okay with just checking that there is any error?

karl-dz · 2026-02-24T02:55:17Z

smartcontract/programs/doublezero-geolocation/tests/update_program_config_test.rs

+    )
+    .await;
+    assert!(
+        result.is_err(),


karl-dz · 2026-02-24T02:56:31Z

smartcontract/programs/doublezero-geolocation/Cargo.toml

+solana-bincode = "2.2.1"
+solana-loader-v3-interface = { version = "3.0.0", features = ["serde"] }


Do you want to add these to the workspace Cargo.toml?

Add the doublezero-geolocation onchain program with InitProgramConfig and UpdateProgramConfig instructions, foundation allowlist integration via serviceability CPI, and build/lint/test integration. Part 1 of 3 for RFC16 geolocation verification.

…heck Move the min_compatible_version > version invariant check to run after both fields are applied, so a version-only downgrade cannot silently create an inconsistent state where min_compatible_version > version.

nikw9944 linked an issue Feb 23, 2026 that may be closed by this pull request

geolocation: program scaffolding #3084

Open

nikw9944 force-pushed the bdz/doublezero-2952-part-1-program-config branch from faa0ca6 to b909d19 Compare February 23, 2026 23:29

karl-dz reviewed Feb 24, 2026

View reviewed changes

smartcontract/programs/doublezero-geolocation/tests/update_program_config_test.rs Show resolved Hide resolved

karl-dz reviewed Feb 24, 2026

View reviewed changes

nikw9944 added 5 commits February 24, 2026 15:40

fixup

6e25f36

geolocation: move serviceability_program_id to build-time constant

d7c7e68

address feedback

7176113

nikw9944 force-pushed the bdz/doublezero-2952-part-1-program-config branch from 6917536 to 7176113 Compare February 24, 2026 16:28

nikw9944 modified the milestone: Geo Location Feb 24, 2026

		solana-bincode = "2.2.1"
		solana-loader-v3-interface = { version = "3.0.0", features = ["serde"] }

Comments

Conversation

nikw9944 commented Feb 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary of Changes

Diff Breakdown

Testing Verification

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

nikw9944 commented Feb 23, 2026 •

edited

Loading