So, here’s the scoop: In January 2025, the SP1 team at Succinct really stepped up their game by sharing some great security tips. They managed to fix three vulnerabilities and decided to put a pause on those outdated legacy verifier routers. Pretty smart move, right? Check out this super helpful checklist that lays out everything you need to know about auditing zkVM “guest” programs. It’s all about making sure your proofs are solid, can be verified on-chain, and are totally ready to roll for production.

Auditing zkVM Guest Programs: A Checklist Inspired by 2025’s SP1 Security Guidance

These days, decision-makers are really turning to zkVMs to help with rollups, coprocessors, and those all-important cross-chain bridges. It's fascinating to see how this tech is shaping the way we connect and scale! Here's the key takeaway: zkVMs are great at verifying that your guest program is running just as it should, but they don’t automatically turn sketchy programs into secure ones. So, back in January 2025, Succinct dropped their SP1 Security Update, which came packed with some really effective mitigation strategies and clear upgrade instructions. We took all those insights and put together a super useful checklist that you can easily keep track of before your next launch. It's auditable, too, so you can feel confident you're covering all your bases! Take a look at it here: (blog.succinct.xyz). It's worth checking out!

Here’s what you can look forward to: Let’s break down what’s new with SP1 security in 2025 and why you should care about it. There have been some significant changes that could really impact how we handle security moving forward. It’s definitely worth keeping an eye on! Here’s a super useful audit checklist that takes you through everything from toolchains and public values to syscalls, precompiles, serialization, determinism, recursion, on-chain verification, and so much more. It’s got you covered on all the important stuff!

• Here are some real-life examples along with a few “red flags” to keep an eye on when you're doing code reviews. Here are some handy tips on when to turn on SP1-2FA (that’s TEE-backed two-factor authentication) so you can really ramp up your security game.

---

1) What changed in 2025: the SP1 security context

Back in January 2025, we launched SP1 Turbo (v4). x) Hey, just a heads up - we’ve made some key fixes!

• We fixed a glitch in the chip ordering check in the STARK verifier. This was a problem with soundness that impacted the way we directly verify core shard proofs. We’ve added a few missing calls to make sure that our recursive proof really shows a complete execution (is_complete). This was pretty significant because it meant that some partial executions could get missed and actually be viewed as complete ones.
• We fixed a little glitch in Plonky3's batching process. It turns out that the evaluation claims weren't getting integrated into the Fiat-Shamir method before we went ahead and sampled those combination coefficients. This might allow some wrong polynomial evaluations to slip through unnoticed.

If you want all the nitty-gritty details, head over to the full update at blog.succinct.xyz. It's got everything you need to know!

Succinct just launched a bunch of quick upgrades for Turbo and put a hold on the routers that connect to mainnet verifier contracts for the older versions. They also mentioned a frequent pitfall that developers often fall into: steering clear of making direct calls to HALT or any other syscalls. Just a quick tip: be sure to use the SP1 entrypoint. This way, you'll have those COMMIT events working properly, and all the public values will stay within the limits you want. It makes a big difference! Hey, if you want the scoop, take a look at the details right here: (blog.succinct.xyz).

One of the researchers mentioned some concerns they found in the SP1 SDK v3. 4. 0. They mentioned how you could mix these elements together to form proofs. They specifically highlighted a scenario with an unconstrained committed_value_digest that could come up if the COMMIT doesn't get triggered because of an early HALT. Plus, they threw in a note about an unchecked recursion condition that could also play a role. Luckily, the Turbo release has sorted out those potential vulnerabilities. If you want to dive deeper into the details, just head over to this link: blog.lambdaclass.com. You'll find all the juicy info there!

Takeaway for Leaders

Even with an awesome zkVM, it’s super important to have a strong guest program and a well-organized development process. Without those, it just doesn’t click! Vendors who work with zkVM technology have highlighted an interesting point: a lot of the security issues we see actually come from the code written by guests and the contracts associated with it, not so much from the proving technology itself. If you want to dive deeper into this, take a look at their security model. It's definitely worth your time!

---

2) Threat model refresher: what the proof actually covers

