Summary: Blockchain APIs are key players in handling important money transactions. So, if something goes wrong--like making too many calls, having leaked keys, or not managing tokens properly--it can actually result in real financial losses. In this guide, we'll dive into the newest trends in rate-limiting strategies, key and token security, and best practices for managing secrets. We've put together some reliable, provider-specific numbers, designs that meet RFC standards, and real-world examples to support decision-makers interested in adding nodes, relayers, or data services, whether they're at a startup or a bigger company.

Blockchain Integration API Security: Rate Limits, Keys, and Secrets Management

Decision-makers who are exploring blockchain integrations are really navigating a pretty unique landscape. Your "web API" typically connects with signing systems and node endpoints that handle a bunch of tasks. These range from broadcasting transactions to keeping an eye on pay-per-call costs, and even driving some pretty big operational changes. Recently, we've seen a rise in attacks that target specific weaknesses--like rate-limit exhaustion, leaked CI tokens, mis-issued JWTs, and those annoying long-lived RPC keys. It’s kind of a trend that’s been popping up, and it’s definitely something to keep an eye on.

Here’s a quick rundown of what’s working well in 2025: we've gathered some solid quotas, standards that might be worth checking out, and some operational patterns you can dive into right away.

1) Rate limiting that matches blockchain workloads

Why general-purpose throttling fails here

Just a heads up when you're working with Node RPCs: not all the calls are on the same level. Some methods, like debug_traceTransaction, eth_getBlockReceipts, and even the more general eth_getLogs, can really eat up your resources or rack up costs way faster than your typical read requests. So, it’s definitely something to keep in mind! Hey there! Just a quick reminder that it’s really important to set budgets for each method you’re using. It can make a huge difference! Check out the details here if you want more info.

So, here's the deal: different service providers have their own set of rules regarding quotas. This could mean anything from credits and requests per second to what they call "billing units" or BUs. It's all a bit of a mixed bag! "Just a heads up--if you push those limits too far, you could end up with your WebSocket connections getting dropped or your requests getting paused for the day. It's a bit of a pain, so keep an eye on those limits!" Better watch out! (docs.metamask.io).

Current provider numbers you should design around

Coinbase CDP Node (Base): So, for each project, you’re getting around 7,500 “billing units” every 5 seconds. That boils down to about 50 requests per second on average. Pretty neat, right? Just a heads-up, the limits can really change depending on how complicated the methods are. (docs.cdp.coinbase.com).
QuickNode: They offer endpoint-level rate limits and have some method-level caps that you can control through their Console API. Basically, you can think of it in terms of the number of requests you can make per second, minute, or even day. If you happen to exceed the limits, you'll run into a 429 error. People in the community often talk about how the basic plan lets you handle about 500 requests per second for each endpoint. (quicknode.com).
Infura (MetaMask services): So, depending on the plan you choose, there are some daily credit limits you should keep an eye on. If you go over those limits, your traffic will come to a halt for the rest of the day, and you’ll lose your WSS connections. So, just a heads-up! Yikes! (support.infura.io).
Google Cloud Blockchain Node Engine: This service hooks you up with some pretty generous API limits per minute for both the control-plane and node APIs for every project you work on. Don't forget to think about how you'll bump up your quotas as your project expands. It's super important to keep that in mind! (cloud.google.com).

Plus, some providers are really stepping up by sharing their "heavy call" lists and some solid best practices. For instance, they’re recommending stuff like using eth_getLogs with pagination, gzip compression, and batching. It’s pretty cool to see them helping each other out like that! Keeping an eye on their patterns is definitely a clever strategy. (docs.speedynodes.com).

Adopt algorithms with predictable burst semantics

Going with the token bucket method is a solid choice, especially since it lays out clear settings for “rate” and “burst.” It’s kind of similar to what you’d see in AWS API Gateway, which is pretty handy for managing your HTTP/WSS entry points. In the meantime, if you're looking to keep that steady flow in check, using a leaky bucket can really help smooth things out with NGINX. If you want to dive into the details, just head over to this link: (docs.aws.amazon.com). Happy exploring!

Standardize your response headers for clients

If you need to throttle, go ahead and send back a 429 response. Don’t forget to add a Retry-After header, and it’s a good idea to include some clear rate metadata too. Cloudflare has some great tips for production, and they recommend using headers that are straightforward and practical, like Ratelimit, Ratelimit-Policy, and retry-after. These can really help you keep things organized! It might be a good idea to keep an eye on the current IETF efforts regarding the “RateLimit” header, or you could find a schema that meshes nicely with it. (rfc-editor.org).

