Apyx Protocol Security: How We Protect Our Users

At Apyx, the security of the protocol is not treated as a feature. It is a requirement. Every decision about how the protocol is secured, from who can execute a mint to who can upgrade a contract, was made with the assumption that any single point of control would eventually be targeted. Given recent market developments, we want to take a moment to give existing and prospective users clarity on how Apyx’s security architecture is structured, and why it is designed to remain secure even under adversarial conditions.

How Protocol Control Is Structured

Every sensitive function in the Apyx protocol, be it minting, pausing, configuration changes, or contract upgrades, is gated by a single onchain access control contract: the OpenZeppelin AccessManager. This means that nothing happens in the protocol without being explicitly permitted by this contract. There are no implicit permissions, no back doors, and no administrator keys that bypass this system.

The AccessManager is controlled by two distinct multi-signature wallets operating at different privilege levels and different approval thresholds.

The Admin Multi-Sig
The admin multi-sig is the highest level of authority in the protocol, controlling the AccessManager itself and thereby having the ability to assign which addresses hold which roles, set the rules that govern how roles are granted, and configure the time delays that apply to every action taken by the protocol's operators. Currently configured at 4-of-6 signatures, with plans to expand to 5-of-7 as the protocol grows.

Unlike traditional admin keys that execute changes instantly, the admin multi-sig's most sensitive actions are subject to mandatory onchain delays before they take effect. Granting a new operator role, for example, requires a 3-day waiting period before that membership activates. Any change to which role controls a given contract function is similarly delayed. These delays are enforced at the contract level and cannot be bypassed, even by the admin multi-sig itself, without triggering an additional waiting period that is visible onchain.

The Maintainer Multi-Sig
Day-to-day protocol operations are handled by a separate maintainer multi-sig, currently configured at 3-of-6 signatures. The lower threshold enables faster response in operational situations while keeping unilateral action off the table.

The maintainer multi-sig is split into 5 tiers, each with a built-in execution delay that determines how long a scheduled action must sit pending before it can execute:

This tiered structure means the sensitivity of the required approval scales with the potential impact of the action. Pausing a contract in an emergency happens instantly. Upgrading a contract takes seven days, giving token holders, auditors, and the broader community a larger window to observe and respond.

How the Observation Window Works

Every delayed action in the protocol is visible onchain from the moment it is scheduled. Before any pending operation executes, anyone, including external monitoring services, auditors, and the community, can see exactly what is queued, when it will execute, and what it will do.

The goal is that no significant change to the protocol can happen covertly. Every governance action leaves a public, timestamped record.

During this window, any individual signer from the guardian group can cancel the pending operation. Because all 6 signers across both multi-sigs also hold guardian authority, the threshold for cancellation is effectively 1-of-6 signatures, a single on-call team member can veto a suspicious scheduled action without waiting for a quorum.

Minting

Minting is one of the most sensitive control surfaces in any stablecoin protocol. At Apyx, every mint goes through a mandatory two-step process: a mint must be requested and a mandatory delay is enforced to allow team members to review and acknowledge or cancel the mint. Only after an observation period can the mint be executed. There is no single-transaction minting path.

A rolling rate limit caps the total amount of apxUSD that can be minted within any 24-hour window. This limit is enforced by the minting contract and applies regardless of authorization. Its purpose is to bound the potential market impact of any erroneous or unauthorized mint, ensuring that even in a worst-case scenario, exposure is contained to a defined ceiling rather than unconstrained.

Every mint request triggers an automated PagerDuty alert to the on-call team member the moment it is submitted. That alert must be acknowledged or it escalates automatically to the full set of signers. During the 4-hour window, the on-call operator reviews the request to confirm it is expected, correctly sized, and consistent with normal operations. If anything looks wrong, the mint can be cancelled before it executes.

OffChain Alerting: PagerDuty On-Call Coverage

Onchain delays create the window, offchain monitoring is what ensures someone is watching.

Apyx has integrated PagerDuty across the protocol's most critical control surfaces. Every action that goes through either multi-sig or the AccessManager, and every mint, triggers an automated alert to an on-call team member. If the alert is not acknowledged within the configured response window, it automatically escalates to the full set of signers.

For minting specifically, the 4-hour execution delay between a mint request and its execution is paired with a PagerDuty alert that must be acknowledged before the mint completes. This creates a mandatory human review step on every single mint, without exception. The on-call operator confirms the mint is expected, the size is consistent with normal operations, and no anomalies are present. If anything looks wrong, the operation can be cancelled before it executes.

This means the protocol is monitored around the clock, not on a best-effort basis.

Hardware Key Discipline

Every signing key across both multi-sigs is held on a hardware wallet. Signers do not approve transactions on their primary everyday devices. All signing activity takes place on dedicated devices reserved exclusively for that purpose.

This separation matters because it removes a large class of risks that have compromised other protocols, browser-based attacks, malicious software, clipboard hijacking, and social engineering targeting daily-use devices. A signer's everyday computer never touches a protocol transaction.

What This Architecture Protects Against

The layered structure is designed to contain risk at every level.

Compromised Signer Key
A single compromised key cannot execute any consequential action alone. Both multi-sigs require multiple signers. Even if one key is lost, the attacker still needs to meet a multi-sig threshold and wait through onchain delays while the team detects and responds.

Compromised Guardian Key
A compromised guardian key can be used to cancel scheduled actions, but cannot execute actions, move funds, change roles, or escalate its own privileges. An attacker with a single guardian key could repeatedly cancel legitimate protocol operations but could not use that key to extract value from the protocol or harm user funds. In this case the admin multi-sig will revoke the compromised guardian key.

Compromised Maintainer Quorum
If an attacker somehow acquired enough keys to meet the maintainer threshold, the execution delays give the guardian group time to cancel pending operations before they execute. Every delayed action is visible onchain and monitored offchain via PagerDuty.

Malicious Insider
No single team member can unilaterally execute a sensitive action. The combination of multi-sig thresholds, mandatory delays, and 24/7 alert monitoring means any unusual activity creates an observable signal with time to respond.

Accidental or Erroneous Actions
The observation window protects against mistakes too. A misconfigured parameter or an unintended target can be caught and cancelled before it takes effect. Delays are not only a security measure, they are an operational safety net.

Ongoing Commitment to Governance Security

The current configuration is not the endpoint. Apyx plans to increase the admin multi-sig threshold to 5-of-7 signatures as the signer set expands. We have also engaged a third-party auditor to review our multi-sig setup and threat model, treating governance security with the same rigor as smart contract security. Any major future changes to the admin setup will also be audited by a third-party.

As the protocol grows, the governance structure will continue to evolve. The principles behind it will not: no unilateral control, no hidden actions, no single points of failure, no unlimited blast radius.

Summary

Apyx is designed around the assumption that trust in a protocol must be earned and maintained through verifiable controls, not through reputation alone. The architecture described here, tiered multi-sigs, mandatory on-chain delays, 24/7 monitoring, and hardware key discipline, all reflects that commitment.

The team behind Apyx has been in crypto as early as 2013, collectively having spent decades at Kraken. We take security incredibly seriously and understand it is paramount to the success of any DeFi protocol. From Mt. Gox to 10/10, we've lived through it all and have applied all of our learnings to build Apyx for the long term. As any good security architect knows, though, no system is perfect, so we are continuously improving all facets of the Apyx protocol to stay one step ahead of the attackers.