So, when we talk about proof, it really comes down to the guest program doing its own thing. The host orchestrator isn’t really involved in that. The host can toss in any kind of input, but the guest's logic and the outputs they've committed to are locked down tight with cryptographic security. Alright, so here’s the deal: when it comes to orchestration, don't put all your faith in host code. It's not something you can completely rely on. (blog.sigmaprime.io).

So, when it comes to SP1's security model, there are a few important things to keep in mind. First off, your compiled program should be memory-safe, which basically means it shouldn’t mess around with memory in a way that could cause problems. Next, it shouldn’t be doing anything shady or malicious--just keep things honest and above board. And finally, you’ll want to make sure it's well-constrained; this includes using precompiles in a safe manner. It’s all about keeping everything secure and running smoothly! Hey, just a quick note - this model operates on the idea that 0 isn’t a valid program counter in your compiled binary.
(docs.succinct.xyz).

---

3) The 7Block Labs SP1 Guest Security Checklist

Just a heads up, make sure to look at these items as "must-pass" checkpoints for PRs. It's super important before you give the thumbs up for release!

A. Toolchain, versioning, and proof types

Just a heads up, make sure you’re pinning to SP1 Turbo (v4). x or later). Hey everyone! Just wanted to give you a quick heads-up that the older versions (V2/V3) are officially being retired on the Succinct Prover Network. Mark your calendars for February 15, 2025, because that’s when it all goes down! Hey, you know what? It might be a smart move to transition your build, CI, scripts, and infrastructure over to Turbo. Take a look at the details right over here!

When you're picking a proof type, it's worth pausing for a second to consider your options. You've got core, compressed, Groth16, and PLONK on the table. Take a little time to think about what fits your needs best! Just a heads up, here are a few important things to keep in mind: So, both Groth16 and PLONK rely on trusted setups. Succinct has a special ceremony just for Groth16, and when it comes to PLONK, they’re using Aztec Ignition.
Groth16 definitely speeds things up, but it does come with a little extra trust when it comes to the ceremony. Dive deeper here. When it comes to important applications, make sure you’re using the approved versions of the software. And don’t forget to update those security patches as soon as they’re released! It's super important to keep everything safe and running smoothly. If you're looking for more details, you can check it out here.

B. Reproducible, attestable builds and vkey checks

Hey, just wanted to give you a quick heads up: those development builds can be a bit unpredictable sometimes.
As you get ready for production, don’t forget to take advantage of SP1’s reproducible build process. It’ll help you whip up a consistent ELF that you can rely on every time. For all the juicy details, just hop on over here. Enjoy!

Hey, just a quick reminder to double-check that the verification key (vkey) you received from your ELF aligns with what the on-chain verifier is looking for. It's always good to make sure everything matches up! SP1 projects, like Blobstream, have a straightforward method for creating reproducible builds and doing verifications. First off, you'll want to build it using cargo prove, just remember to tag it with Docker. After that, just run the vkey tool and make sure to cross-check it with the contract to ensure everything lines up. It's pretty simple once you get the hang of it! Including this step in your CI pipeline is a smart move! If you're looking for more details, check this out here. You'll find everything you need!

Here's a little background for you: Reproducible builds focus on giving a clear and verifiable trail from the source code to the final binary. This approach has really gained traction in the industry because it helps build trust in the supply chain. If you're interested in diving deeper into the topic, you can check it out here. Happy reading!

C. Public values (I/O) discipline: commit the right things, in the right order

Hey, just a quick note: the only data that gets shared with verifiers is the stuff you commit inside the guest using sp1_zkvm::io::commit or commit_slice. So, make sure you’re keeping that in mind! Just a heads-up: when they read those public values, they'll do it in the exact sequence you set them up. So, it’s important to think of that order as part of your ABI! If you want to dive deeper into the details, just click here. Happy exploring!

Watch out for this common mistake: don’t call HALT too soon or return before your deferred COMMIT events have a chance to complete. It’s important to let them finish up before moving on! Make sure to stick to the usual program entry point, and try to avoid directly calling HALT or syscalls. It's just cleaner that way! This will help you steer clear of those pesky “unconstrained public value digest” issues that Turbo has already worked through at the recursion layer. Plus, it’ll protect you from any slip-ups that developers might accidentally introduce. If you want to dive deeper into this, check out this blog post. It’s got all the details you’ll need!