Practical controller patterns

To set your rate limits, consider tailoring them according to different identity tiers. You could do this based on things like each API key, specific IP addresses or CIDR blocks, individual organizations, and even different RPC methods.

Establish clear budgets for each method: Hey there! Just a quick note about eth_getLogs. Let’s cap it at N requests per second, alright? Also, don't forget to implement block-range pagination to keep everything running smoothly. Thanks!
So, when it comes to using debug_traceTransaction, just keep in mind that it's all about queuing. No sudden bursts are permitted. To get access, you’ll either need to be on an elevated plan or be part of the allowlist. Hey there! Just a quick tip: it's a good idea to keep separate pools and budgets for your WSS subscriptions and HTTP polling. Trust me, using eth_subscribe is way more efficient than constantly polling for new block notifications. You'll save yourself some headaches! Take a look at this link: docs.metamask.io. You’ll find some useful info there!

Example: Using QuickNode Method Caps through Console API

When you're diving into QuickNode, it's really useful to get the hang of accessing those method capabilities through the Console API. It makes things a lot easier! Let’s break it down!.

Step 1: Access the Console

Alright, let's kick things off! The first thing you'll need to do is hop into the Console. All you need to do is hop onto your QuickNode dashboard, and you’re good to go!

Step 2: Check Method Caps

Once you’re in the console, it’s super easy to take a look at the method caps. Here’s how you can get it done:

1. Head over to the API section. 2. Just check out the Method Caps option! It's right there waiting for you.

Another option is to use this snippet to quickly take a look at the method caps:

const methodCaps = async () => {
    const response = await fetch('https://your-quiknode-url.com/methods');
    const data = await response.json();
    console.log(data);
};

methodCaps();

Step 3: Understand the Output

Once you run the code, you'll receive a detailed JSON response that lays out all the method capabilities for you. It'll probably look a bit like this:

{
    "methods": {
        "eth_getBlockByNumber": true,
        "eth_sendTransaction": false,
        "eth_call": true
    }
}

Don't forget to take a look at the different methods you have available and see which ones you can actually use! It's always good to know your options. It’s pretty straightforward!.

Troubleshooting Tips

If you hit any snags on your journey, don’t worry! Here are some handy tips to get you back on track:

Make sure to double-check your API URL! Make sure you've got the right permissions set up for your account. Make sure to check out the QuickNode status page regularly to stay updated on any outages.

Conclusion

And that’s all there is to it! Checking method caps with the QuickNode Console API is super easy! Now it's time to really take advantage of all the awesome features at your fingertips! Happy coding!.

curl -X POST "https://api.quicknode.com/v0/endpoints/{id}/method-rate-limits" \
  -H "x-api-key: $QN_API_KEY" -H "accept: application/json" \
  -d '{
    "interval": "second",
    "methods": ["eth_getLogs", "eth_chainId"],
    "rate": 100
  }'

(quicknode.com)

2) Authentication and token designs that resist replay and confusion

Move beyond bearer-only: mTLS, DPoP, and JWT BCP

mTLS for server-to-server: To ensure your API clients stay secure, connect them using X. If you're setting up an auth server, make sure you're working with 509 certificates and issuing those certificate-bound OAuth tokens as outlined in RFC 8705. It’s all about keeping things secure and following the guidelines! This approach sets up a secure, phishing-resistant channel that's tailor-made for confidential clients. Take a look at this link: (rfc-editor.org). You might find it interesting!
DPoP (RFC 9449): This one's all about keeping your tokens in check at the application layer with a DPoP proof JWT. Basically, it helps make sure your tokens aren’t just doing their own thing and are actually valid when they’re used. Basically, you're stopping replay attacks by linking the tokens to a public key. Just a quick reminder: make sure to include the jkt confirmation, which is the JWK thumbprint, and don’t forget to add a unique jti or nonce for every request you send out! This really comes in handy when you can’t use mTLS, especially with mobile or web apps. More details here: (rfc-editor.org).
JWT Best Current Practices (RFC 8725): Make sure to manage your JWTs carefully! It’s a good idea to specify which algorithms are okay to use, like pinning down acceptable ones. Don’t forget to include an explicit typ (for instance, dpop+jwt) to keep things clear. Always validate the aud as well, and try to avoid any mix-ups with algorithms. Trust me, it'll save you a lot of hassle down the road! It's a smart move to use different keys and aud values for different types of JWTs, like session tokens compared to service tokens. This way, you keep things organized and add an extra layer of security. If you want all the details, just click right here: (rfc-editor.org).
Share your verification keys through JWKS (RFC 7517): It's super important to keep your keys fresh! Try to rotate them regularly by introducing new kid values and gradually retiring the old ones according to a set schedule. If you’ve got any sensitive info in your JWK Sets, make sure to encrypt them. But usually, you'll just be sharing public keys anyway. Check out all the nitty-gritty details right here: (rfc-editor.org). You’ll find everything you need!

