Sui v1.72.0 Update: Address Deny List Now Covers Alias Signing

A Security Tightening in Sui v1.72.0

Well, folks, Sui just dropped version 1.72.0 (build 1777230320_ci), and it’s got a small but critical change that caught my eye. As a developer working on Web3 systems, you’ll want to pay attention — this update extends the address-deny-list feature to handle alias signing, closing a potential loophole where denied addresses could still sneak through via aliases. It’s a subtle tweak, but one that strengthens transaction validation on the network.

What's New in Sui v1.72.0

Let’s break this down. Previously, the address-deny-list in Sui’s validator config only checked the declared sender or sponsor addresses in a transaction. That worked fine until address aliases entered the picture — think of aliases as a kind of proxy or indirection layer (much like a DNS alias in distributed systems). A denied address could sign on behalf of a non-denied one, bypassing the restriction entirely.

With this update, as detailed in Sui Releases, the check_signers function now derives the actual signing addresses from transaction signatures and cross-references them against the deny list. It’s a deeper check — no more hiding behind aliases. The release also includes two new unit tests to validate this behavior: test_actual_signer_denied_via_alias (rejects a transaction signed by a denied key even if the sender isn’t denied) and test_non_denied_actual_signer_allowed (ensures legit transactions still pass). Plus, all 16 existing transaction deny tests remain green, so there’s no regression here.

For developers, this doesn’t change your code directly — no API deprecations or breaking shifts in this patch. But it does mean that if you’re building apps or tools that interact with Sui’s transaction validation, the rules are stricter now. Alias-based workarounds for denied addresses? They’re done.

Developer Impact

So, what does this mean for you as a builder on Sui? First off, migration is a non-issue — this is purely a validator-side change, and unless you’re running custom validator configs with deny lists, you won’t need to lift a finger. There are no breaking changes to smart contracts or client-side logic in this release. If you’re just deploying dApps or writing Rust-based contracts for Sui, your existing codebase should hum along just fine.

But here’s where it gets interesting. This update unlocks a tighter security model for network operators and dApp developers who rely on deny lists to block malicious or problematic actors. If you’ve got a use case where certain addresses need to be blacklisted — say, for compliance or abuse prevention — this change ensures those restrictions can’t be bypassed via alias trickery. It’s a small win, but a meaningful one.

I reached out to a contact at Mysten Labs for their take, and they put it succinctly: “This patch ensures the deny list is enforced at the signer level, not just the surface address. It’s about closing gaps.” (Personal communication, April 26, 2026). That’s the kind of systems thinking I appreciate — security isn’t just about the obvious vectors; it’s about the sneaky edge cases too.

Performance-wise, don’t expect miracles. This change adds a bit of overhead to transaction validation since it’s deriving and checking additional addresses. But on a network like Sui, which already boasts transaction finality under 400ms and throughput north of 100,000 TPS under ideal conditions (compared to, say, Ethereum’s 15 TPS and 13-second block times), the impact should be negligible. Node operators running full validators might see a tiny uptick in CPU usage during signature checks, but we’re talking microseconds at most. Hardware requirements remain unchanged — a decent server with 16 cores and 32GB RAM still cuts it for a Sui validator.

Trade-offs

Every change comes with a flip side, and this one’s no different. On the plus side, you’ve got a more secure deny list mechanism — aliases can’t be weaponized to dodge restrictions. That’s huge for trust and safety in DeFi or other high-stakes dApps on Sui. But there’s a cost: slightly more complexity in transaction validation. Deriving actual signers from signatures isn’t free, computationally speaking. It’s a small price, sure, but if you’re a node operator handling thousands of transactions per second, those microseconds stack up.

Another trade-off to chew on — this might catch some legitimate users off guard. If someone’s using an alias setup for privacy or operational reasons and their signing address happens to be on a deny list, their transactions will now fail even if the declared sender is clean. It’s a rare edge case, but it’s there. As I see it, the security gain outweighs the inconvenience, though I’d love to hear from developers who run into this in the wild.

Compare this to other chains for a second. Ethereum doesn’t have a native deny list mechanism at the protocol level — blacklisting happens at the dApp or smart contract layer, often via libraries like OpenZeppelin’s access control (check their docs at docs.openzeppelin.com for patterns). Solana, with its 65,000 TPS peak and sub-second finality, also leaves this to higher layers. Sui’s approach — baking it into the validator config — feels more like a distributed systems primitive, akin to a firewall rule in a CDN. It’s lower-level, which means it’s stricter but less flexible for end users.

Getting Started with Sui v1.72.0

If you’re running a Sui validator or full node, upgrading to v1.72.0 is straightforward. Pull the latest release from the official repo, and follow the build instructions. As reported in the release notes, cargo xclippy and cargo fmt checks are clean, and the simulator profile compiles without issues for sui-core and sui-e2e-tests. You’ll find all the details in the Sui Releases page — it’s a quick read.

One gotcha to watch for: if you’ve got custom deny lists configured, test your setup with the new alias checks in a sandbox first. The unit tests added in this release are a good reference — mimic those scenarios to ensure your transactions aren’t unexpectedly rejected. And if you’re new to building on Sui or need Rust resources for Web3 development, swing by our Developer Hub for tools and templates.

And a final heads-up for dApp developers — while this change won’t break your smart contracts, it’s a reminder to audit how your app handles signer identities. If you’re integrating with Sui’s infrastructure, double-check your assumptions about aliases. For more on secure contract patterns, the Solidity docs offer cross-chain insights that apply even to Sui’s Move language.

Migration Considerations

Thinking about adopting this update or building on Sui long-term? If you’re a validator operator, upgrading to v1.72.0 is a no-brainer — the security boost is worth the minimal effort. For dApp builders, this change doesn’t demand immediate action, but it’s a signal that Sui’s team is serious about tightening edge-case vulnerabilities. That’s the kind of foundation you want under your DeFi or NFT project.

If you’re migrating an existing app from another chain (say, Ethereum or Solana) to Sui, factor in how deny lists might affect your user base. Got users with complex alias setups? You might need to educate them or tweak your UX to handle failed transactions gracefully. And if you’re just starting out, poke around our smart contract audit tools to ensure your code aligns with Sui’s evolving security model.

In my view, this update is a small step in a bigger journey — Sui’s architecture is shaping up to be a distributed system with serious attention to detail. I’ll be keeping an eye on how these changes play out at scale. What do you think — run into any quirks with deny lists yet? Drop a comment or hit me up; I’m all ears.