I totally get it! Looks like you shared an example but didn’t include any actual text for me to rewrite. No worries, though. Just send over what you want to have revamped, and I'll be happy to help! Sure thing! Just send over the text you want me to rework, and I’ll gladly give it a makeover for you!

use sp1_zkvm::syscalls::syscall_halt;
fn main() {
    // ... compute outputs ...
    syscall_halt(0); // dangerous: bypasses normal commit/exit semantics
}

Absolutely, I'm here to help! What do you need assistance with? Sure! Just share the text you want me to rewrite, and I'll dive right in!

fn main() {
    let out = compute();
    sp1_zkvm::io::commit(&out);
    // return normally; let the SP1 entrypoint handle HALT safely
}

D. Syscalls and “unconstrained” code: minimize and justify

• Whenever you can, try to use patched crates and safe wrappers instead of jumping right into direct syscalls. SP1 comes with a lot of handy syscalls, such as those for SHA-256 extend/compress, secp256r1 operations, and basic read/write functions. However, diving straight into them can be a bit tricky and might land you in some tough spots. So, it’s definitely worth taking a moment to get the lay of the land before you start! It's kind of like handling unsafe Rust--only dive into it when you really need to, and definitely make sure you’ve got some tests set up beforehand. Hey, if you want to dive into the details, just head over to docs.rs. You’ll find everything you need there!
• The unconstrained macro lets you execute code without being held back by the VM's limits. Just a heads up--make sure to be careful with this. It's best to use it for precomputing hints that won’t interfere with any outputs you've already committed to. And seriously, don’t rely on it for figuring out values you're planning to commit later without giving everything a good double-check first. Better safe than sorry! It's really crucial to jot down every time you use it. Make sure to include your thought process and any tests you run, too. Trust me, you’ll be grateful for that later! If you want to dive deeper, you can check out more info over at docs.rs.

Red Flag Pattern:

So, the term "red flag pattern" pops up a lot in trading, especially when we’re diving into technical analysis. It helps traders spot potential red flags in the market, letting them know when something might be a bit off. Here's a quick breakdown:.

What is a Red Flag Pattern?

A red flag pattern usually pops up when there's an unexpected shift in price or volume that strays from the usual trends. It's like a little warning sign that something might be off. This might mean that someone is trying to mess with the market or that something big is about to happen.

Key Features to Look For:

1. Unusual Volume: Be on the lookout for any sudden jumps in trading volume. If you notice that a stock that typically has low trading volume suddenly spikes up, it could be a good idea to look into what's going on.

2. Price Gaps: So, price gaps are those moments when the price suddenly leaps from one level to another without any trading happening in between. When you see one of these, it usually means something unexpected has gone down, so it’s definitely a good idea to be careful.

3. High Volatility: When a stock starts to bounce around in price like crazy, it usually means that traders are reacting to some news or rumors floating around. But let's be real -- not all of that information is trustworthy.

4. Divergence: Keep an eye out for any differences between how the price is moving and what the indicators are showing. So, let’s say you’re watching a stock that’s reaching new highs. Pretty exciting, right? But if you notice that the RSI (Relative Strength Index) is actually dropping at the same time, that might be a hint that the stock’s upward momentum is starting to fade. Just something to keep in mind!

Examples:

• False Breakouts: Sometimes, a stock will push through a big resistance level, but if it snaps back down right after, that's definitely a warning sign to watch out for.
• Earnings Reports: So, if a company puts out its earnings report and the stock price takes a nosedive, even though the results look solid, it might mean there's something fishy going on that needs a closer look.

How to Respond:

If you notice a red flag pattern, don’t freak out! Just take a moment to breathe and step back. Here are a couple of things you might want to check out:

• Research: Take some time to explore the latest news about the stock or the market.
• Reevaluate Your Situation: Think about whether you should cash in on your gains or let go of some losses.
• Stay in the Loop: Make sure you’re keeping an eye on market trends and insights from reliable sources. It’ll help you see the bigger picture!

Conclusion:

It's super important for traders to spot red flag patterns because catching them early can save you from some serious losses down the line. If you keep yourself updated and stay on your toes, you'll be able to navigate the markets better and make wiser trading choices.

