ERC-20, BEP-20, SPL veya Jetton Token Oluşturma Ajansı

Projeniz için hangi token formatı uygun?

Format, ürünün çalışacağı ağa ve cüzdanlar, uygulamalar ve altyapı ile uyumluluğuna göre seçilir. ERC-20, Ethereum'daki token için; BEP-20, BNB Smart Chain'de; SPL, Solana'da; Jetton ise TON'da kullanılır. Ürün zaten bir ağa bağlıysa, belirli bir görev olmadan diğer formatları eklemek yerine genellikle o ağın standardıyla başlamak mantıklıdır.

Başlangıçta tokenın amacını belirlemek faydalıdır: işlevlere erişim, ürün içi ödemeler, protokol mekaniğine katılım veya başka bir senaryo. Ardından arz ve yönetim özellikleri belirlenir. Örneğin, arzın sınırlı olup olmayacağına, ek yönetici haklarına ihtiyaç olup olmadığına ve dağıtımdan sonra hangi işlemlere izin verileceğine önceden karar vermek önemlidir. Bu kararlar mimariyi ve projenin token yapısını kullanıcılara nasıl açıklayacağını etkiler.

İş değerlendirmesinden önce seçilen ağı, kullanım senaryolarını ve gerekli entegrasyonları netleştiriyoruz. Gereksinimler temel tokenın ötesinde özel mantık içeriyorsa, bunu ayrı bir spesifikasyona ayırmak ve akıllı sözleşme geliştirme olarak değerlendirmek daha iyidir. Genel bakış için Web3 geliştirme bölümüne bakabilirsiniz.

ERC-20, SPL veya Jetton dağıtımından önce neyi onaylamalı?

Dağıtımdan önce token parametrelerini ve yönetim yöntemini onaylamak gerekir; bunları yayın sonrası düzeltmek imkansız olabilir veya ayrı bir geçiş gerektirebilir. Sözleşmeyi veya programı hazırlamadan önce proje sahibinin temel kararları onaylaması için kısa bir spesifikasyon oluşturuyoruz.

Spesifikasyon genellikle şunları içerir:

• isim ve kısaltma (ticker) ile formata uygunsa ondalık basamak sayısı;
• arz ve dağıtım modeli: sabit arz veya kurallara göre ek üretim;
• sahip adresleri ve yönetici hakları, görev tanımına göre devir veya feragat dahil;
• gerekli işlevler ve kısıtlamalar, örneğin işlem duraklatma yeteneği;
• ağ, hedef dağıtım adresi, doğrulama materyalleri ve meta veri bilgileri.

SPL ve Jetton için parametreler ve uygulama yapısı EVM uyumlu standartlardan farklıdır; bu yüzden bir uygulamayı ağlar arasında mekanik olarak taşımıyoruz. Ürün arayüzüyle etkileşim için token ayrı bir entegrasyon gerektirebilir; bu, dApp geliştirme ile birlikte kararlaştırılabilir. Spesifikasyon onaylanmadan önce müşteri adresleri, ifadeleri ve yönetim haklarını kontrol eder—böylece dağıtımdan sonra yanlış bir karar bulma riski azalır.

Token oluşturma sürecinde hangi materyaller yer alır?

İş kapsamı başlangıçtan önce belirlenir: hangi dosyaları, eylemleri ve ayarları alacağınızı önceden bilirsiniz. Temel paket, parametrelerin detaylandırılması, seçilen standarda göre uygulama, onaylanan ağda dağıtım ve proje sonucunun teslimini içerir.

Göreve bağlı olarak pakete şunlar dahil edilebilir:

• token uygulamasının kaynak kodu ve yapılandırması;
• onaylanan ağda dağıtım ve oluşturulan token adresi;
• seçilen ağ ve gezgin bu süreci destekliyorsa kodun gezginde doğrulanması;
• meta verilerin hazırlanması veya güncellenmesi: isim, sembol, açıklama ve onaylanan formatta grafik materyal;
• yönetim haklarının devri ve temel parametrelerin kontrolü için talimat.

Yayın öncesinde uygulamanın onaylanan spesifikasyona uygunluğunu ve müşterinin sağladığı adresleri kontrol ediyoruz. Meta veriler ve tasarım, üçüncü taraf kaynaklardaki proje kaydının yerini tutmaz: bunların başvuru ve inceleme için kendi gereksinimleri olabilir. Token bir ürünün parçasıysa, entegrasyon noktalarını ve erişimleri önceden konuşuruz. Kullanıcı arayüzü için Web3 projesi web sitesi veya landing page ve Telegram ürünü için bot veya Mini App gerekebilir. Bu işler yalnızca ayrı onay sonrasında dahil edilir.

Token üzerinde çalışma nasıl ilerler ve lansman ne zaman planlanmalı?

Çalışma, onaylanan spesifikasyondan doğrulanabilir dağıtıma doğru ilerler. Takvim; ağa, işlev kapsamına, veri hazırlığına ve yalnızca token uygulaması mı yoksa ürün entegrasyonu mu dahil olduğuna bağlıdır. Geliştirme başlamadan önce sıralamayı ve kontrol noktalarını onaylarız.

Tipik süreç şöyledir:

1. Tokenın amacını, ağını ve beklenen işlevlerini açıklarsınız.
2. Parametreleri, erişimleri ve sonuç kapsamını netleştirir, spesifikasyonu onaylarız.
3. Uygulamayı hazırlar ve onaylanan süreçte incelemeniz için sunarız.
4. Onay sonrası seçilen ağda dağıtımı gerçekleştirir, adresi ve temel özellikleri kontrol ederiz.
5. Öngörülen meta verileri yapılandırır, uygun olduğunda doğrulama yapar ve materyalleri teslim ederiz.

