Skip to main content
Security is an important part of Elysium Names because the protocol manages name ownership, registration payments, renewals, referrals, auctions and other onchain operations. The smart contracts are developed with a focus on permission control, payment accounting, predictable ownership behaviour and protection against common contract vulnerabilities. This page outlines the protocol’s security measures and testing approach.

​
1. Security Approach

Elysium Names uses several mechanisms to reduce risks across its contracts. These include:
  • Access control for administrative and restricted operations.
  • Two-step ownership transfers through OpenZeppelin’s Ownable2Step.
  • Reentrancy protection on applicable payment functions.
  • Commit-reveal registration to protect registration commitments.
  • Explicit checks for registration and renewal conditions.
  • Separate accounting for referral rewards and protocol payments.
  • Duplicate-claim protection in supported partner programmes.
  • Automated tests covering core contract behaviour and edge cases.
These measures are designed to make protocol operations more predictable and reduce the likelihood of unauthorised or invalid state changes.

​
2. Smart Contract Safeguards

​
Access control

Restricted administrative functions are protected so that only the appropriate authorised account can execute them. The controller and auction contracts also require the necessary permissions to perform their designated operations through the core name contract.

​
Two-step ownership transfer

The protocol uses OpenZeppelin’s Ownable2Step ownership model. A nominated owner must explicitly accept ownership before the transfer is completed. This reduces the risk of accidentally transferring administrative control to an incorrect address.

​
Reentrancy protection

Applicable payment functions use reentrancy protection to reduce the risk of malicious external calls re-entering sensitive operations before execution is complete.

​
Commit-reveal registration

Name registration uses a commit-reveal process. A commitment must be at least 15 seconds old and no more than 24 hours old when registration is submitted. The commitment is also bound to the intended receiving owner. This helps protect registration requests from certain forms of front-running and prevents a commitment from being reused for a different receiving wallet.

​
Referral accounting

Referral rewards are tracked separately from treasury funds. This separation helps prevent referral liabilities from being treated as ordinary withdrawable protocol revenue.

​
Partner claim protection

Supported partner programmes include duplicate-claim protection. Once a wallet has successfully claimed a configured benefit, the contract prevents the same wallet from claiming that benefit again under the same programme.

​
3. Automated Testing

Elysium Names uses Foundry for smart contract development and automated testing. The test suite covers protocol functionality and important edge cases, including:
  • Name registration and pricing.
  • Commit-reveal validation.
  • Name ownership and transfers.
  • Address and text records.
  • Manager permissions.
  • Primary-name functionality.
  • Renewals and expiry.
  • Grace-period and expired-name premium behaviour.
  • Referral discounts and reward accounting.
  • Partner eligibility and duplicate claims.
  • Reserved-name registration.
  • Auction bidding, refunds and settlement.
  • Payment accounting and access control.
The project has 155 passing automated Foundry tests, including fuzz tests covering accounting-related behaviour. Passing tests provide evidence that the tested scenarios behave as expected. They do not establish that the contracts are free from vulnerabilities.

​
4. Fuzz Testing

Fuzz testing is used to evaluate contract behaviour across a range of generated inputs rather than relying only on manually selected examples. This is particularly useful for operations involving:
  • Payment calculations.
  • Registration pricing.
  • Referral accounting.
  • Bid validation.
  • Refunds.
  • Contract state transitions.
Fuzz tests can help identify unexpected behaviour that may not appear in ordinary test cases. However, fuzz testing is limited by the properties, inputs and scenarios included in the test suite.

​
5. External Security Review

Automated testing and internal code review are not substitutes for an independent security assessment. The protocol’s security status should be described accurately:
  • Automated Foundry testing has been completed for the documented test suite.
  • Reentrancy protection and access-control safeguards are implemented where applicable.
  • An independent security audit should not be assumed complete unless a final audit report has been published.
Users and integrators should review the latest official security disclosures before relying on the protocol in production.

​
6. Responsible Integration

Applications interacting with Elysium Names should also follow good security practices. Developers should:
  • Use verified contract addresses and the correct network.
  • Validate name-resolution results before initiating transactions.
  • Check name expiry where relevant.
  • Distinguish NFT ownership from the resolved wallet address.
  • Use the correct ABI for the deployed contract version.
  • Handle failed transactions and contract reverts safely.
  • Avoid assuming that a successful frontend response means an onchain transaction has completed.
  • Verify royalty and payment configuration against deployed contract state.
Wallets should display the resolved recipient address before allowing users to confirm a transaction.

​
7. Security Reporting

If a developer or user identifies a potential vulnerability, they should avoid exploiting it or publicly sharing sensitive technical details before the issue has been assessed. Security concerns should be reported through the project’s official communication channels so they can be reviewed responsibly. Project resources:

​
8. Summary

Elysium Names combines access controls, commit-reveal registration, payment safeguards and automated testing to protect important protocol operations. Its test suite includes 155 passing Foundry tests, including fuzz testing around accounting behaviour. These measures form part of the protocol’s security approach, but they should not be interpreted as a guarantee of vulnerability-free code or as proof of an independent security audit.