let y = sp1_lib::unconstrained!({
  // network call / randomness / anything host-like (don’t do this in guest)
  // or critical business logic
});
// ... later ...
sp1_zkvm::io::commit(&y); // committing values derived *outside* constraints

E. Serialization and input handling: bound everything, avoid cycle-heavy formats

Try not to use generic serializers to cover your cycles unless absolutely necessary. Hey there! So, if you’re looking to boost SP1's performance, I've got a couple of tips for you. First off, try using zero-copy I/O paths like read_slice or read_vec. They can really simplify things. Also, consider using formats that are similar to rkyv, and don’t forget about commit_slice for handling bytes. These tricks should help you get the most out of your setup! Just remember to put some limits on how long the input can be and make sure to check everything out front. It’s a good way to catch any issues early on! Check it out here.

Hey, if you’re diving into serde types, just make sure you approach it with care. Take a moment to really profile your work--it’ll make a difference! So, there's some context about the hiccups bincode has with zkVM I/O. Luckily, our team has brainstormed and developed some much better solutions that really align with what we need. If you want to dive deeper into it, you can check it out here.

F. Precompiles: use patched crates, not raw syscalls

Hey there! So, SP1 Turbo just dropped some really cool new precompiles, including secp256r1 and bigint for RSA. Pretty exciting stuff! On top of that, it includes a growing set of "patched crates" that modify the usual library calls--like sha2 and sha3--so they can take advantage of optimized syscalls instead. Hey, if you're teaming up with them, I'd really recommend using the patched crates instead of diving into those precompile syscalls directly! Trust me, it’ll make your life a whole lot easier. Check out this link for more details: blog.succinct.xyz.

Alright, let's dive into the precompile specs! Basically, what we’re looking at here are these custom STARK tables that you can access through RISC-V ecall, and they use specific syscall numbers to get the job done. When you're going through audits, remember to double-check that you're using the approved versions of those patched crates. Also, don’t forget to validate your inputs properly--it's super important! (docs.succinct.xyz).

G. Recursion correctness: assert “complete execution” and test for early-exit shenanigans

Turbo patches help fill in those tricky spots where calls ensure that recursive proofs are actually complete executions. Just a quick reminder--make sure you include tests to catch anything important your program might miss, like returning early before it wraps up all its commitments. You don’t want to overlook those key checks! This is really important, especially when you're dealing with compressed proofs or on-chain gateways. (blog.succinct.xyz).

H. On-chain verification gotchas: hash functions and gateways

As of now, SP1's Solidity verifier is using SHA-256 to hash public values. Hey there! Just wanted to give you a quick heads up: if you decide to activate the blake3 feature in sp1-zkvm, your proofs might not match up with what the standard on-chain verifier expects. Keep that in mind! Alright, just a heads up--make sure to keep that feature switched off in production unless you’re the one in charge of the verifier. Better safe than sorry! If you want to dive deeper into the details, just click here. You'll find all the info you need!

Hey, just a quick heads-up! If you’ve made the switch to Turbo after the incident, double-check that your verifier gateway/router addresses and vkey roots are all set to the Turbo-safe deployments that Succinct has rolled out. It’s super important to keep everything aligned! This was included in the response back on January 27, 2025. If you want more details, just click here. Enjoy!

I. Determinism: no ambient entropy, clocks, or host assumptions

• The guest code runs in a virtual machine that doesn’t have an operating system or any internet access. To work with anything labeled as "ambient," you’ll first want to set it up as input. You can do this using io::read to grab the data, and then make sure to validate it afterwards. Try not to depend on things like time, randomness, or anything coming from the host, unless the guest has confirmed that info through their inputs. (blog.sigmaprime.io).

J. Memory safety and undefined behavior

Alright, so here’s the deal with SP1's model: it's founded on the belief that we're working with a program that's not out to cause any harm and is safe when it comes to memory usage. It helps keep the reserved memory areas in the AIR secure by making sure those register spots are protected. But hey, if you've got some sketchy undefined behavior (UB) sneaking into your Rust code, it's on you to make sure it's all locked down. To handle this, you should stick to safe Rust practices, run Miri, and don’t forget to add some fuzzing into the mix. (blog.succinct.xyz). Just a quick tip: try to avoid using any layout tricks that only work on certain platforms. If you're thinking about ABI stability, don’t forget to use repr(C). It's a good practice to keep in mind! Oh, and make sure to add test vectors that can handle inputs and outputs when they're being roundtripped across different versions! It'll save you a lot of hassle later on.