Example: Minimal Public JWK Set for Your API

Check out this straightforward example of a minimal public JSON Web Key (JWK) set that you can use for your API. It's super handy! This setup makes it easy for you to share your public keys safely.

{
  "keys": [
    {
      "kty": "RSA",
      "kid": "1234",
      "use": "sig",
      "n": "modulus_here",
      "e": "AQAB"
    }
  ]
}

Breakdown of the JWK

kty: So, this just means the key type. In our situation, we're going with "RSA."
kid: So, this here is the key ID. You can use it to figure out which key you’re dealing with. Right now, it's set to "1234."
use: This is all about how the key is meant to be utilized. We’re using it to sign things, which is what we call "sig".
n: So, this is basically the modulus of the RSA key. Just swap out "modulus_here" with the real modulus value you have.
e: This is known as the public exponent. We're going with the standard value of AQAB, which is 65537. It’s a pretty common choice!

Go ahead and make any changes you need to this example so it works best for your application!

{
  "keys": [
    {
      "kty": "EC",
      "crv": "P-256",
      "kid": "2025-10-api-signing",
      "use": "sig",
      "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8Tus9uPHvRVEU",
      "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikYjKIWI5a0"
    }
  ]
}

(rfc-editor.org)

API keys: treat like credentials, not config

Hey, just a quick reminder: when your data is at rest, make sure to hash it. It’s super important to keep that focus sharp! And don’t forget to give out credentials that are specific to each environment or service. It really helps keep everything secure! It's definitely a smarter move to use short-lived credentials that get rotated, like combining OAuth2 client credentials with mTLS or DPoP, rather than relying on those static bearer tokens.

3) Secrets management: rotations, short-lived credentials, and leak prevention

KMS and HSM updates to leverage in 2025

Hey there! Exciting news: AWS KMS just dropped some awesome new features! Now, you can easily set your automatic key rotation periods anywhere from 90 to 2560 days. And if you prefer a bit more control, you can also go for on-demand rotation. Pretty neat, right? Oh, and here’s the cool part: after the second rotation, the pricing is capped! That means you can keep things rolling without it turning into one of those annoying annual tasks.
They've also simplified auditing by providing APIs that let you check out your rotation history. Take a look at this link: (aws.amazon.com). You'll find some interesting info there! So, in the Azure universe, both Managed HSM and Azure Key Vault Premium have received FIPS 140-3 Level 3 validation for the public regions. That's some serious security approval right there! This is a huge victory for anyone who's been worried about managing key custody and keeping up with compliance mapping. If you're curious to dive deeper into this topic, check it out here: Microsoft Tech Community. You’ll find some really useful info!

Kick off your security by setting up a solid root-of-trust in a cloud HSM or KMS. Just a heads up, make sure it’s FIPS-validated if that’s in the cards for you. Make sure to stash your app secrets, like RPC keys and relayer secrets, in a secure place like Secrets Manager or Key Vault. It’s a smart way to keep them safe! Make sure to set up those automatic rotations! If you can manage it, try to rotate them every four hours using AWS Secrets Manager. It’ll keep your secrets safe and sound! Make sure to plan your maintenance windows at times that won't interfere with your clients. It's all about keeping their experience smooth and hassle-free! (docs.aws.amazon.com). If you're working with Azure, you really ought to take a look at the Managed HSM key autorotation policies. They're pretty handy! Hey, just a heads up to watch out for those version caps! Remember, there’s a limit of 100 versions per key. Don’t want you to hit that ceiling! (learn.microsoft.com).

Dynamic and short-lived secrets

