+++ nonce = "330494191513632785" project_nonce = "999" owner = "596642625" language = "en" title = "Coupons as a tool" content_hash = "0ac3e179cbb566bb5ca6fa22f496e37ff731b458465d4260cc09c29c04184226" +++

Coupons as a tool

Coupons on the platform are built around two data types, and the split matters before you issue anything of your own.

Coupon template is the declaration of a promotion: what is given, on what terms, in what volume. Core parameters of a template are locked once created — deliberate commitment. A template by itself gives nothing to anyone; it defines the rules.

Clipped coupon is a user's individual membership in that promotion. The user "clips" the template — a personal replica of the coupon appears for them, and that's what they use. Discounts, accruals, balance spending — all of it happens on the clipped coupon, not on the template.

Today the coupon infrastructure is implemented in one direction — the platform's own. The platform issues templates (support for emerging industries, trusted suppliers, strategic participants), users clip them and apply — for lead-charge discounts or credit accruals. That loop is wired into the platform from the start.

Coupons for project owners' own business processes are a different story. For that to work fairly, without the platform holding user funds in custody, it needs a smart-contract implementation on TON. The path can open natively, or through third-party plugins — the Telegram-bot compatibility layer gives strong potential for third-party integrations here. The potential is clear; the specific implementation path is still developing.