K. Proving infra and upgrades

If you've got some heavy lifting to do with your workloads, I definitely recommend checking out the (patched) Succinct Prover Network. It’s a solid choice! It's awesome because it can manage proofs across a cluster, which really helps reduce latency while keeping the costs steady. Oh, and here’s the exciting part: this is where the awesome security feature, SP1-2FA, makes its debut. Take a look at this: blog.succinct.xyz. You'll find some really interesting stuff there! Hey! Don’t forget to subscribe to our Succinct advisories and blog. You won’t want to miss out! So, after January 2025, they launched some pretty major upgrades for performance and security. Imagine it like going from Turbo to Hypercube - it's a big leap! Keeping yourself updated is a really good strategy for handling your risks. If you’re looking for more info, just check this out: blog.succinct.xyz.

---

4) Hands-on example: auditing a signature-verification guest

Scenario: Validating Messages and Generating a Merkle Root

In this situation, your guest will dive into reading a bunch of messages along with ECDSA-secp256r1 signatures. It's going to be quite interesting! Alright, let me walk you through what happens, step by step:

1. Checking Out Messages: Your guest takes a moment to dive into the messages, making sure they've got all the important details covered.

2. ECDSA-secp256r1 Signatures: Every message has its own unique ECDSA-secp256r1 signature that you’ll need to check for verification. This step is super important for making sure that every message stays reliable and trustworthy.

3. Verification: The guest goes through and checks each signature. If everything looks good, it means the message is legit.

4. Hashing Valid Messages: So, when we talk about valid messages, they actually get hashed. This gives each message a unique fingerprint, which is super important for building the Merkle tree.

5. Getting the Merkle Root: So, here’s the deal--once we have all those valid message hashes lined up, they go into the Merkle tree. From there, your guest will generate the Merkle root. This root shows how trustworthy the valid messages are as a whole.

Alright, let’s break it down. Your guest checks out the messages, makes sure the signatures are legit, hashes the ones that pass the test, and in the end, they’ve got this Merkle root that ties everything together. Pretty cool, right?

Checklist Walk-Through (With Fixes)

Here’s a super helpful checklist you can follow to ensure everything’s in great shape. Here are some common problems you might run into, along with some simple solutions to help you get things back on track.

1. Initial Setup

• Take a look at your setup: Before you jump into things, double-check that everything’s in order. It’s always good to make sure you’ve got everything you need!
• Fix: If you notice any missing dependencies, just go ahead and install them by running this command:

  npm install

2. Code Quality

• Lint your code: Keeping things consistent is super important! Don’t forget to run your linter to spot any style issues you might have missed.
• Fix: If you spot any mistakes, just go ahead and fix them. You can easily set up auto-formatting using:

  npx prettier --write .

3. Functionality Tests

• Run your tests: Seriously, don’t forget to test! Go ahead and run your test suite to make sure everything’s functioning like it should. It’s super important!
• Fix: If your tests don’t pass, check out the error messages and tweak your code accordingly.

4. Performance Checks

• Keep an eye on performance: Make sure to check how your app holds up when there’s a lot going on.
• Fix: If you notice any spots that are running slow, think about tweaking your algorithms or using some caching techniques to speed things up.

5. User Interface

• Check out the UI designs: Take a look and see if the user interface matches up with what you had in mind in your design specs.
• Quick Tip: If something seems a bit off, take a moment to check your CSS and HTML. A little tweak in the layout or styling can make a big difference!

6. Security Measures

• Look for any weaknesses: Running a security audit is definitely a smart move!
• Fix: If you find any vulnerabilities, here's what you can do:

  npm audit fix

7. Documentation

• Keep your docs updated: Remember to jot down any changes you’ve made! It’s super important to have everything documented.
• Fix: If your documentation is looking a bit stale, take some time to update it so it matches where your project is at now. It's super important to keep everything current!