Consider using HashiCorp Vault to create temporary credentials with its cool “dynamic secrets” feature. If that doesn’t quite fit what you’re looking for, don’t hesitate to check out some cloud-native options instead! These TTL-bound tokens are fantastic because they really keep things in check and make revoking access super easy! (developer.hashicorp.com).

CI/CD without long‑lived cloud keys

Dive into using GitHub Actions OIDC! It’s a great way to exchange a short-lived JWT for cloud credentials, like AWS STS. It’ll make your workflow a lot smoother! With this approach, you can avoid having to store cloud keys right in your CI. Just a heads up--make sure to set id-token: write and really keep an eye on those trust policies. You’ll want to be strict about the aud and sub claims. Hey, if you're looking for more info, you can find all the details right here. Definitely worth a look!

OIDC Trust Policy Example (AWS)

So, if you're diving into Amazon Web Services (AWS) and thinking about using OpenID Connect (OIDC) for authentication, one of the first things you'll need to do is set up a trust policy. It's a pretty crucial step in the process! This policy lets AWS trust an outside OIDC provider. Let me give you a simple example to kick things off and help you out.

Example Trust Policy

Alright, here's a simple trust policy that you can use:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::123456789012:oidc-provider/oidc.example.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.example.com:sub": "user123"
        }
      }
    }
  ]
}

Breakdown of the Policy

Version: This shows which version of the policy language we’re currently using.
Statement: This is where we lay out the key details.
Effect: We're giving the green light for this action to happen.
Principal: Here, we're talking about the OIDC provider that we trust. Don't forget to swap out 123456789012 with your real AWS account ID, and make sure to replace oidc.example.com with the URL of your OIDC provider.
Action: We're giving the green light to the sts:AssumeRoleWithWebIdentity action. This step is super important because it lets us grant temporary access to resources when needed.
Condition: Here’s where you can lay out the conditions for the trust relationship. Here, we’re just making sure that the user ID is user123. Feel free to tweak this to match the specific identifiers you're working with!

Additional Notes

Be sure to tweak this policy to fit your specific needs, particularly when it comes to the Principal and Condition sections. Feel free to throw in some extra conditions if you're looking for tighter controls or want to target specific users or groups. It's all about making it work for your needs!

If you customize this example to match your own situation, you'll be on track to create a strong trust policy for your OIDC integration on AWS!

{
  "Version":"2012-10-17",
  "Statement":[{
    "Effect":"Allow",
    "Principal":{"Federated":"arn:aws:iam::<ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com"},
    "Action":"sts:AssumeRoleWithWebIdentity",
    "Condition":{
      "StringEquals":{
        "token.actions.githubusercontent.com:aud":"sts.amazonaws.com",
        "token.actions.githubusercontent.com:sub":"repo:ORG/REPO:ref:refs/heads/main"
      }
    }
  }]
}

(github.com)

Leak realities and the case for push protection

So, back in 2023, we saw a staggering 12. Wow, did you see that? There are 8 million new secrets showing up on public GitHub! That's a whopping 28% jump compared to last year. Crazy, right? What's really troubling is that a lot of these secrets stuck around even days after they were revealed. So, here we are in 2024, and things took a turn for the worse, shooting up to about 23. Wow, 8 million leaks! That really drives home just how crucial it is to have pre-push blocking and scanning in place everywhere. It's a no-brainer! Hey there! Just a quick reminder to use GitHub Secret Protection and push protection for your organization's repositories. It's a smart way to keep everything secure and under control. Don't forget to set it up! (blog.gitguardian.com).

Recently, we've noticed some sneaky supply-chain attacks that have managed to snag thousands of tokens by exploiting compromised GitHub Actions workflows. It's pretty wild how these tactics can catch us off guard! Hey there! Just a quick reminder to keep tabs on your automation tokens. It’s super important to only use the minimum workflow capabilities you really need. This way, you can stay organized and avoid any unnecessary hiccups! (techradar.com).

Logging without spilling secrets

Hey there! Just a quick reminder to stick to the OWASP logging guidelines. It's super important to avoid logging things like access tokens, API keys, or any PAN data. When it comes to personal info, make sure you're masking any PII to keep it safe. Also, don’t forget to secure your logs both while they’re being sent and when they’re stored. And hey, setting up alerts for any privilege changes or access to sensitive data can really help keep everything in check! Stay safe out there! Hey, just a quick reminder to keep an eye out for any GET parameters that could be unintentionally revealing credentials. It’s an easy thing to overlook! (cheatsheetseries.owasp.org).

