Technical Overview
A detailed technical overview of the Tap Ants Voucher System architecture.
Smart Contract Architecture
The Tap Ants Voucher System consists of three main smart contracts that work together to provide a complete voucher and redemption solution:
TapAntsVoucher
A non-transferable ERC20 token that represents season-based vouchers. This contract prevents transfers between users and ensures vouchers can only be redeemed through approved channels.
VoucherRedeemContract
Handles the redemption process for vouchers. This contract manages the mapping between vouchers and redemption tokens, and provides both admin-controlled and self-service redemption options.
RedemptionToken
A standard ERC20 token that users receive when they redeem their vouchers. This token represents the actual value or reward that users get in exchange for their vouchers.
The contracts are designed to work together in a modular way, allowing for flexibility in implementation and future upgrades. The system uses OpenZeppelin's ERC20 and Ownable implementations as a foundation, with custom modifications to support the voucher use case.
Contract Inheritance Structure
TapAntsVoucher
TapAntsVoucher
├── ERC20 (OpenZeppelin)
└── Ownable (OpenZeppelin)VoucherRedeemContract
VoucherRedeemContract
└── Ownable (OpenZeppelin)RedemptionToken
RedemptionToken
├── ERC20 (OpenZeppelin)
└── Ownable (OpenZeppelin)Key Design Decisions
Non-Transferability
The TapAntsVoucher contract overrides the standard ERC20 transfer functions to prevent transfers between users. This ensures that vouchers can only be redeemed through the approved redemption process.
Season-Based System
Each voucher contract is associated with a specific season ID, allowing for time-limited promotions and structured reward programs. This enables businesses to create different voucher contracts for different seasons or campaigns.
Flexible Redemption
The VoucherRedeemContract supports both admin-controlled and self-service redemption processes. This allows businesses to choose the redemption model that best fits their needs.
Controlled Burning
Only the owner or the redemption contract can burn voucher tokens, ensuring proper redemption tracking and preventing unauthorized redemptions.
Tokenomics
Voucher/Redemption Token Economic Model
The Tap Ants Voucher System implements a dual-token model:
Voucher Tokens (TapAntsVoucher)
- Purpose: Represent vouchers or credits that can be redeemed for actual value.
- Distribution: Minted by the contract owner and distributed to users as rewards, incentives, or through purchases.
- Transferability: Non-transferable, ensuring they can only be used by the intended recipient.
- Lifecycle: Created → Distributed → Redeemed (burned) → Value received.
Redemption Tokens (RedemptionToken)
- Purpose: Represent the actual value or reward that users receive when redeeming vouchers.
- Distribution: Minted during the redemption process based on the conversion rate.
- Transferability: Fully transferable, allowing users to trade or use them as they wish.
- Utility: Can be used within the ecosystem for purchases, access, or other benefits.
Season-Based Voucher System
The season-based voucher system allows businesses to create different voucher contracts for different time periods or campaigns:
- Season ID: Each voucher contract has an immutable season ID that identifies the specific season or campaign.
- Time-Limited Promotions: Businesses can create vouchers that are only valid during specific seasons or time periods.
- Structured Rewards: Different seasons can have different redemption rules, conversion rates, or eligible rewards.
- Transition Management: When a season ends, businesses can deploy a new voucher contract for the next season while maintaining the same redemption infrastructure.
Non-Transferability Mechanisms
The non-transferability of vouchers is enforced through several mechanisms:
- Overridden Transfer Functions: The standard ERC20 transfer and transferFrom functions are overridden to always revert with an error message.
- Restricted Approvals: The approve function is modified to only allow approvals to the redemption contract or the voucher contract itself.
- Controlled Burning: Only the owner or the redemption contract can burn vouchers, ensuring they can only be redeemed through approved channels.
These mechanisms ensure that vouchers can only be used by the intended recipient and cannot be transferred to other users, which is essential for many voucher use cases such as loyalty programs, event tickets, and promotional offers.
Security Considerations
Access Control
The contracts use OpenZeppelin's Ownable pattern for access control. Ensure that the owner address is secure and consider implementing a multi-signature wallet or DAO for critical operations.
Redemption Contract
The redemption contract has the ability to burn vouchers. Ensure that this contract is properly audited and secured to prevent unauthorized redemptions.
Emergency Procedures
Implement emergency procedures such as pausing functionality or emergency withdrawals in case of security incidents.