8. Deployment

• Get ready to launch: Double-check that everything’s set and good to go for the big day!
• Fix: If you’re running into deployment errors, it’s a good idea to take a closer look at your configuration files and deployment scripts. Make sure everything’s set up right!

Conclusion

Take a quick look at this checklist to see if there's anything you might have overlooked. Just tackle each item one by one, and you'll have your project running smoothly in no time!

1. The inputs you’re working with are pretty limited in what they can do, and they’re specifically set up for zero-copy operations.

#[derive(serde::Deserialize)]
struct SigInput { /* msg, sig, pk */ }

// Better: read bytes, then parse with a zero-copy schema.
let raw = sp1_zkvm::io::read_vec();           // zero-copy
// parse_raw() should bound lengths and validate structure.
// Avoid variable-sized allocations without caps.
let items = parse_raw(&raw).expect("invalid input");

So, what's the deal? Well, the goal here is to keep the witness size manageable and avoid those generic (de)serialization methods that often get stuck in endless loops. (docs.succinct.xyz).

2) Use Patched Crates for Hashing; Avoid Raw Syscalls

When you start getting into hashing, it’s definitely a smart move to use patched crates instead of just going for raw syscalls. Trust me, it’ll save you a lot of headaches down the line! This can save you from a lot of headaches and help you keep your code nice and tidy. Here’s why:.

1. Security: Updated crates have fixes for vulnerabilities, which is great because they keep things safer. On the flip side, if you’re using raw syscalls and not managing them carefully, you could be opening yourself up to some serious security risks. Just something to keep in mind! 2. Simplified Upkeep: Using patched crates means you tap into a whole community of support and enjoy regular updates. It's like having a team of folks looking out for you! This really helps you keep your code in check down the line. 3. Cross-Platform Compatibility: When you use crates, you can breathe a little easier knowing that your code is more likely to work smoothly across various operating systems.

If you’re diving into Rust, check out crates like sha2 or rust-crypto. They’re not only solid and reliable but also kept up to date, so you can feel confident using them! Trust me, you’ll be really glad you dodged the hassle of dealing with raw syscalls later on!

# Cargo.toml (guest)
# Routes sha2 to SP1 precompiles; versions must match your SP1 release
sha2-v0-10-9 = { git = "https://github.com/sp1-patches/RustCrypto-hashes", package = "sha2", tag = "patch-sha2-0.10.9-sp1-4.0.0" }

So, here's the deal: we've been diving into ways to boost our speed while still keeping everything within the right limits. We're really trying to avoid those quick-fix syscall connections. Take a look at this: (docs.succinct.xyz). You might find it super helpful!

1. Instead of handling signature checks in an "unconstrained" way, let's use precompiles to get the job done. ”.

use p256::ecdsa::{VerifyingKey, Signature}; // routed via patched crates/precompiles when available
let vk = VerifyingKey::from_sec1_bytes(&item.pk)?;
let sig = Signature::from_der(&item.sig)?;
vk.verify(item.msg, &sig)?; // executed with SP1 acceleration under the hood

• Why: Unconstrained code runs outside of the virtual machine, so it's best to avoid using this method to get committed values. (docs.rs).

1. Just make sure that the outputs come in a consistent order, and then go ahead and return them like normal.

let root = compute_merkle_root(valid_msgs);
sp1_zkvm::io::commit_slice(root.as_bytes()); // public
// return; SP1 handles COMMIT/HALT correctly

• Why: The verifier goes through public values in the exact order they were committed, so definitely don’t cut corners and stop early! (docs.succinct.xyz).

1. Make sure you've selected the right proof type and double-check that it's compatible with the blockchain.

• Go ahead and use SHA-256 for public value hashing since that's the standard option. It's the way to go! Hey there! If you’re planning to use the regular Solidity verifier, you might want to just skip over the blake3 feature. (docs.succinct.xyz).

1. Making sure we have reproducible builds and verifying vkey in our CI process. Alright, the first step is to build the ELF by running cargo prove. Just a heads up, make sure it’s tagged for Docker when you do! Once you're done, go ahead and run the vkey tool. Just make sure to compare it with the vkey root that's saved in the contract before you hit that deploy button. If there's a mismatch, it's best to just let CI fail. (succinctlabs.github.io).