4) Node and relayer specifics: avoid “RPC key = wallet key” mistakes

Keep signing systems out of application memory

If you want to keep your private keys secure, it’s a good idea to check out custody platforms or relayers backed by a KMS (Key Management System). These options make sure that your keys stay out of app memory, which really adds an extra layer of safety. So, check this out: OpenZeppelin Defender Relayers do a great job of keeping private keys safe by storing them securely in AWS KMS. On top of that, API keys are hashed in Cognito, which is pretty cool, and they come with rate limits of 100 requests per second. If you need a little extra boost, you can momentarily push that up to 300 requests per API key without any issues. Pretty handy, right? Take a look at this link: (docs.openzeppelin.com). You'll find some really useful info there!

When you're thinking about throughput, it's best to aim for around 50 transactions per minute for each relayer. That seems to be a sweet spot! This way, you can dodge any slowdowns on those fast L2s. Hey there! If you’re gearing up for any bumps in the road, don’t forget to keep an eye out for those pesky 429 status codes. It’s a good idea to have some backoff logic in your back pocket just in case! If you want to dive deeper into the details, check this out: old-docs.openzeppelin.com. It's got all the info you need!

Rate-limit your own transaction injection

Make sure to create budgets for each origin and wallet. This will help protect against replay attacks and that annoying flooding that can happen because of nonce gaps. Hey, just a quick heads-up! When you're dealing with rollups that use sequencers, keep in mind that you might occasionally face some stalls or even a bit of censorship now and then. It's something to watch out for! To keep things running smoothly, you might want to think about adding circuit breakers and using "validUntil" timeouts. This way, if any nonces get caught up, they'll be released automatically. Defender's got your back with validForSeconds and validUntil. These handy features can totally save the day by automatically doing nothing if a transaction doesn’t get mined. Take a look at the docs! You’ll find some great info there.

Cache what’s immutable

It’s really important to aggressively cache finalized blocks, receipts, and proofs. Trust me, it’ll make a big difference! Try not to poll faster than the block times. Instead, use WebSocket (WSS) to get real-time updates. It’ll make everything smoother! (docs.metamask.io).

5) Security standards to actually implement (not just cite)

Hey there! Just a heads up, you're working with data that goes up to October 2023.

Now, let’s dive into RFC 8705, which is all about OAuth 2. 0 mTLS: This one's focused on using certificate-bound tokens for secure services, which makes it ideal for those server-to-server node adapters. Check it out here.

RFC 9449 (DPoP): Looking to secure your tokens with client keys in browsers or mobile apps? This RFC has got your back! It helps to stop those pesky replay attacks by making sure each request gets its own unique jti, and it also deals with nonce challenges. Check out all the nitty-gritty details here. You'll find everything you need to know!
RFC 8725 (JWT Best Current Practices): This one really focuses on the algorithms being used, checks the aud (audience) value, and sorts token types according to typ, claims, and keys. It's a handy guide to keep things organized! You should definitely check this out - it's a really interesting read! Just click here to dive in.
OWASP API Security Top 10 (2023): This guide really emphasizes how crucial it is to address rate abuse and the risks that come with using third-party APIs (that's API4/10 for those in the know). These are definitely serious concerns that shouldn't be overlooked! Hey, just a quick heads up to keep an eye out for SSRF threats, especially when it comes to webhook integrations! If you want to dive deeper into the details, check out this link here. It's got some great info!
NIST SP 800‑57 Part 1: In this section, they talk about what cryptoperiods are and recommend that you automate key rotation depending on the type of key and how sensitive the system is. It's a pretty handy guideline if you want to keep things secure! Hey there! If you’re interested in keeping things secure, you might want to check this out here. It's got some really useful info!
**PCI DSS v4. Hey everyone! If you’re working with PANs or handling payment processes that involve card transactions, you’ll want to pay attention to this update. It’s super important! Hey there! Just a heads-up that keyed hashes and strict key lifecycle controls have become mandatory. Make sure to check out the new section 3 for all the details!

1. 1). Check it out here.

6) Reference architecture: a hardened RPC and relayer edge

