GLAM *.+ Mitigating Supply Chain Attacks With Onchain Access Control and Timelocks

Last week (September 8, 2025), researchers reported a major npm supply chain incident that compromised 18 widely used JavaScript packages with an estimated 2.6 billion weekly downloads, silently intercepting crypto activity by swapping destination addresses to attacker wallets. It has been widely described as the largest attack by download volume. For a clear post mortem and practical lessons, see Galaxy Research’s analysis of the breach.

This is not an isolated incident. In 2025 alone, we have also seen:

The eslint-config-prettier compromise
$1.5 billion stolen from the Bybit exchange through a supply chain compromise
A targeted attack on Coinbase expanded to the widespread GitHub Actions incident

Your Wallet Is More Vulnerable Than You Think

Most wallets use an all or nothing model. If the private key is compromised, whether through malware, phishing, or a supply chain attack, the attacker gains full control of the assets. One key becomes a single point of failure.

A successful supply chain attack targeting crypto users could for example involve the following steps:

An attacker injects malicious code into a trusted package or dependency
The malware triggers and intercepts transactions
It silently replaces the destination address with an attacker wallet or injects a malicious payload (e.g., an instruction that transfers funds to the attacker’s wallet)

Routine transactions can also hide authority or permission changes in the same bundle, turning a harmless action into a later drain. For example, a malicious transaction appeared to be standard unstaking operations caused $41.5 million loss of funds to SwissBorg by changing withdrawal authority to an attacker controlled wallet. A policy that restricts authority updates would have prevented this attack.

To users, the entire attack is invisible until the assets are gone. Even experienced users with hardware wallets can be at risk, especially when blind signing is involved. On Solana, blind signing is often required for complex program calls when wallets do not render program-specific fields, which leaves room for invisible parameter abuse.

Clear signing can help surface malicious parameters, but the adoption timeline on Solana is still uncertain, and even when available people get tired, distracted, or rushed, so you still need onchain policies to ensure unauthorized transactions do not execute.

Developers Have Been Targeted

Recent attacks specifically target developers because:

One compromised developer account can publish malicious packages that affect downstream applications, impacting millions of users
A single compromised developer can impact the entire organization as they have access to privileged resources like build pipelines and API keys

Real incidents highlight these risks. Nation-state actors like North Korean TraderTraitor group have used fake job offers, trojanized tools, and cloud compromises to push malicious updates that later hit downstream crypto users.

Even though the community responded quickly to this most recent attack and the financial impact was limited, this will not be the last time developers are targeted. There are a multitude of reasons why developers can be vulnerable to supply chain attacks, as they constantly need to install tools, dependencies and frequently interact with new protocols and smart contracts for testing.

How Onchain Access Control Contains the Damage

Onchain access control replaces all or nothing with fine grained, protocol-enforced policies. Instead of having the funds controlled by a single wallet, permissions are split into discrete units that can be individually granted to delegate wallets.

Onchain access control narrows what any one key can do and makes attacks less effective. A high privilege owner defines and updates the policies, then grants narrowly scoped permissions to delegate wallets (bots, traders, services). If a delegate key is compromised, any transaction outside the allowed instructions and parameters will fail onchain, potentially preventing any loss of funds.

Features and Limitations of Existing Solutions

Onchain access control is not meant to be an alternative to existing wallet solutions. It provides an additional layer of security that helps contain impact if a wallet or private key is compromised. The table below highlights the features and limitations.

Feature / Solution	Traditional Wallets	MPC Wallets	Multi Signature	Onchain Access Control
Private Key Storage	Single key on one device	Split into shares across multiple parties/devices	Each signer has their own full key	Delegates authenticate with keys, but permissions live in onchain program logic
Blockchain Visibility	Standard single signature	Looks like a normal single signature	Multi-sig transactions visible onchain	Normal single signature; fine-grained permissions enforced onchain
Security Model	All-or-nothing; compromise = total loss	Threshold signing; compromise requires multiple shares	Protocol-enforced multi-party approval (e.g., Bybit exploit)	Protocol-enforced role/permission model
Setup & Maintenance	Simple, but risky	Complex cryptography, invisible to users	Relies on protocol implementation and setup of signer set	One-time setup with privileged wallet, then delegate management
Flexibility of Permissions	None	Limited to “M of N” shares	Limited to “M of N” signatures	Flexible, fine-grained (e.g., trade-only, withdraw-only)
Attack Surface	Key theft = total compromise	Attackers need multiple shares	Attackers need multiple keys	Delegate compromise limited to assigned permissions
Enterprise Use	Rare, too risky	Widely used by custodians and large enterprises	Used by DAOs and treasuries	Emerging, suited for protocols and organizations of any size
Limitations	Single point of failure	Complex implementation, dependency on MPC providers, cost of use and maintenance	Unsuitable for automated workflows, additional program attack surface	Requires protocol-level integration, additional program attack surface