---

5) Emerging best practices from SP1 Turbo and beyond

Hey, have you heard about those new precompiles? There’s secp256r1 and the bigint for RSA, and let me tell you, they can really save a ton of cycles! This is fantastic news for wallets, identity solutions, and any enterprise workloads that rely on non-secp256k1 curves! Just a heads-up: double-check that the cryptography options you’re picking match up with the precompiles that are available and the patched crates you're working with. It’s super important to keep everything aligned! Hey, take a look at this: (blog.succinct.xyz). It's worth checking out!

When you're diving into performance tuning, think about a few key things. First off, consider whether to go with thin or fat LTO - it can really make a difference. Also, setting your codegen-units to 1 is a smart move, and don’t forget to trim away any unnecessary copies. These little adjustments can really help boost your performance! The SP1 docs have some super helpful tips on compiler flags and I/O optimizations! And if you can, please try to keep the use of serde to a minimum. If you want to explore more, check this out: docs.succinct.xyz. Happy digging!

Just a quick reminder to keep an eye on SP1 Hypercube and their work on formal verification! They’ve got some interesting stuff going on, especially with those formally verified RISC-V constraints. These new developments are really taking performance to the next level and boosting confidence when it comes to deploying zkVMs. If you're looking for more details, check it out here: blog.succinct.xyz.

---

6) When to enable SP1-2FA (TEE-backed two-factor proving)

SP1-2FA takes your SP1 executor and runs it right inside an AWS Nitro enclave. It's crafted to make sure that the outputs from the enclave are verified and align perfectly with the ZK proof. What this really means is that you’ve got a robust defense-in-depth strategy in place. For someone trying to mess with the results, they would need to get past both the ZK and the hardware isolation. That's no easy feat! That’s a pretty tough cookie to crack!

If you're diving into the Prover Network, you’ll be happy to know that integrating it is super easy--just a single line of code does the trick! Right now, it's in private beta, and there’s a security audit lined up for 2025. Check out these awesome ways you can use it:

• We're talking about those high-stakes transactions or critical bridges where if someone pulled off a proof forgery, it could lead to total chaos.
• Managed enterprise setups that need hardware-based confirmations for security.
• Just a quick reassurance while we’re working on expanding the formal verification coverage.

If you’re looking for more details, be sure to take a look at this blog post! It's got some great info.

Hey there! Just a heads-up: SP1-2FA is designed to keep you safe from any issues with the proving system. However, it won't protect you from bugs that might pop up in the application itself. So, stay alert! Hey, just a quick reminder about that guest audit we talked about earlier--don't let it slip your mind! Take a look at this: blog.succinct.xyz! I think you’ll find it really interesting!

---

7) Vendor questions to ask before greenlighting a release

Hey! Could you let me know the specific SP1 version you’re working with? Also, what proof type are you using, and which patched crate tags do you have pinned down? Oh, and don't forget to share the lockfiles and tags too. Thanks! Could you walk us through the steps to reproduce the build? Also, it’d be great if you could show us how to check that the vkey matches up with the on-chain verifier. Thanks!

• Could you please compile a list of all the times when we use unconstrained or direct syscalls? Also, it would be really helpful to include some tests that show these calls don’t mess with the committed outputs. Thanks! Sure! When it comes to deserialization, it’s important to outline the input limits and think about any fuzzing or negative test scenarios you might want to run.

First off, let’s talk about the input bounds. Make sure you define what types of data are acceptable and set clear limits on things like string lengths, numerical values, and any other specific formats you’re expecting.

Now, onto fuzzing and negative testing. Fuzzing is all about throwing unexpected or random data at your deserialization process to see how it handles the chaos. You might want to test with overly long strings, invalid data types, or even malicious payloads to check if your system can take a hit and still stand strong.

Always keep in mind that you want your tests to cover the risky edges of your inputs. That way, you’re better prepared for anything that might come your way!

• If you’re using a custom approach for public value hashing, could you show us how it works with the verifier and contracts? That’d be super helpful! Hey there! If you're using the Prover Network, could you let me know if SP1-2FA is switched on? Also, what’s the process for verifying attestation? Thanks!