Edge/API Gateway So, we've set up a token bucket system that runs at a certain rate of requests per second (RPS), and the size of the bucket is based on which tier of service we’re using from the provider. Oh, the burst capacity? It's typically around 3 to 5 times the average duration in seconds. Just a heads-up, make sure to include the Ratelimit, Ratelimit-Policy, and retry-after headers when you're sending out your requests. If you run into any bumps along the way, go ahead and return a 429 status. Just remember to share some tips on using exponential backoff and jitter to help manage the situation! Take a look at this link for more details: developers.cloudflare.com. It's super helpful!
AuthN/AuthZ We've set up mTLS for our backend service accounts, and for our web and mobile apps, we're rolling with DPoP. When it comes to JSON Web Tokens (JWT), we're all in on RFC 8725. This means we're incorporating JWKS rotation and making sure to use method-specific scopes.
Secrets So, we keep the root keys stored safely in our KMS or HSM for added security. We're using Secrets Manager or Key Vault to handle automatic rotation, and for dynamic secrets tied to things like database or cloud tasks, we turn to Vault. If you want to dive deeper into this topic, check it out here: (aws.amazon.com).
Build/CI We're using GitHub OIDC for our cloud roles, and we’ve set up organization-wide secret scanning along with push protection. Check out all the juicy details right here: (docs.github.com). It's packed with great info!
Observability We're currently tracking 429 counters, organized by both method and key. We've got some monitors in place for SSRF and webhook traffic, and on top of that, we’ve set up secret-access logs that come with alerts. We made sure to follow the OWASP logging guidelines to keep everything above board. If you want more details, take a look at this resource: OWASP Logging Cheat Sheet. It's got a ton of great information for you!

7) Copy‑paste examples you can deploy this week

7.1 Express + Redis: token bucket per API key and per RPC method

// npm i ioredis rate-limiter-flexible express
import express from 'express';
import { RateLimiterRedis } from 'rate-limiter-flexible';
import Redis from 'ioredis';

const redis = new Redis(process.env.REDIS_URL);

const methodBudgets = {
  // tighten heavy calls:
  eth_getLogs: { points: 20, duration: 1 },   // 20 r/s
  debug_traceTransaction: { points: 2, duration: 1 }, // 2 r/s
  default: { points: 100, duration: 1 }       // 100 r/s
};

const limiter = (req, res, next) => {
  const apiKey = req.get('x-api-key') || 'anon';
  const method = req.body?.method || 'default';
  const { points, duration } = methodBudgets[method] || methodBudgets.default;

  const rl = new RateLimiterRedis({
    storeClient: redis,
    keyPrefix: `lim:${method}`,
    points, duration, execEvenly: true, inmemoryBlockOnConsumed: points * 5
  });

  rl.consume(`${apiKey}`)
    .then(() => next())
    .catch(rej => {
      const retrySec = Math.ceil(rej.msBeforeNext / 1000);
      res.set('Retry-After', String(retrySec));
      res.set('Ratelimit', `"${method}";r=${rej.remainingPoints};t=${retrySec}`);
      res.status(429).json({ error: 'Too Many Requests', retry_after: retrySec });
    });
};

const app = express();
app.use(express.json(), limiter);
app.post('/rpc', /* forward to provider */);
app.listen(8080);

Just a quick reminder to keep the header style consistent with what our clients are used to. It's all about that seamless look and feel! If you’re working with Cloudflare or AWS API Gateway, it’s usually a good idea to stick with the features they offer right out of the box. If you want to dive deeper, you can find more info here.

7.2 Backoff with jitter on 429

// exponential backoff with full jitter
async function backoff(fn, {base=200, cap=5000, maxTries=6} = {}) {
  let attempt = 0;
  while (attempt < maxTries) {
    try { return await fn(); }
    catch (e) {
      if (e.status !== 429) throw e;
      const sleep = Math.min(cap, base * 2 ** attempt) * Math.random();
      await new Promise(r => setTimeout(r, sleep));
      attempt++;
    }
  }
  throw new Error('Rate-limited too many times');
}

Whenever you can, make sure to send back a 429 status code along with a Retry-After header. Just keep in mind the recommendations from RFC 6585 while doing so. Feel free to dive into the details right here!

7.3 AWS KMS: enable automatic rotation at a custom cadence

aws kms enable-key-rotation \
  --key-id "$KEY_ARN" \
  --rotation-period-in-days 180