Lansmanı geciktirmemek için isim ve kısaltmanın yazımını, proje açıklamasını, grafik dosyasını, ağı ve dağıtım için gerekli adresleri önceden hazırlayın. Proje tarafından kararları kimin onaylayacağını ve dağıtım cüzdanını kimin yöneteceğini ayrıca belirleyin. Arayüz veya diğer bileşenler bağlanacaksa, bunları nihai değerlendirmeden önce belirtin: ilgili Web3 geliştirme görevleri birlikte planlanır, ancak kapsam ve süreler ayrıca sabitlenir.

Token çıkarırken hangi kısıtlamaları dikkate almak önemli?

Çıkış öncesinde yalnızca kodu değil, aynı zamanda bazı ağ eylemlerinin geri döndürülemezliğini, yönetim haklarını ve üçüncü taraf gezginlerin kurallarını da dikkate almak gerekir. Spesifikasyonda, bizim işimize dahil olanı ve proje sahibinin kararına veya harici platforma bağlı olanı açıkça ayırıyoruz.

Dağıtım adresi ve ağa yazılan parametreler taslak olarak kabul edilemez: ağda, adreste veya ayarlarda bir hata, yeni bir dağıtım ve ayrı bir geçiş planı gerektirebilir. Bu nedenle müşteri, işlem gönderilmeden önce nihai spesifikasyonu ve cüzdan verilerini onaylar. Token'da yönetim hakları kalıyorsa, sahibi anahtarların güvenli saklanmasını sağlamalı ve her eylemin sonuçlarını anlamalıdır. Hakların devri veya feragati yalnızca onaylanan senaryoya göre yapılır.

Onaylanan uygulama kapsamından ve gerçekleştirilen eylemlerden sorumluyuz, ancak üçüncü taraf bir gezginin doğrulamayı kabul edeceğini, cüzdanın tokenı ek işlem olmadan göstereceğini veya bir dizinin meta verileri onaylayacağını garanti edemeyiz. Bu tür hizmetlerin kararları kendi prosedürlerine, gereksinimlerine ve teknik koşullarına bağlıdır. İş kalitesini kontrol etmek için token adresini ağla doğrulayın, parametreleri onaylanan spesifikasyonla karşılaştırın ve onaylanan kaynak materyallerin erişilebilirliğini kontrol edin. Yürütücüye tohum ifadeyi veya cüzdanın özel anahtarını vermeyin.

TON projeleri için Jetton çıkarımı ve pazarlama nasıl ilişkilendirilir?

TON projeleri için pazarlama, önce Jetton ve ürün hakkında güvenle ve tutarlı bir şekilde yayınlanabilecek onaylanmış bilgiler gerektirir. Token dağıtımı tek başına konumlandırma, kullanıcı senaryosu veya iletişim planı oluşturmaz—bunlar ayrı görevlerdir, ancak çıkarımla paralel hazırlanmalıdır.

Kamu materyallerini hazırlamadan önce tokenın projedeki rolünü, hangi işlevlerin çalıştığını ve hangi iddiaların ürünle doğrulandığını belirleyin. Jetton adını, sembolünü, adresini ve resmi kanal bağlantılarını tüm temas noktalarında kontrol edin. Lansman bir uygulamayla ilgiliyse, token açıklamasından kullanıcı eylemine kısa bir yol hazırlayın: nereye gidileceği, orada ne yapılabileceği ve hangi kısıtlamaların önceden anlaşılması gerektiği.

Planlama için işi üç akışa ayırmak faydalıdır: Jetton teknik hazırlığı, kamu sayfalarının içeriği ve toplulukla iletişim. Her akış için bir sahip ve materyal güncelleme sırası belirleyin; böylece parametre değişiklikleri kanallarda güncel olmayan bilgi bırakmaz. Teknik kısım, Telegram botu veya Mini App ile entegrasyonu ve ürün arayüzü için ayrı bir dApp geliştirme içerebilir. Bu işlerin kapsamını token çıkarımından ayrı olarak kararlaştırırız.

Fiyatlar

Başlangıç fiyatları USD'dir. Özel paketler ve hacim indirimleri talep üzerine. Ödeme: USDT, USDC, BTC, ETH, SOL, TON veya proje tokeniniz ile.

Nasıl çalışır

1. Gereksinimleri topluyoruzAğı, token amacını, gerekli işlevleri ve mevcut materyalleri iletirsiniz. Entegrasyonları ve onay sorumlularını netleştiriyoruz.
2. Spesifikasyonu sabitliyoruzArz parametrelerini, yönetim haklarını ve sonuç kapsamını onaylıyoruz. Temel veriler onaylanmadan dağıtıma başlamıyoruz.
3. Uygulamayı hazırlıyoruzSeçilen standarda göre sözleşmeyi veya programı oluşturuyor ve onaylanan gereksinimlere uygunluğunu kontrol ediyoruz.
4. Token'ı dağıtıyoruzSeçilen ağda dağıtımı gerçekleştiriyor, adresi ve parametreleri doğruluyor, ardından meta veriler ve doğrulama ile ilgili onaylanan işlemleri yapıyoruz.
5. Materyalleri teslim ediyoruzToken adresini ve onaylanan kaynak materyalleri sağlıyor, öngörülen işlevlerin kontrolü ve yönetimi için prosedürü açıklıyoruz.