---

8) Quick red flags to stop a merge

• Jumping straight into syscalls, like HALT, write, or read, without a good reason or thorough testing isn't really the best approach. (blog.succinct.xyz).
• Basically, it’s any free block that generates values that are committed down the line. (docs.rs).
• Jumping into read_vec without checking the lengths first? Yeah, that's a pretty big no-no.
• We're going to enable Blake3 public value hashing with the goal of using the standard Solidity verifier. (docs.succinct.xyz).
• Ignoring the January 2025 router freeze recommendations or sticking to pre-Turbo branches. (blog.succinct.xyz).

---

9) Action plan you can run this week

Hey! If you haven't done it yet, don’t forget to switch over to SP1 Turbo. You’ll want to check it out! Once you’ve done that, feel free to re-run your proofs and on-chain verifiers in the staging environment. If you want to dive deeper into the details, just click here! Alright, let's kick things up a notch with some continuous integration (CI) checks! First off, you want to make sure your builds can be replicated easily--so no surprises there. Next, don’t forget to verify the vkey. It's super important! Also, run cargo-audit on all your sp1_* crates to catch any potential issues. And hey, make it a rule to block any "unconstrained/syscall" patterns unless you've got waivers sorted out. Just a little precaution to keep everything running smoothly! Hey, just a quick reminder--make sure you switch over to those patched crates for your crypto primitives. And definitely take advantage of those zero-copy I/O paths! They’re going to make your life a lot easier. If you’re looking for more details, check out the documentation right here. It's got everything you need to know!

• Finally, don’t forget to stage SP1-2FA for your top-priority proving jobs. It’s a great way to bump up your security just that little bit more! If you're curious and want to dig deeper into that, you can check it out here.

---

Closing

When it comes to zkVM guest programs, you absolutely have to audit them. After all, the strength of those proofs really hinges on the quality of the code they’re linked to. The 2025 SP1 security updates really pointed out some of the typical mistakes people make with guest programs. They also shared some awesome tips for putting up those much-needed guardrails in your pipeline.
If you go through this checklist, you’ll be able to ship your work faster, feel way more confident about what you’re doing, and dodge any surprises when audit time rolls around.

Hey there! If you’d like 7Block Labs to take a look at your SP1 codebase, we’ve got this handy checklist we can work through together. After that, we can give you a detailed gap analysis, which will pinpoint the specific fixes you need. Plus, we'll whip up a migration plan to help you transition to Turbo or Hypercube-compatible flows smoothly. And don't worry, we’ll also set up some CI guardrails for you so you can keep everything running smoothly even after we've wrapped things up. Sounds good?

---

Sources and further reading

• SP1 Security Update (Jan 27, 2025): Great news! We've fixed some security issues with Turbo. If you want to know how to upgrade or what to do if your router starts acting up, we've got you covered! (Read more here).
• LambdaClass Update: We’ve rolled a few issues together in the sp1‑sdk v3.

4. You've got some proofs to whip up, right? Well, good news--this has been fixed in Turbo! Check out all the details right here! (Details here).

• SP1 Docs: Check out all the details on inputs and outputs, as well as compilation and optimization. You’ll also want to look into patched crates, precompile specs, and the security model. And hey, don't overlook the Blake3 caveat--it's an important one! Everything you need is right here! (Explore the docs).
• SP1 Turbo Release: We’ve got some thrilling news to share! We've rolled out some new precompiles, like secp256r1 and RSA/bigint, plus we’ve nailed down some pretty awesome cluster proving benchmarks. (Check it out!).
• RISC Zero Security Model: Just a quick heads-up--it's really up to you to make sure your guest program is secure! This is a handy way to get your threat models all lined up. (Learn more).
• Reproducible Builds Background and SP1 Example (Blobstream): So, let’s dive into a quick guide on verifying vkeys--what it is, why it matters, and a little example to get you started! It's really important to make sure your builds can be consistently reproduced. (Read more).
• Big News About SP1-2FA: We’re excited to announce that we’re introducing a second factor backed by TEE on the Prover Network! Right now, it’s in private beta, so stay tuned for more updates! Hey, that's some exciting news! If you want to dive deeper into it, check this out: Find out more.

---