You can handle rotation periods that range from 90 to 2560 days. Plus, it allows you to set up on-demand rotations whenever you need to. And don't worry about keeping track--there's a handy view of your rotation history that makes audits a breeze! Take a look at the AWS documentation for more details!

7.4 GitHub Actions OIDC: no stored cloud keys

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::<ACCOUNT_ID>:role/gh-oidc-deploy
          aws-region: us-east-1
      - run: aws sts get-caller-identity

Short-lived STS credentials are a great way to ditch those annoying static secrets in CI! Hey, take a look at this link: github.com. It’s pretty cool!

7.5 QuickNode: enforce per‑method caps for abuse‑prone calls

curl -X POST "https://api.quicknode.com/v0/endpoints/{id}/method-rate-limits" \
  -H "x-api-key: $QN_API_KEY" \
  -d '{"interval":"minute","methods":["eth_getLogs"],"rate":600}'

Be sure to keep an eye on those hot paths that can seriously drive up costs for providers or throw a wrench in the user experience.
Take a look at this link: quicknode.com. It’s pretty informative!

8) Governance, audits, and drills

How about we spice things up with some exciting quarterly “key flip” game days? The idea is to switch things around by rotating your production RPC key, relayer API key, and KMS CMK alias. Plus, we can keep things in check by running some end-to-end verification and checking out the dashboards. It'll be a great way to keep everything fresh and fun! Here’s the good news: AWS makes it really easy and budget-friendly to get started. You can access it whenever you need, and keeping track of your usage is a breeze! (docs.aws.amazon.com).

Make sure to monitor how secrets are getting leaked, not just in the code itself but in other places too. So, stuff like tickets, containers, and package registries can actually end up leaking live keys. It’s something to keep in mind! Hey, so when you think about secret scanning, picture it more like a perimeter defense rather than just a tool to guard your repositories. It's all about keeping that outer layer secure too! (gitguardian.com).
Keep an eye on how your providers are doing in real time. If you're using services like the Coinbase CDP Node that have usage limits based on BU, it’s a good idea to set up alerts to keep track of your consumption over time. This way, you won’t get any surprises! When using Infura, it’s a good idea to give engineers a little nudge when they reach 75% or 85% of their daily credits. This way, we can help them avoid any unexpected interruptions in their work. (docs.cdp.coinbase.com).

Hey, just a heads up! If you're using third-party automation tools like GitHub Actions or those workflow bots, it’s super important to think about the supply-chain risks that could come along with them. It's a smart move to pin your actions by SHA, keep your tokens scoped, and keep an eye on your artifacts for any sketchy edits in your workflows. Trust me, staying on top of these little things can really save you a headache down the line. Campaigns like GhostAction really highlight how fast thousands of secrets can disappear. It’s pretty eye-opening to see how easily things can get taken! (techradar.com).

9) MPC wallets and threshold signing: what to ask vendors

MPC is a great way to avoid the risk of putting all your eggs in one basket with a single key. However, you really want to dig into how developed the protocol is and see how it manages things like randomness and nonces--kind of like what happened with the BitForge problems in threshold ECDSA. Taking the time to do this homework can save you some headaches down the road! Don’t forget to check in about the DKG randomness! It’s important to know how often it refreshes and to get a feel for how the enclaves and TEEs function. (coindesk.com).

When you're dealing with enterprise relaying, it's super important to ensure that your keys never leave the safe space of your HSM or TEE. And hey, it’s really important that your API secrets can be easily separated and changed out without messing up your signing keys. Keeping things flexible is the way to go! Platforms like Defender and other leading custody solutions typically offer pretty straightforward documentation that outlines how to handle these separations as well as the rate limits you should keep in mind. (docs.openzeppelin.com).

10) Quick checklists for execs

Are we actually setting limits on how many heavy RPC calls each method can handle? Also, can we take a look at the 429 errors and see them categorized by key and method? Hey there! Just wanted to check in on a couple of things. Are all our CI/CD deployments set up to be keyless with OIDC? And do we have that organization-wide push protection and secret scanning activated? You can find more about secret protection here. Thanks! Hey there! Just wanted to check in on a couple of things. Are our service tokens limited by the sender, like using mTLS or DPoP? Also, are we sticking to the JWT guidelines from RFC 8725? You can find those details over at rfc-editor.org if you need a refresher. Thanks! Hey there! So, just to clarify, is the rotation of our KMS/HSM set up to run automatically? And are we keeping track of the cryptoperiods like NIST suggests? Also, do we make sure to test everything out every three months? Just want to double-check all the bases! (csrc.nist.gov). Hey team! Just checking in on whether we’re still keeping our signing systems separate from the app memory. Also, do we have any strategies lined up for handling relayer throughput and balancing the load? Oh, and what about those pesky nonce issues--any plans for un-sticking those? You can find some useful info here: old-docs.openzeppelin.com. Thanks!

