> ## Documentation Index > Fetch the complete documentation index at: https://docs.intention.xyz/llms.txt > Use this file to discover all available pages before exploring further. # Layanan program > Layanan yang menurunkan state akun secara off-chain dari riwayat trading yang sudah terkomit, lalu mengomit hasilnya kembali lewat transaksi protokol. Ada hal tentang akun yang perlu diketahui venue tetapi tidak bisa dihitung saat blok dieksekusi. Tier volume bergantung pada trading selama tiga puluh hari. Reward bergantung pada jendela yang belum tertutup. Atribusi referral bergantung pada hubungan yang terbentuk berbulan-bulan lalu. Menaruh pekerjaan itu di dalam eksekusi blok salah dalam dua hal sekaligus: setiap blok harus membayar biaya komputasi yang nyaris tidak dibutuhkan blok mana pun, dan kernel harus menyimpan riwayat yang tidak punya alasan lain untuk disimpan. Layanan program menyelesaikannya dengan membalik arah. Komputasi berjalan **di luar** blok, di atas catatan yang sudah terkomit. *Hasilnya* kemudian dikomit **kembali** ke chain sebagai state protokol, tempat eksekusi bisa membacanya dalam waktu konstan seperti konfigurasi lain mana pun.
Riwayat trading terkomit
Layanan programkomputasi berjendela, di luar blokmembaca tabel biaya langsung dari chain
Berubah sejak diterapkan?
Tidak ditulis
Transaksi protokol
State on-chain
Dibaca saat eksekusiwaktu konstan
Diff terhadap tarif, bukan posisi tierAmbang batas yang bergeser, atau tier yang tarifnya diubah, mengubah apa yang dibayar akun tanpa mengubah indeks tier-nya.
Chain yang menentukan tarif finalPeriode baru dicatat sebagai diterapkan setelah semua batch terkomit; crash me-replay seluruh periode, dan itu aman karena komputasinya idempoten.
Chain tetap menjadi otoritasnya. Layanan tidak memegang state yang menjadi sandaran jaringan — layanan hanya mengusulkan nilai, dan hanya yang diterima chain-lah yang nyata.

Yang berjalan hari ini

**Tier biaya berbasis volume.** Layanan ini mengonsumsi riwayat trading yang di-stream dari node, mengakumulasi volume per akun, dan mengambil snapshot secara terjadwal. Ketika periode ditutup, layanan menghitung volume rolling-window setiap akun, memetakannya melalui konfigurasi biaya yang **dibaca langsung dari chain**, lalu menulis kembali akun yang berubah secara batch. Beberapa detail dalam kalimat itu bersifat menentukan: * **Tabel tier dibaca dari chain, tidak pernah di-hard-code.** Layanan yang memegang salinannya sendiri akan terus menerapkan jadwal kemarin setelah jaringan mengubahnya. * **Diff dilakukan terhadap tarif, bukan terhadap posisi tier.** Membandingkan *indeks* tier melewatkan dua kasus nyata: ambang batas yang bergeser sehingga akun yang tidak berubah jatuh ke tier lain, dan tier yang tarifnya diubah sementara indeksnya tetap sama. Keduanya mengubah apa yang dibayar akun; tidak satu pun mengubah indeksnya. * **Chain yang menentukan tarif final.** Transaksi membawa indeks tier; eksekusi menyelesaikannya terhadap konfigurasi biaya yang sedang berlaku. Indeks tier di luar rentang yang valid menggagalkan seluruh batch, bukan diterapkan sebagian. * **Periode baru dicatat sebagai sudah diterapkan setelah semua batch terkomit.** Crash di tengah periode akan me-replay seluruh periode itu, dan itu aman karena komputasinya idempoten — jendela yang sama menghasilkan hasil yang sama.

Model kegagalan

Layanan ini berada di antara dua sistem yang masing-masing akan sesekali tidak tersedia. Desainnya mengasumsikan hal itu, bukan memperlakukannya sebagai kejadian luar biasa. Kegagalan dependensi — database, stream dari node, API node — dicoba ulang dengan backoff. Kegagalan itu tidak mengakhiri proses, karena restart tidak memperbaiki dependensi yang tak terjangkau; restart hanya menambahkan cold start ke dalam masa gangguan. Yang tetap fatal adalah hal yang *bisa* diperbaiki oleh restart atau yang harus dilihat operator: konfigurasi tidak valid saat startup, gagal mengikat health endpoint, dan panic. Selama gangguan, proses tetap berjalan, melaporkan dirinya not-ready, dan menghitung error. Karena itu sinyal operasionalnya adalah **“sudah berapa menit ini not-ready”** dan bukan **“apakah prosesnya hidup”** — dan itulah pertanyaan yang berguna, sebab proses yang hidup tetapi gagal melakukan ingest selama satu jam justru insiden yang sebenarnya. Shutdown berlangsung graceful pada sinyal yang dikirim orchestrator: pekerjaan berhenti, checkpoint di-flush, dan proses keluar dengan bersih. Tanpa itu, setiap deployment rutin akan menelan biaya satu jendela yang belum di-flush dan satu replay. Periode yang sudah dihitung tetapi belum diterapkan bukanlah periode yang hilang. Karena komputasinya idempoten dan periode yang diterapkan baru dicatat setelah penulisan berhasil, proses yang terputus melanjutkan dengan mengulang jendela itu, bukan melewatinya.

Mengapa polanya bisa digeneralisasi

Jalur write-back bersifat generik. Ada transaksi protokol untuk menetapkan konfigurasi di tingkat akun dan untuk menetapkan konfigurasi global, dan layanan program adalah proses apa pun yang menghitung nilai bagi salah satunya dari riwayat yang sudah terkomit. Tier biaya adalah satu-satunya yang berjalan. Program insentif, atribusi referral, dan kelayakan kampanye akan berbentuk sama: komputasi berjendela di atas riwayat trading, diff terhadap apa yang sedang diterapkan, dan write-back secara batch. Semuanya akan berada di sini, bukan di dalam kernel, dengan alasan yang sama seperti tier biaya — komputasinya periodik dan historis, sementara eksekusi butuh jawaban itu tersedia sebagai lookup waktu konstan. Tidak satu pun dari semua itu sudah dibangun; yang bisa digeneralisasi adalah polanya, bukan komitmen bahwa semuanya akan memakainya. Ketentuan komersial program-program ini ada di [Biaya & Program](/id/programs/fees). Halaman ini membahas bagaimana hasilnya sampai ke on-chain.

Ke mana selanjutnya

Stream yang dikonsumsi layanan ini. Sisi komersialnya: apa saja tier-nya dan berapa biayanya. Bagaimana konfigurasi yang ditulis kembali dibaca saat eksekusi. Mengapa key konfigurasi diberi versi, dan mengapa klien harus me-resolve-nya secara langsung.