Separated authority
Sensitive actions are not intended to depend on a single unrestricted operational wallet. Authorization, scheduling, execution, and participation coordination are separated into distinct control layers.
Security Policy
This page defines ATAMO's security principles, disclosure process, monitoring model, and reviewer expectations. ATAMO treats security as a combination of contract design, administrative structure, public observability, operational discipline, signed releases, and responsible disclosure.
Security Summary
Administrative Control
Structured through 2-of-3 Safe multisignature and Timelock execution
Upgrade Handling
Controlled through delayed approval and observable Timelock execution path
Disclosure Channel
Published through official security contact and PGP references
Monitoring Model
Public on-chain verification, event monitoring, and contract observability
1. Security scope
This security policy applies to the ATAMO protocol, official smart contracts, administrative execution model, participation infrastructure, official documentation, release-verification artifacts, and official project web infrastructure.
Security review should include deployed contracts, contract verification, Safe configuration, Timelock-controlled administrative activity, official documentation, signed Git tags, signed checksum manifests, and public release references.
Included in scope
- official deployed smart contracts
- SecureToken proxy and implementation
- Timelock proxy and implementation
- TokenActionRecorder governance-action recording infrastructure
- ATMSParticipationVault staking, proposal, support, and reward infrastructure
- administrative control architecture
- Safe multisignature authorization model
- Timelock scheduling and execution path
- upgrade approval flow
- signed release artifacts
- official website and official disclosure channels
Outside direct scope
- third-party integrations not controlled by ATAMO
- external services, exchanges, wallets, or analytics platforms
- unofficial mirrors, fake social accounts, or unrelated infrastructure
- user devices, browser extensions, and wallet software not controlled by ATAMO
- third-party token listings that do not match official contract references
2. Security principles
Delayed execution
Critical administrative actions follow a Timelock-controlled delay period before execution, creating a review window for observers.
Public observability
Administrative actions and contract behavior should be verifiable through public blockchain data, verified contract source, official contract references, signed Git tags, and signed release artifacts.
Explicit authority disclosure
ATAMO does not rely on false immutability claims. Where administrative powers exist, they are intended to be disclosed directly.
Bounded contract behavior
Hard restrictions such as supply enforcement should be defined in contract logic rather than only in policy language.
Minimal web complexity
The official website is intended to remain simple and informational, reducing unnecessary attack surface.
3. Protocol security model
ATAMO security is based on a structured administrative model rather than on the claim that no administrative authority exists.
Sensitive protocol actions are intended to pass through:
- Safe multisignature authorization
- governance-action recording where applicable
- Timelock scheduling
- mandatory delay period
- on-chain execution
This model is designed to reduce single-actor control risk and keep sensitive actions visible before completion.
Multisignature control
Sensitive authorization is controlled through the ATAMO Custodian Safe using a 2-of-3 threshold.
Timelock enforcement
Sensitive operations should not execute instantly through the normal administrative path.
Observable activity
Reviewers should be able to monitor governance events, scheduled actions, execution history, vault events, and verification references.
4. Official security-relevant addresses
| Component | Address | Security role |
|---|---|---|
| ATAMO Custodian Safe | 0xe3b72bdb899364ce86949746D31CCba5f384b949 | 2-of-3 multisignature governance root |
| Timelock Proxy | 0x2778BC96422AeD7D7Ac7CE21372Aa42c525A86B8 | Delayed governance execution layer |
| Timelock Implementation | 0xb0d8dc6a08Cb4F93a795c53867ac990C8ce4B0E0 | Current Timelock logic implementation |
| SecureToken Proxy | 0x38604c42c16e29BbFbc5479668453f18cB6cf335 | Canonical ATMS token proxy |
| SecureToken Implementation | 0xD0E06380aF1927c5d929625406d7E9896a80C09c | Current token logic implementation |
| TokenActionRecorder | 0xAA7152784479Ed53147A12514602968327c9965E | Governance-action metadata recorder |
| ATMSParticipationVault | 0x01273Ef57CE09C4Aa615E3bd95eF2b9DD54fd0E4 | Staking, proposal, support, and rewards layer |
5. Upgrade security position
ATAMO uses an upgradeable contract architecture. This means logic changes may remain possible through the defined administrative process.
Upgradeability is treated as controlled authority, not as hidden immutability.
Upgrade security expectations
- upgrade actions should follow the defined approval flow
- upgrade actions should follow Timelock-controlled execution
- upgrade activity should remain observable before completion
- reviewers should validate upgrade controls against verified contract logic
- storage compatibility should be validated before upgrades
- upgradeability should be interpreted as disclosed protocol governance, not as unrestricted invisible control
6. Responsible disclosure policy
ATAMO welcomes responsible private disclosure of potential vulnerabilities. Public disclosure should be avoided until the issue has been reviewed and, where appropriate, addressed.
Disclosure channel
Security reports should be sent to the official security contact.
Email: [email protected]
GitHub Security Advisory: Open private advisory form
Encrypted communication is supported through the official ATAMO PGP public key.
Security.txt: View security contact
PGP Key: View public key
PGP Fingerprint:
7FF6 8D4A 2A54 F8CC 8641 E880 A4C7 575F 79C4 E1AC
Compact fingerprint:
7FF68D4A2A54F8CC8641E880A4C7575F79C4E1AC
Disclosure expectations
- provide a clear description of the issue
- include reproduction steps where possible
- identify affected contract, page, script, or component
- include impact analysis where possible
- allow time for validation and remediation review
- avoid public disclosure before review when the issue could create active risk
7. Security response process
ATAMO attempts to review good-faith security reports and provide follow-up communication when reasonably possible.
Response timing may vary depending on severity, reproducibility, operational impact, and required remediation steps.
No fixed response time or bug bounty payment is guaranteed unless explicitly announced through official channels.
Report categories
- smart contract vulnerabilities
- governance or Timelock execution issues
- upgrade authorization weaknesses
- Participation Vault accounting or proposal-support issues
- TokenActionRecorder governance-recording issues
- website or infrastructure security weaknesses
- official-channel impersonation or suspicious administrative activity
8. Reviewer guidance
How reviewers should validate security claims
Security claims should be evaluated against verified contract source code, deployment addresses, Safe configuration, Timelock configuration, protocol-model documentation, admin-powers documentation, signed Git tags, signed checksum manifests, and public on-chain behavior.
How security should be interpreted
ATAMO security is based on disclosed authority, structured execution, delayed governance, and public verifiability. It should not be interpreted as a claim that no administrative power exists.
9. Monitoring and verification
Administrative activity should be monitored through the public blockchain, official contract references, source-code verification pages, signed Git tags, signed checksum manifests, and protocol documentation.
Reviewers, exchanges, and community members should validate sensitive changes against public on-chain evidence whenever possible.
Administrative activity should be monitored through public blockchain
records, the official contracts page, and the project's verification
references.
10. Release verification
ATAMO v1.0.0 release verification is based on a signed Git tag and a signed SHA256 checksum manifest.
Release directory:
releases/v1.0.0/
Primary release-integrity files:
- deployment-manifest.mainnet.json
- deployment-records-full.mainnet.json
- ATAMO_DEPLOYMENT_STATEMENT_mainnet_2026-05-16.txt
- SHA256SUMS
- SHA256SUMS.asc
- ATAMO_RELEASE_PGP_PUBLIC_KEY.asc
Verification commands:
git tag -v v1.0.0
gpg --verify releases/v1.0.0/SHA256SUMS.asc releases/v1.0.0/SHA256SUMS
sha256sum -c releases/v1.0.0/SHA256SUMS
11. Security transparency principle
ATAMO treats security disclosure and administrative transparency as part of the protocol's trust model. Where authority exists, it should be disclosed. Where claims are made, they should be verifiable. Where risk remains, it should not be hidden behind vague language.