A Timelock Helps Mitigate Supply Chain Attacks

A timelock delays changes to take effect for a set time window. Actions are staged first, then can be applied when the window expires. The delay gives time to monitor, alert, and cancel suspicious changes.

When a timelock is enforced, even if the user can still be tricked into signing a malicious transaction, the attack will not cause any damage before the timelock expires. Imagine a scenario where the malicious transaction includes an instruction that updates a treasury’s admin pubkey to the attacker controlled wallet, and the admin somehow signs it, the authority change will not take effect immediately, giving the legitimate admin time to respond.

How GLAM Implements Onchain Access Control and Timelocks

If a private key is compromised, GLAM blocks unauthorized actions with fine grained onchain access control and a timelock, so out-of-policy transactions do not execute.

Onchain Access Control

The protocol enforces three level access control (vault, instruction, and parameter level) using a combination of integration ACLs (access control lists), delegate ACLs, and protocol specific policies. This layered approach separates custody from action: vaults retain asset ownership while delegates receive precisely scoped execution rights.

Vault Level

The vault level access control ensures that specific restrictions and permissions are applied uniformly to the entire vault, regardless of the permissions assigned to wallets interacting with it. For example, integration allowlist and assets allowlist are enforced at the vault level. If the Kamino integration is not enabled, nobody, including the owner, can open or increase borrows on Kamino. This approach strengthens security by providing an overarching control layer for critical vault operations.

Instruction Level

The instruction level access control in the GLAM Protocol is a fine-grained mechanism that enables secure delegation of permissions to other entities (such as a trader, an AI agent, or a bot) within defined boundaries. It ensures that delegates can only perform specific actions permitted by the vault owner, enhancing operational flexibility without compromising security. For example, a hot wallet may be allowed to unstake or repay borrows but not withdraw, enabling automation without risking funds.

Parameter Level

The parameter level access control represents a highly granular mechanism that restricts and defines access not only by instruction but also by specific parameters within those actions. This ensures that even when a delegate is permitted to execute certain instructions, the scope of those instructions is limited to predefined parameters. For example, a trading bot could be given permissions to swap SOL and Liquid Staking Tokens (LSTs), but not an arbitrary meme coin.

Timelocks

The GLAM Protocol supports a configurable timelock on sensitive actions such as policy updates, fee changes, integration settings, and access control modifications. For example, GLAM Tokenized Vaults default to no external transfers; even the manager cannot withdraw.

To enable withdrawals, the manager must explicitly add specific recipient public keys to a transfer allowlist. For an attacker to move funds, they would first need the manager to sign a policy change that adds the attacker address to that allowlist. That change is staged under a timelock and surfaced, giving the manager time to review, cancel, and remediate before it takes effect.

Conclusion

Supply chain attacks have exposed a critical vulnerability: the path to signing is often less secure than the keys themselves. When malware can swap addresses or hidden updates can grant unauthorized access, even the strongest key management is not enough.

Onchain access control changes the game. Instead of just protecting who can sign, you control what any key can actually do. Add a timelock for a review window that turns instant losses into cancellable transactions. This catches attacks without slowing daily operations.

These controls amplify multisig and MPC rather than replacing them. Use multisig or MPC to secure the signing process, then add onchain access control to limit damage from any compromised key, and configure a timelock with alerts and allowlists for complete coverage.

GLAM brings this model to Solana with vault level, instruction level, and parameter level rules plus configurable timelocks. The protocol is under audit and launches on Solana mainnet in Q4 2025. To join the private beta and try onchain vault level access control on real flows reach out or email hello@glam.systems.