Where 7Block Labs can help

Architecture Sprints: We dive into your budgets for each method and see how they stack up against what your providers are capable of. Plus, we’ll make sure to set up rate-limit headers that tick all the boxes for the standards!
Token hardening: We’re putting in mTLS/DPoP, switching up your JWKS regularly, and establishing secure secret flows through Vault/KMS to make sure everything stays super secure.
CI de-secreting: How about we transition your pipelines to OIDC? It’s a great move! Let’s also make sure that push protection is in place for the whole organization. Plus, we should whip up some runbooks for any leaks that tie into your observability initiatives. Sounds good?
Relayer and node performance: We've optimized caching and tackled WSS subscriptions. Plus, we’ve thrown in some nonce circuit breakers to keep things running smoothly. And just to keep everything efficient, we’re balancing the load for relayers based on their throughput targets.

So, when you dive into a new integration or tweak an existing one, you typically wrap things up with a two-week “API Security Fit-Up” session. By the end, you’ve got some solid controls in place, plus handy dashboards, alerts, and even drills to make sure everything runs smoothly!

Sources mentioned

Hey there! If you’re interested in API security, you should definitely check out the OWASP API Security Top 10 (2023). It covers some pretty important stuff like rate abuse and SSRF, plus it gives you some solid tips on steering clear of unsafe API consumption. It’s a great resource to help you stay on top of your game! If you want to dive into all the details, just head over here. It's all laid out for you!

Hey, make sure you check out the latest RFCs: OAuth 2. You won't want to miss it! You've got a bunch of cool standards out there, like mTLS (that’s RFC 8705), DPoP (which is RFC 9449), and JWT best practices (RFC 8725). And don't forget about JWK from RFC 7517, plus those HTTP 429 rules detailed in RFC 6585. Pretty handy stuff if you're diving into security and web protocal essentials! You can take a look at them right here.

If you’re diving into provider quotas and controls, you should definitely check out a few things. First up, take a look at the Coinbase CDP Node. It’s pretty handy! Then there’s the QuickNode method limits, which you won’t want to ignore. Infura’s credit behavior is also something to be aware of. And of course, don’t forget about the quotas for the Google Blockchain Node Engine. Lastly, it’s a good idea to skim through the best practices for WSS/HTTP in the Infura and MetaMask documentation. It could save you some headaches down the line! If you want to dive deeper into the details, you can check out more information here.

When it comes to cloud rate-limit implementations and headers, there’s definitely a lot to think about. Check out what Cloudflare has in store! You might also want to look into AWS API Gateway's token bucket strategy or NGINX's leaky bucket technique. They all have some interesting ways to handle traffic! If you want to dive deeper, just check it out here.

So, let's talk about key rotation and HSM updates for a sec. AWS KMS has rolled out some pretty cool flexible key rotation options, giving you more control. On the other hand, Azure Managed HSM has just hit FIPS 140‑3 Level 3 compliance, which is a big deal! Check out the latest updates right here. There’s always something new happening, so it’s a good idea to stay in the loop!

Keep an eye out for any hidden risks and supply chain problems. Hey, if you get a chance, definitely take a look at the GitGuardian "State of Secrets Sprawl" report for 2024-2025. It’s packed with useful insights! Also, don’t miss the scoop on GitHub Secret Protection and the GhostAction campaign - those topics are super interesting too! Want to dive deeper into this topic? You can check out more details here. Happy reading!
If you want to learn more about Vault dynamic secrets and how cloud secret rotation windows work, feel free to check out all the details here. It's pretty informative!
Finally, if you’re looking for relayer guidance and limits, you should definitely take a look at what OpenZeppelin Defender has to offer. They’ve got some really useful resources that can help you out! Dive in here.

Want a fresh take on your current setup? 7Block Labs has got your back! We can give you a straightforward assessment and whip up a prioritized plan that matches industry standards--all in under two weeks. It’s quick and hassle-free!