AER360: Four Products, One Signing Control Plane

Short answer

AER360 is not presented as a new blockchain or token. It is the current product layer built around Aeredium's threshold-signing infrastructure. Its four named pillars are AERKey, the AERKey Wallet, the policy engine, and the Agent Control Center.

The components are designed as one authorization path: a person or agent proposes an action, policy decides whether the exact action is allowed, the enclave cluster verifies that decision before signing, and the outcome is added to a tamper-evident audit chain.

1. AERKey: the signing foundation

Aeredium's current page says AERKey runs the CGGMP24 threshold-signing protocol across three independent machines. Each machine holds a fragment inside a sealed hardware enclave. The company says the complete key is never assembled, including during signing.

The output is an ordinary signature accepted by the destination blockchain. The threshold process is therefore not exposed as an on-chain multisignature transaction. Aeredium also says CGGMP24 can identify a misbehaving participant instead of merely failing without attribution.

These are official architectural claims. The public page does not provide enough deployment data to independently confirm cluster topology, availability, geographic distribution, or production volume.

2. The AERKey Wallet

The AERKey Wallet is described as a custodial wallet, but not one where a provider stores a recoverable complete key. Accounts live on the threshold cluster, no seed phrase is created for the user, and each transaction is approved with biometrics bound to that exact transaction.

This wording matters because it differs from the existing public description of StablePro Wallet as a non-custodial, device-key wallet. No reviewed source says that StablePro was renamed, replaced, or migrated to the AERKey Wallet. They should be treated as separate products until Aeredium documents the relationship.

3. The policy engine

The policy engine evaluates a proposed transaction before any enclave signs it. Published examples include transaction limits, approval quorums, destination allowlists, verified-identity requirements, and biometric confirmation tied to the transaction payload.

Aeredium's central security claim is that policy is not only a web application check. The enclaves require cryptographic proof that the specific request passed policy, making the verdict a condition of producing the signature.

4. The Agent Control Center

AER360 extends the same model to autonomous agents. An owner can create child wallets so that one wallet belongs to one agent and one policy. The official page says each agent wallet uses one of twelve policy templates controlling values such as amount, frequency, and permitted counterparties.

The page does not say whether Agent Control Center replaces AER Police. AER Police previously described agent identity, Pacts, policy gates, audit proof, kill switches, and an Agent Containment Index. Until Aeredium publishes a relationship statement, Agent Control Center should be treated as the current AER360 component and AER Police as a related, separately documented product name.

Every decision is meant to produce evidence

Aeredium says every request, approval, refusal, and signature is written to a tamper-evident audit chain sealed by the threshold cluster. The stated goal is cryptographic evidence that remains verifiable years later, rather than an administrator-controlled application log.

The official page does not expose a public audit explorer, verification specification, sample record, retention policy, or independent audit for this AER360-wide record. AERSeal does, however, publish a separate offline verifier for its threshold-address proof.

How the surrounding products fit

What is established, and what is not?

• Observable: the official AER360 page and platform film are public, and AERSeal exposes a related public service workflow.
• Officially stated: CGGMP24 signing, three enclave-held fragments, transaction-specific policy proof, twelve agent policy templates, and tamper-evident audit records.
• Not established: named customers, institutional production deployment, assets secured, transaction volume, public pricing, wallet download access, external certification, or an independent security audit.

Primary sources

Frequently asked questions