Polkadot

Ang Polkadot ay isang multi-chain network protocol na nag-uugnay ng maraming espesyalisadong blockchain (“parachains”) sa isang sentral na Relay Chain. Ang Relay Chain ang nagbibigay ng shared security, consensus, at cross-chain interoperability, habang ang mga parachain ay sabay-sabay na tumatakbo at nakikipagkomunikasyon gamit ang cross-consensus messaging (XCM) ng Polkadot. Ang disenyo nito ay nakatuon sa scalability at composability ng mga chain sa loob ng iisang network.

Sa arkitektura ng Polkadot, ang mga parachain ay application-specific chains kung saan ang mga block ay ginagawa ng mga collator at sinusuri ng mga validator ng Relay Chain. Sa pamamagitan ng pagkakabit sa Relay Chain, namamana ng parachain ang economic security ng validator set at maaaring magpalitan ng mensahe sa ibang chains gamit ang XCM. Maaari ring magdugtong ang mga bridge ng Polkadot sa mga panlabas na network—halimbawa, sa Ethereum sa pamamagitan ng Snowbridge; ang koneksyon sa Bitcoin ay ibinibigay sa pamamagitan ng parachains tulad ng Interlay sa halip na isang native na light-client bridge. Para sa mas detalyadong operasyon ng cross-chain messaging, tingnan ang dedikadong XCM section.

Ang DOT ang native token ng network sa Relay Chain. Sa spesipikasyon ng Polkadot, ito ang pundasyon ng tatlong pangunahing tungkulin: pamamahala ng protocol (governance), staking para sa seguridad ng network, at bonding (mekanismong historikal na gamit para magdagdag ng chains).

Ang resource model ng Polkadot ay umuunlad na may “Polkadot 2.0”. Sa halip na lease ng pangmatagalang slot, nakakakuha ang mga proyekto ng access sa compute ng Relay Chain gamit ang coretime (oras sa virtual cores). Ang coretime ay ina-allocate sa system chains sa pamamagitan ng governance at kinukuha ng ibang chain sa open market.

Ang DOT ang native token ng Polkadot Relay Chain. Pinangangalagaan nito ang pangunahing functionalities ng network:

Seguridad ng network sa pamamagitan ng staking (NPoS): Maaaring mag-nominate ng validator o magpatakbo ng validator ang mga DOT holder upang tumulong mag-finalize ng mga block at panatilihing tapat ang sistema. Ang naka-stake na DOT ang sumusuporta sa asal ng validator at tumatanggap ng staking rewards; ang maling asal ay maaaring patawan ng parusa (slashing). Tingnan: Nominated Proof-of-Stake at Slashing para sa mga mekanismo at panganib.

On-chain governance (OpenGov): Ginagamit ang DOT para mag-propose at bumoto sa referenda sa iba't ibang “track”, mag-delegate ng voting power, at lumahok sa protocol upgrades at desisyon sa system-chain. Tingnan: OpenGov at Paano makakalahok ang mga user sa governance… para sa detalye ng tracks, deposit, at delegation.

Network fees at kinakailangang deposit: Ang mga transaksyon sa Relay Chain ay nagpapabayad ng fees na DOT ang pambayad, at ang bawat account ay kailangang panatilihin ang minimum balance (existential deposit) upang manatiling aktibo. Ang ilang on-chain actions ay nangangailangan rin ng refundable na DOT deposit (hal., identity). Tingnan: Ano ang mga on-chain utilities ng DOT… para sa mga uri ng fee at deposit.

Pagkuha ng Relay Chain compute (“coretime”) sa Polkadot 2.0: Nakakabili ang mga proyekto ng execution time sa Relay Chain cores gamit ang DOT bilang pambayad; ang DOT na ito ay sinusunog. Ang modelong ito ang pumalit sa long-term slot leases/crowdloans. Tingnan: Ano ang nagbago sa Polkadot 2.0… at Paano maglunsad ng chain… para sa ekonomiya at mga paraan ng deployment.

Pagpopondo ng sistema sa pamamagitan ng on-chain Treasury: DOT ang denominasyon ng Treasury inflows (bahagi ng block rewards, fees, tips, slashes) at ito ay ginagastos—sa pamamagitan ng governance—sa mga aprobadong proposal. Tingnan: Paano gumagana ang on-chain Treasury… para sa proseso at scope.

Paggalaw sa iba’t ibang chain at paggamit sa ekosistema: Maaaring i-teleport ang DOT sa pagitan ng Relay Chain at system parachains tulad ng Asset Hub gamit ang XCM; ang cross-chain transfers ay maaaring may fee pareho sa pinagmulan at destinasyong chain. Tumatanggap nang direkta ang ilang parachain/app ng DOT; ang iba ay nangangailangan ng bridged/wrapped na representasyon. Tingnan: Asset Hub at Paano nagi-interoperate ang DOT… para sa specifics at babala.

Kung hinahanap mo ang eksaktong fee model, minimum, deposit at staking flows, magpatuloy sa “Ano ang mga on-chain utilities ng DOT (staking, fees, governance at deposits)?”

Gumagamit ang DOT ng fixed na taunang issuance na nagsimula sa ~8% ng supply sa umpisa at ngayon ay naging constant na ~120 milyong DOT kada taon, at dahil dito ang percentage ng inflation ay pababa habang lumalaki ang total supply. Sa bawat taon, 15% ng issuance ay direktang minamint sa Treasury at 85% ay napupunta sa staking rewards (binabayaran kada era). Ang mga parameters na ito ay ipinatupad sa pamamagitan ng OpenGov (Referendum #1139) at isinama sa runtime code.

Emissions cadence at distribution: Ang bagong DOT ay tuloy-tuloy na nililikha at kinakalkula sa katapusan ng bawat era (~24 oras sa Polkadot), at pagkatapos ay inihahati sa validators at nominators ayon sa staking reward mechanism; ang 15% share ng Treasury ay minamint sa system account nito. Sa fixed-issuance model, hindi na ina-adjust ang hati ayon sa staking participation ng network, na nagpapasimple sa rewards kumpara noon.

Burns na pumapantay sa gross issuance: Dalawang bagay ang nagpapababa ng net supply growth: ang pagbili ng coretime (sa Polkadot 2.0) ay sinusunog, at puwede ring sunugin ng Treasury ang pondo sa pamamagitan ng governance. Kaya ang tunay na taunang inflation ay fixed issuance (~120M DOT) bawas ang nasunog sa kasalukuyang taon.

Pagkakaiba mula sa dating modelo: Bago ang 2024 na pagbabago, pinuntirya ng Polkadot ang ~10% annual inflation, na may rewards na naa-adjust base sa “ideal” staking rate at anumang kakulangan ay napupunta sa Treasury (“staking inefficiency”). Sa bagong modelo, tinanggal na ang adjustment na iyon at napalitan ng fixed 15% Treasury share gaya ng nabanggit sa itaas.

Walang hard cap (subject sa governance): Walang maximum supply na built-in sa protocol ang DOT. Maaaring baguhin ang issuance parameters sa pamamagitan ng on-chain governance; ang mga update ng 2024–2025 ay ipinasa sa prosesong iyon. Para sa kasalukuyang settings at aktibong mga pagbabago, tingnan ang mga kaugnay na OpenGov referenda.

2020 redenomination (pagbabago ng unit lang): Noong 21 Agosto 2020 (“Denomination Day,” block #1,248,328), ni-renominate ang DOT sa 1 old DOT = 100 new DOT. Ito ay pagbabago lang ng unit, hindi ng value o pag-aari: ang balances at presyo ay na-scale ng 100×, at ang base unit (Planck) bawat DOT ay mula 10¹² naging 10¹⁰ Planck. Ang economics ng network ay di nagbago.

Staking (pagpapaseguro sa network): Ang DOT ay maaaring i-bond para sa seguridad ng network sa ilalim ng Nominated Proof-of-Stake (NPoS). Maaaring mag-nominate ng validator o magpatakbo ng sarili ang mga holder; binabayaran ng rewards kada era, at ang maling asal ay maaaring magresulta sa slashing. Ang validator set ng Polkadot ay inihahalal gamit ang Phragmén-based algorithms, at maaari ring sumali ang user sa nomination pools kung nais ng mas simple at maliit na halaga. Ang mga mekanismong tulad ng unbonding times, slashing conditions at detalye ng halalan ay tinatalakay sa NPoS at Slashing sections.

Fees (pagbabayad para sa transaksyon): Sa Relay Chain, ang mga transaksyon ay binabayaran ng mga fees sa DOT na kukunin mula sa transferable balance (hindi mula sa bonded funds). Binubuo ng base fee, length fee, weight-based fee at optional tip ang fees; puwedeng mag-iba ang fees depende sa kasikipan ng block. Ipinapakita ng wallets ang estimated fee bago ka pumirma.

Maaaring may fees sa parehong pinagmulan at destinasyong chain ang mga cross-chain actions. Halimbawa, ang pag-teleport ng DOT mula Relay Chain papuntang Asset Hub ay may destination fee at walang “keep-alive” safeguard, kaya dapat manatiling lampas sa minimum balance ng destinasyon ang account upang maiwasan ang reaping.

Governance (OpenGov): Ginagamit ang DOT para mag-propose at bumoto sa referenda ng OpenGov. Kailangan ng decision deposit ang proposals; ang voting ay gumagamit ng conviction-weighted balances (naka-timelock ang tokens para sa dagdag na voting power). Maaari ring mag-delegate ng voting power ang user, kasama ang per-track delegation. Saklaw sa OpenGov sections ang operatibong pamamalakad (voting, delegation, lock management).

Deposits at minimum balance: Pina-patupad ng Polkadot ang existential deposit (ED)—isang minimum na libreng balanse upang manatiling buhay ang account. Kung mas mababa sa ED, maaari itong ma-reap at ang natitirang dust ay masusunog. Sa kasalukuyan, 1 DOT ang ED sa Relay Chain at 0.01 DOT sa Polkadot Asset Hub (depende sa chain at subject sa pagbabago). May keep-alive checks para maiwasan ang aksidenteng reaping; hindi ito naipatupad sa teleports.

Ang ilang feature ay nangangailangan ng reserved deposits (bonds) na hawak habang aktibo ang feature at karaniwang ibinabalik kapag inalis na ito. Halimbawa: on-chain identity na pinamamahalaan sa People parachain ay nangangailangan ng refundable deposit at registrar fee; ang pagtanggal ng identity ay nagbabalik ng deposit (nananatili ang pondo sa People hanggang ma-teleport pabalik). Ang governance-related deposits (hal., decision deposits) ay saklaw sa Governance section.

Ang Relay Chain ay ang sentral na chain ng Polkadot. Nagbibigay ito ng network-wide na security at global consensus, at sinadyang minimal ang application logic: ginawa upang mag-host at mag-kordina ng maraming parallel chains kaysa mag-run ng end-user features mismo. Tinitiyak ng Relay Chain ang isang globally consistent na view ng state sa lahat ng nakakabit na shards (“parachains”).

Ang Parachains ay mga application-specific chains na sabay-sabay na tumatakbo at nakakabit sa Relay Chain. May sariling state at logic ang mga ito ngunit minamana ang security mula sa validator set ng Relay Chain. Ang mga collator ng parachain ang taga-ipon ng transaksyon at gumagawa ng candidate blocks na may proofs; ang mga validator naman ng Relay Chain ang sumusuri ng availability at validity bago tanggapin ang mga state transition ng parachain sa shared state. Nagbibigay ito ng specialization sa parachains habang ang consensus, finality at coordination ay hawak ng Relay Chain.

Maaaring mag-komunikasyon ang mga parachain gamit ang cross-consensus messaging (XCM) ng Polkadot, habang ang Relay Chain ang nangunguna sa routing/verification layer upang siguruhing ligtas ang pagpapalitan ng data at asset. Ang malalim na mekanismo ng XCM ay nasa XCM section.

Kasama rin sa Polkadot ang system parachains (system chains) para sa mga core protocol function—hal., Asset Hub para sa fungible at non-fungible assets—na inilalayo ang functionality sa Relay Chain pero gumagamit pa rin ng shared security. Ang mga system chains ay ina-allocate ng on-chain governance.

Sa Polkadot 2.0, nakakakuha ng compute ang mga proyekto mula sa Relay Chain gamit ang cores (“coretime”). Tumanggap ng mga core ang mga system chains sa pamamagitan ng governance, habang ibang chains ay bumibili ng coretime sa open market; ngunit nananatili ang pangunahing ugnayan: ang bawat parachain ay nagpapatakbo ng sariling logic, at Relay Chain ang nagva-validate at nagfi-finalize ng kanilang state transitions.

Ang XCM (Cross-Consensus Messaging) ay ang wika ng Polkadot para magpadala ng intent-based na mensahe sa pagitan ng consensus systems (Relay Chain, parachains, at—sa pamamagitan ng bridge—ibang networks). Tinutukoy nito ang dapat mangyari, hiwalay sa anumang specific runtime pallets. Ang XCMP (Cross-Chain Message Passing) ang transport protocol para sa parachain↔parachain messages; ang relay↔parachain traffic ay gumagamit ng UMP (upward) at DMP (downward). Asynchronous ang mensahe.

Transfers: dalawang native na XCM pattern

• Teleport: dumadaan ang supply direkta sa pagitan ng trusted locations nang walang reserve keeper. Karaniwang gamit: DOT sa pagitan ng Relay Chain at Polkadot Asset Hub. Nangangailangan ng mutual trust configuration sa parehong chain ang teleports.
• Reserve-based transfer: ang asset’s reserve chain ang nagtatala ng total supply; ang pinagmulan ay nagla-lock/burn ng representasyon, ina-adjust ng reserve ang balanse, at ang destinasyon ay nag-mimint/credit ng representasyon. Karaniwang pattern ito sa paglipat ng asset sa parachains na hindi ang reserve.

Sa praktika, maraming team ang mas gusto ang reserve transfers para sa kaligtasan at accounting clarity; ang teleports ay enabled lamang para sa mahigpit na trusted na ruta (para sa DOT: Relay Chain ↔ Asset Hub).

Channels at routing: Ang parachain↔parachain messages ay dumadaan sa channels. Sa kasalukuyan, karamihan ng network ay gumagamit ng HRMP (Horizontal Relay-routed Message Passing) na may parehong interface gaya ng XCMP ngunit nagtatago ng mensahe sa Relay Chain; mas mahusay ang XCMP bilang end-state. Ang HRMP channels ay unidirectional; para sa two-way na koneksyon, kailangan ng channel sa bawat direksyon at dapat buksan/katigan ng parehong chain.

Fees, weight at execution: Kailangang “bumili ng execution” ng isang XCM sa destination chain (magbayad para sa weight/compute). Ang mga asset na tinatanggap at gaano karami ang kinakailangang weight ay polisiya ng destination chain. Kabilang sa karaniwang extrinsics ang teleport_assets at reserve_transfer_assets, na nagtatakda ng destinasyon, beneficiary, assets at fee item.

User-level behaviour at safeguards:

• Existential deposits & keep-alive: walang “keep-alive” check sa teleports. Siguruhing ang post-fee balance mo sa destinasyon ay lampas pa rin sa existential deposit nito kundi maaari ma-reap ang account. May destination-chain fee rin ang teleports.
• Asynchrony & ordering: hindi instant ang delivery; ordering ay guaranteed lang sa loob ng channel.

Para sa bridges sa mga panlabas na network at wrapped DOT, tingnan ang interoperability section sa dulo.

Ang Asset Hub ay system parachain ng Polkadot (dati “Statemint”) para sa pag-issue, paghawak at paglipat ng asset, kabilang ang fungible tokens at NFTs. Disenyo itong common-good chain na may mas mababang fees at existential deposit (ED) kaysa Relay Chain, at nagagamit ang DOT bilang native token para sa fees at deposits. Sa Polkadot Asset Hub, 0.01 DOT (sampung beses mas maliit kaysa Relay Chain) ang existential deposit, at maaaring gawing sufficient (walang kailangan DOT para hawakan) o non-sufficient (kailangan abutin ang DOT ED) ang assets.

Sa operasyon, ang Asset Hub ay venue para gumawa ng asset, mag-manage ng metadata at maglipat; opisyal na guidance ay nilalahad din ito bilang ideal na venue sa pagtrato sa non-native tokens at NFTs. (Sa Kusama Asset Hub ay enabled ang smart-contract execution; sa Polkadot, native EVM/PVM smart contracts ay ilalagay sa Polkadot Hub system chain, hindi sa Asset Hub.)

Kailan mainam mag-teleport ng DOT?

Ang teleport ay trusted XCM route na nakaset sa pagitan ng Relay Chain ↔ Asset Hub para sa DOT. Mainam ito kung kailangan mo talaga ng DOT sa Asset Hub, halimbawa upang:

• Magbayad ng mas mababang fees o abutin ang 0.01 DOT na existential deposit para makapag-hold ng non-sufficient assets, o
• Magamit ang features at applications na tumatakbo mismo sa Asset Hub.

Mga pangunahing behaviour bago mag-teleport:

• Ang destination-chain fee ay ibinabawas mula sa teleported amount; dapat ay ≥ existential deposit pa rin ang natira o mawawala ang pondo.
• Walang “keep-alive” na enforcement ang teleports kaya dapat tiyakin na lampas pa sa existential deposit ang post-fee balances sa magkabilang dulo kung nais manatiling buhay ang account.
• Huwag mag-teleport direkta sa deposit address ng exchange (karamihan ng exchange ay hindi kilala ang teleports).

Para sa mechanics ng teleports vs reserve-based transfers at malawakang cross-chain routing, tingnan ang XCM/XCMP section. Kung may planong Asset Hub migration o maintenance, maaaring pansamantalang hindi available ang teleports at XCM transfers; tingnan ang kasalukuyang Support notices para sa status.

Layunin at tungkulin: Independent na network na may hiwalay na token (DOT, KSM) at magkaparehong code ang Polkadot at Kusama. Canary network ang Kusama: live, totoong economic environment kung saan unang nailulunsad ang bagong features at mabilis ang galaw; stability at reliability naman ang priyoridad ng Polkadot para sa production deployments.

Governance cadence: Parehong gumagamit ng OpenGov ngunit mas maiksi ang timelines ng Kusama (depende sa track) mula decision hanggang enactment, kaya’t mas mabilis ang upgrades; mas konserbatibo ang Polkadot. Ang parameters ay kada track at maaaring magbago sa governance.

Staking timing: Ang unbonding period ay ~28 araw sa Polkadot at ~7 araw sa Kusama. Ang mga era—gamit para sa validator payouts—ay ~24 oras sa Polkadot at ~6 oras sa Kusama. Naaapektuhan nito ang reward cadence at haba ng pagkaka-lock ng pondo pagkatapos mag-unbond.

Minimum account balance (existential deposit): Sa Polkadot ay 1 DOT, sa Kusama ay 0.000333333 KSM (maaaring magbago ng governance). Mas mababa pa ang ED sa Asset Hub parachains.

Upgrade path: Major protocol changes and features ay sinusubukan muna sa Kusama sa totoong kondisyon; pag napatunayan, nilalagay sa Polkadot. Pinapanatili nito ang agility ng Kusama at konserbatibo ang Polkadot para sa long-term operation.

Parehong may arkitekturang model (Relay Chain + parachains) at OpenGov tooling ang dalawang network; ang mga pagkakaiba sa itaas ay sumasalamin sa layunin (bilis vs stability) at operational na parameters (timing, minimums) at hindi sa pundamental na disenyo.

Ang NPoS ay staking model ng Polkadot na may dalawang role: ang mga validator ay nagpapatakbo ng node na gumagawa at nagva-validate ng mga block; ang mga nominator ay sumusuporta sa napiling validator gamit ang kanilang DOT. Pareho silang nakakatanggap ng rewards at parehong may risk ng penalty kung magkamali ang validator na sinuportahan. Pinipili bawat era ang validator set at ina-assign dito ang nominator stake.

Election cycle at timing: Sa Polkadot, ang isang era ay ~24 oras. Ang susunod na validator set ay kinokompyut sa huling bahagi ng kasalukuyang era at naipapatupad pagdating ng susunod; rewards ay kinakalkula kada era.

Paano sumasali ang nominator: Maaaring suportahan ng isang nominator ang hanggang 16 validator. Maaring iallocate ng algorithm ang stake ng nominator sa subset lang ng mga ito, upang balansehin ang set; hindi lahat ng inonominate ay tatanggap ng backing.

Paano inihahalal ang validators (objective at algorithm): Tatlong goal ang inoo-optimize ng validator elections: (1) mapalaki ang total stake na gumagarantiya sa set, (2) mapalaki ang pinakamababang stake ng lahat ng elected validator, at (3) mapaliit ang stake variance sa buong set. Off-chain kinokompyut ang solusyon at hinahain on-chain sa Election Provider (multi-phase). Ang network ay gumagamit ng proportional committee-election rules mula sa Phragmén research at nasosolve off-chain via multi-phase Election Provider.

Stake assignment at payouts (overview): Kapag napili na ang panalo, tinutukoy ng election solution kung paano hahatiin ang nominator stake sa napiling validator. Binabayaran ang validator kada era base sa activity, at nominators ay binabayaran depende sa kanilang backing na validator(s). Detalye ng rewards ay sakop ng staking specifics.

Panagutan: Dahil ang nominator ay aktibong sumusuporta, maaari silang ma-slash kung nakagawa ng fault ang validator na kanilang tinulungan mapabilang sa active set. Para sa kondisyon at porsyento, tingnan ang dedikadong Slashing section.

Para sa unbonding times, pools at reward mechanics, tingnan ang staking sections; ang entry na ito ay nakatuon lamang sa election model at validator selection.

Ang slashing ay on-chain penalty na pinapataw kapag nilabag ng validator ang consensus rules. Binabawasan ang porsyento ng stake sa validator slot na iyon (self-bond + anumang nominator stake). Depende ang laki sa offense; ang nasunog na fund ay napupunta sa Polkadot Treasury. Mapaparusahan lang ang nominators kung nakalagak ang kanilang stake sa nagkasalang validator.

Mga offense na pwedeng mag-trigger ng slashing (halimbawa): Ipinapakita ng Polkadot ang validator offenses at tipikal na parusa. Kabilang dito ang mga sumusunod:

• Equivocation (BABE/GRANDPA/BEEFY): pag-double-sign ng blocks o votes. Slash range 0.01%–100% depende sa gravity at dami ng validator; disabled ang validator.
• Pagsuporta ng invalid parachain block: ang para-validator ay nagsuporta ng invalid block. 100% slash; on-chain disabling.
• ForInvalid vote: bumoto ang secondary checker para sa invalid block. 2% slash; disabling.
• AgainstValid vote: bumoto kontra sa valid block. 0% slash (walang stake loss) ngunit may disabling.

Unavailability vs slashing: Karaniwang outages ay nauuwi sa forced chilling (tigil sa pagiging validator) kaysa sa slashing. Sa Polkadot, “offline” slash ay tinitingnan lamang kung may network-level event—hal., ≥10% ng validator set ay sabay-sabay nawala. Madalas, kapag “prolonged” offline (mga 4 na oras) resulta ay chilling lang.

Sino ang nagbabayad at magkano: Ang slashes ay percentage base sa exposed stake ng validator slot (self-bond + bahaging nominator bond). Ang losses ng nominators ay pro-rata depende sa exposure nila sa offending validator; stake backing ng ibang validator ay hindi apektado. Ang percentage model ay sadyang umaayon sa stake at hikayat ng diversification.

Pagpapatupad, delay, at reversals: Pina-patagal ng Polkadot ang maraming slashes ng mga ~28 araw (unbonding period). Sa loob ng window na ito, maaaring i-cancel ng governance ang slash kung sanhi ito ng protocol bug o di tunay na kasalanan; kung hindi, ipapatupad bago pwedeng i-withdraw ang unbonded funds.

Saan napupunta ang slashed funds: Lahat ng slashed DOT ay napupunta sa on-chain Treasury na pinopondohan ang mga proyekto sa OpenGov.

Kaugnay na babasahin: para sa validator selection at stake assignment, tingnan ang NPoS section; para sa unbonding at pools tingnan ang staking sections.

Kapag nagsimula kang mag-unbond, ang naka-bond na DOT ay magiging “unlocking” at maaari lamang i-withdraw kapag natapos na ang 28-araw na unbonding period. Kailangan mong mag-execute ng Withdraw Unbonded upang maging transferable ito. (Sa Kusama 7 araw.)

Exception: Fast Unstake. Kung ang iyong account ay hindi na-expose sa anumang active validator sa huling 28 era, maaari mong gamitin ang Fast Unstake upang laktawan ang 28-araw na hintayan. Kung na-expose, kailangang maghintay ng usual period.

Staking pools vs direct nomination

Entry requirements & rewards eligibility:

• Direct nomination (solo): Kailangan malampasan ng bonded amount mo ang dynamic minimum active nomination threshold upang makatanggap ng reward; nagbabago ito sa paglipas ng panahon.
• Nomination pools: Ginawa para makasali ang mga may mas maliit na holdings; ayon sa opisyal na docs, possible na kumita ng kahit 1 DOT sa pools (depende sa laki at aktibidad ng pool).

Control & custody:

• Direct: Ikaw ang pumipili ng validator.
• Pool: Nananatili sa iyong account ang DOT mo (bonded), ngunit pool nominator ang pumipili ng validator; maaaring makaapekto sa rewards ang maling selection at shared pa rin ang risk sa slashing.

Operations (joining, switching, exiting):

• Unbonding time: 28 araw pa rin sa Polkadot para sa pool at direct. Pag-exit sa pool, maghihintay din ng 28 araw bago ma-withdraw.
• Switching pools: Kailangan mo munang mag-unbond (28 araw sa Polkadot; walang rewards sa panahong ito).
• Rebonding during unbonding: Ang direct nominators ay maaaring rebond anumang oras bago matapos ang 28 araw; ang pool members ay hindi maaaring rebond habang unbonding.
• Reward handling: Kapag nag-unbond ang pool member, ang anumang pending rewards ay awtomatikong naikiclaim sa iyong transferable balance sa withdrawal. May ilang pools na nag-aalok ng auto-compound; opt-in ito.

Ayon sa current guidance, maaaring bumoto sa OpenGov kahit staked sa pool, at maaari ring sumali sa pool gamit ang token na naka-lock na sa governance. (Pagbabago ito mula sa dating limitasyon.)

Para sa mga penalty na nakatali sa validator behaviour, tingnan ang Slashing.

Existential deposit (ED) at minimum account:

• Relay Chain ED: 1 DOT ang minimum para manatiling buhay ang Polkadot account. Kung bababa sa 1 DOT ang free balance, maaaring ma-reap (ma-remove) ang account at mawala ang anumang dust.
• Asset Hub ED: 0.01 DOT sa Polkadot Asset Hub (depende sa governance at chain). Maaaring sufficient ang assets doon (hindi kelangang DOT para hawakan ito) o non-sufficient (kailangan maabot ang DOT ED).

Keep-alive protection: Ang mga wallet tulad ng Polkadot-JS ay enabled ang “keep-alive” bilang default: hindi papayagang matuloy ang transfer na magdudulot na bumaba ang account sa ED. Maaari mo itong i-disable kung gusto mo ng full balance transfer at mawala ang sender account.

Fee model sa Relay Chain:

Weight-based fee system ang gamit ng Polkadot. Ang fee ng isang transaksyon ay suma ng:

• Base component (para sa bawat extrinsic)
• Length fee (ayon sa byte size)
• Weight fee (ayon sa execution weight ng tawag)
• Optional tip (para dagdag inclusion priority)
• May dynamic fee multiplier na bahagyang nagtataas o nagbababa ng fee ayon sa kamakailang block saturation (congestion).

Paano nakikita/tinatantya ang fees: Ipinapakita ng wallets at SDKs ang estimate bago pumirma (hal., paymentInfo sa polkadot.js). Ang fees ay binabawas mula sa transferable balance (hindi sa bonded funds).

Praktikal na tala:

• Pag-reactivate ng reaped na account: Mag-transfer lang ng at least kano ang ED ng chain (hal., 1 DOT sa Relay Chain).
• Chain-specific EDs: Nag-iiba ang ED batay sa chain; mas mababa ang ED ng Asset Hub kumpara sa Relay Chain. Tumingin ng latest values sa opisyal na support docs.
• Cross-chain moves: May destination-chain fee rin ang XCM operations (hal., teleports) at walang keep-alive enforcement; siguraduhing lampas pa rin sa ED ng destination chain ang post-fee balance. Tingnan ang XCM section para sa detalye.

Para sa staking-related minimums at unbonding times, tingnan ang staking sections; account-level fees at minimum balances ang focus dito.

Ang OpenGov ay on-chain governance system ng Polkadot. Binding ang proposals (“referenda”): kapag naipasa ang isang referendum, awtomatikong naipapatupad ito on-chain pagkatapos ng enactment period. Maraming referendum ang puwedeng tumakbo nang sabay-sabay.

Tracks at origins: Bawat referendum ay sinusumite sa isang track na tumutugma sa isang origin (level ng pribilehiyo na kailangan sa action). Bawat track ay nagtatalaga ng: decision deposit, mga oras ng window (prepare/decision/confirmation/enactment), approval/support curves (threshold), at kadalasan ay capacity ng sabay na desisyon. Mas mahigpit ang high-privilege track (hal. Root) kaysa low-impact track (hal. Small Tipper).

Ilang tawag ay puwedeng i-whitelist ng Polkadot Fellowship at maipatupad gamit ang Whitelisted Caller track, na may mas mabilis na parameters kapag naipasa. Nakadokumento ang track behaviour at halimbawa sa OpenGov “origins” guide.

Voting at conviction: Buboto ang token holder ng Aye/Nay/Abstain gamit ang DOT. Maaaring gumamit ng conviction voting (timelock multiplier) para mas malaki ang voting power kung mas matagal i-lock ang token; nagsisimula ang lock pagkatapos ng referendum at magtatapos ayon sa conviction period. Pwedeng iba’t ibang conviction ang gamitin sa iba’t ibang referendum.

Delegation at multi-delegations: Imbes na bumoto, puwedeng i-delegate ang voting power. Sinusuportahan ng OpenGov ang per-track (multi-)delegation: pwedeng ibang amount (at conviction) ang i-delegate sa bawat delegate/bawat track. Hindi mo puwedeng i-delegate ang track kung meron ka pang hindi-expired vote (o existing delegation) hangga’t hindi mo ito nililinis. Nakita sa official interfaces ang track pickers at conviction settings pag nagse-set ng delegation.

Referendum lifecycle (overview):

• Submission & prepare period – isinusumite ang referendum sa track; puwedeng magsimula ang voting, pero hindi pa bibilangin hanggang matapos ang prepare period. Kailangang ilagay ang decision deposit para makapasok sa deciding stage.
• Decision period – aktibong idinidesisyon ang item. Kailangang pumasa sa approval at support curves ng track.
• Confirmation period – kailangang manatili ang threshold na satisfied sa minimum confirmation window.
• Enactment period – kapag na-confirm, naka-queue na ang tawag at awtomatikong ipapatupad on-chain pagkatapos ng enactment delay.

Maaaring sumali sa OpenGov ang anumang DOT holder: maaaring mag-sumite ng proposal (referendum), bumoto direkta, o mag-delegate ng voting power. Ang mga aktibidad ay ginagawa sa “tracks” na nagtatakda ng origin (pribilehiyo), decision deposit, thresholds at time window. Magkakaiba ang parameters ng tracks at tinatakda ng governance.

Mag-propose (gumawa ng referendum):

1. Pumili ng tamang track para sa nais mong gawin (hal. Root para sa high-impact action, Tippers/Spenders para sa Treasury).
2. I-sumite ang referendum at siguraduhing may decision deposit; ito ay kinakailangan para makapasok ang item sa deciding stage at ibinabalik ayon sa rules sa track. Makikita sa UI ang deposit per referendum at refundable ito.

Kailangan: Polkadot account na may sapat na DOT para sa fees at decision deposit ng track. Optional ang on-chain identity ngunit kadalasang ginagamit ng proposer para sa kredibilidad; kailangan ng refundable deposit at registrar fee sa People parachain ang pag-set ng identity.

Vote (direktang partisipasyon):

• Pagpili: Aye, Nay, Abstain, Split (hatiin sa Aye/Nay), o SplitAbstain (hatiin sa Aye/Nay/Abstain).
• Conviction voting: opsyonal ang pag-lock ng DOT para sa mas mataas na voting power; nagsisimula ang lock pagkatapos ng referendum at nagtatapos ayon sa conviction. Pwedeng magkapatong-patong ang locks, kaya maaaring magamit ang parehong balanse para sa maraming vote o staking. Maaaring alisin ang vote habang ongoing ang referendum para agad ma-unlock; kung hindi, alisin ang expired locks pagkatapos ng period.

Makakaboto pa rin kahit staked o pooled ang DOT: Pinapahintulutan ng OpenGov ang pagboto kahit solo-staked o sa nomination pools, kasunod ng mga runtime update para makasali ang pooled accounts.

Delegate (per-track, multi-delegation): Kung ayaw mo bumoto sa bawat item, puwedeng mag-delegate ng voting power. Pinapayagan ng OpenGov ang multi-delegation per track: pumili ng ibang delegate bawat track, na may hiwalay na halaga at conviction. Hindi puwedeng mag-delegate sa track na may hindi-expired votes (o existing delegation) hangga’t hindi mo ito na-clear. Puwedeng i-manage ang delegations sa opisyal na UI (Polkadot-JS, Polkassembly, Nova, PolkaGate).

Praktikal na tooling:

• Polkadot-JS UI: mag-propose, bomoto, mag-delegate at mag-clear ng expired referendum locks.
• Polkassembly/Subsquare/Nova/PolkaGate: mag-browse ng referenda, bumoto (kasama Split/Abstain), mag-configure ng per-track delegations.

Para sa thresholds, time windows at deposit sizes, tingnan ang specific track kapag nagpo-propose o nagde-delegate; magkakaiba ang parameters bawat track at pwedeng magbago sa governance.

Ang Treasury ay on-chain pool ng pondo na kontrolado ng OpenGov. Tumatanggap ito ng mga inflow at mailalabas lang ang pondo sa pamamagitan ng governance-approved actions. Ang pondo ay nasa system account; walang external account na makakagalaw nito nang diretso.

Paano napupunan ang Treasury (inflows):

• Transaction fees: 80% ng fee ng bawat extrinsic ay napupunta sa Treasury; 20% sa block producer.
• DOT issuance: 15% ng taunang inflation ay itinutungo sa Treasury.
• Slashes: bahagi ng slashed stake mula sa validator offenses ay kinikredito sa Treasury.
• Direct transfers: maaaring magpadala ng asset sa Treasury account ang user (di karaniwan, hal. reimbursement).

Paano ginagastos ang Treasury (outflows):

• Treasury proposals (spends): governance ang pumapayag sa referenda na nagpapalipat ng pondo sa beneficiary. Naipapatupad ang payout sa schedule ng spend period; tuwing huli ng spend period, bahagi ng unspent funds ay sinusunog.
• Tips: mabilisang bayad via Small/Big Tipper tracks.
• Bounties & child bounties: one-off “parent” bounties na naglalaan ng pondo na ipinamamahagi ng curators sa mga child bounties para sa partikular na tasks/events; kapaki-pakinabang kung maraming bayaran sa takdang panahon. May deposit ang curator, may curator fee, at sila ang nagma-manage ng payout sa bounty duration.

Governance tracks para sa Treasury spending: Pinamamahalaan ng OpenGov ang outflows sa anim na tracks, bawat isa ay may sariling origin at parameters: Treasurer, Big/Medium/Small Spender, at Big/Small Tipper. Mas malalaking spend ay dumaraan sa mas mahigpit na track na mas mataas ang threshold at mas limitadong kapasidad; ang tips ay para sa mas maliliit na award.

Multi-asset Treasury support: Maaaring humawak at gumastos ang Treasury ng asset bukod sa DOT (hal. USDT/USDC) kung na-onboard ang asset sa Asset Hub at may conversion rate na itinakda ng governance sa Treasurer track. Tinukoy ng multi-asset spend ang asset, chain at amount; suportado rin ang milestone-based spend at manual claim windows.

Sub-treasuries (budget delegation): Maaaring maglaan ang governance ng parte ng Treasury sa sub-treasuries na naka-kabit sa collectives o system chains. Bawat sub-treasury ay may sariling rules para sa pag-disburse ng pondo, kaya hindi na kailangan ng hiwa-hiwalay na referenda sa main tracks.

Para sa pag-create, boto, o delegation ng Treasury proposal, tingnan ang OpenGov sections.

Ang Polkadot Fellowship ay isang on-chain collective ng mga technical contributor na nangangasiwa sa protocol runtime at technical standards. Nagtatrabaho ito sa Collectives system chain ng Polkadot at nagkokordina ng trabaho on-chain at sa public repositories (hal., RFCs ng mga proposisyon). Ilang runtime ng Polkadot at Kusama ay pinapanatili ng Fellowship, ngunit hindi nito hinaharangan ang protocol changes—maaari pa ring mag-propose ng runtime upgrade sa Root track sa OpenGov ang kahit sinong DOT holder.

Membership at ranks: Ang mga miyembro ay may rank, at ginagamit ang ranks sa internal na pagboto bilang timbang ng responsibilidad at technical review. May public dashboard sa Collectives chain para makita ang ranks at activity ng Fellowship.

Whitelisting & Whitelisted Caller track: Para sa urgent o low-risk, well-audited actions (kalimitan runtime releases), maaaring i-whitelist ng Fellowship ang isang call hash. Pinapayagan nito ang Whitelisted Caller track sa OpenGov na mag-dispatch ng call na iyon na may Root authority kapag lumusot ang referendum. Mas mabilis ang timelines ng track at iba ang approval/support curves kumpara sa Root, kaya may controlled fast path para sa vetted items.

Paano ina-apply ang upgrades: Sa Polkadot, runtime upgrades ay naipapatupad lang sa pamamagitan ng Root o Whitelisted Caller referenda. Ang papel ng Fellowship ay mag-review at mag-whitelist ng releases para magamit ang mas mabilis na track; kung hindi, sa Root process pa rin daraan.

Open development process: Nababantayan sa public RFC repo ng Fellowship ang mga technical proposal at design work; ang approve/decline signals at on-chain decisions ay visible sa token holders at voters.

Agile Coretime (blockspace bilang market)

Pinalitan ng Polkadot 2.0 ang pangmatagalang slot lease at crowdloans ng coretime market. Nakakabili ng execution time sa Relay Chain “cores” ang mga proyekto sa dalawang paraan:

• Bulk Coretime: buwanang “region” (umpisa ay ~28 araw, 5,040 timeslices) na binebenta sa espesyal na Coretime chain. Ipinaparehistro bilang non-fungible asset at puwedeng ibenta uli.
• Instantaneous Coretime: short bursts na binibili mula sa pool kapag kinakailangan (pay-as-you-go).

May descending-price “lead-in” (Dutch) sa bawat bentahan; may regular na presyo na ina-adjust ng governance hanggang magpantay sa demand. Bahagi ng disenyo ang secondary market para sa regions. Sinusunog ang kinikita mula sa coretime sales ayon sa approved Fellowship RFC. Ang net issuance ay gross issuance minus burns.

Epekto sa gastos: Mas planado ang gastos; bibili ng eksaktong kapasidad na kailangan nila at maliwanag ang price signal, wala nang multi-year lockup. Deprecated na ang auctions/crowdloans mula nang live ang Agile Coretime.

Async Backing (throughput & latency improvements)

Pinaghiwalay ng Asynchronous Backing ang paggawa ng parachain block sa pinakabagong Relay Chain block, kaya namo-move ang produkson ng maramihang candidate at overlapping backing at inclusion. Sa praktika, ito ay:

• nagpapahintulot sa parachain na gumawa ng bagong block kada ~6s (kumpara sa 12s dati)
• nagpapalapad ng execution window (mula ~0.5s ay ~2s) at kaya ~4× mas malalaking blocks
• nagdudulot ng hanggang ~8× na mas mataas na throughput at ~10× na may PoV-reclaim (totoong proof sizes)

Naipatupad ang mga pagbabagong ito noong 2024 (Kusama muna, pagkatapos Polkadot).

Impact sa performance: Mas mataas na TPS at mas mabilis ang inclusion para sa mga parachain na mag-enable; puwede pa ring sumunod ang iba kapag kailangan nila ng extra capacity.

Elastic Scaling (maramihang core kada chain)

Pinahihintulutan ng Elastic Scaling ang isang chain na gumamit ng maramihang core nang sabay-sabay (vertical scaling) sa halip na isa kada parachain. Katugma ito ng async backing at bagong collator/validator parameters para mas mataas ang throughput at mas mababa ang latency. Noong Agosto 2025, finalization na ang Elastic Scaling para sa mainnet enablement via OpenGov (Kusama muna, tapos Polkadot).

Impact sa performance: Ang mga rollup/parachain na mabigat ang load ay puedeng magkalat ng trabaho sa maraming core para mas malaki ang headroom kumpara kung hatiin sa maraming chain.

Summary ng epekto:

• Gastos at plano: market-driven at predictable ang coretime, wala nang long-term lease; monthly regions o on-demand slices na lang ang binibili; coretime revenue burn na bumabawas sa issuance.
• Throughput & latency: Mas madalas at mas malalaking block dahil sa async backing; dagdagan pa ng multi-core execution mula sa elastic scaling. Nagpapataas ng throughput nang hindi binabago ang shared-security model ng Polkadot.

1. I-build ang iyong chain:

   • Gamitin ang Polkadot SDK (Substrate + Cumulus) at magsimula sa parachain template. Bibigyan ka nito ng FRAME-based runtime, collator node at XCM hooks na pwedeng i-adapt.
   • Mag-connect local sa Relay Chain para mag-validate ng block production at basic XCM; may opisyal na tutorial kung paano mag-connect ng local parachain.

2. Testnet proving at kumuha ng ParaID:

   • Iproba ang upgrades at XCM sa Paseo (community testnet na may coretime features).
   • Mag-reserve ng ParaID sa target relay chain sa pamamagitan ng registrar: una reserve (may bayad na deposit), tapos register ng validation code (WASM) at genesis head. Nakasaad sa registrar pallet kada chain ang deposit. (Sa testnet, may eksaktong value sa docs; sa mainnet, governance ang nagtatakda.)

3. Kumuha ng Coretime (Polkadot 2.0):

   • Bulk Coretime (isang “Region”): bumili ng ~28-araw na region na katumbas ng 5,040 timeslices sa partikular na core, binebenta sa Coretime chain. Non-fungible asset ito at puwedeng ibenta uli; may descending-price lead-in papunta sa “regular price”.
   • Instantaneous Coretime: on-demand, short burst na kinukuha mula sa pool kapag hindi kailangan ng full region.
   • Accounting: Sinusunog ang coretime sales revenue ayon sa Fellowship RFC-0010 kaya dapat budgetan ng team ang DOT; wala nang lockup/crowdloan.

4. Magparehistro at mag-activate sa Relay Chain:

   • Kapag may ParaID, runtime WASM at genesis head, isumite ang registration at i-activate ang chain. Sa Polkadot, routine project onboarding gamit ang registrar; system chains (hal. Coretime, Asset Hub) ay nirehistro sa OpenGov (karaniwan Whitelisted Caller track), gaya ng ipinakita sa Coretime chain registration referendum.

5. Gamitin ang iyong network:

   • Collators: magpatakbo ng hindi bababa sa dalawang stable collator; mag-scale at mag-geo-distribute ayon sa load. (Validators nasa Relay Chain; collators ang provided ng parachain.)
   • XCM & HRMP: magbukas ng HRMP channels sa peers (hal. Asset Hub) at i-configure ang XCM (anong fee assets ang tatanggapin, reserve location). Para sa DOT routing, sumunod sa kasalukuyang guidance sa Asset Hub bilang DOT reserve habang nagkakaroon ng migration.
   • Upgrades: magpadala ng runtime upgrades sa governance ng chain mo; vavalidate ito ng Relay Chain during inclusion. (Para sa Relay-level parameters at OpenGov mechanics, tingnan ang governance sections.)

6. Rollups vs parachains (saan papasok ang “rollup” dito):

   • Kadalasan, ipinatutupad ng team ang “rollup” bilang parachain gamit ang SDK (settling at vavalidate ng Relay Chain) upang makuha ang availability/validity at XCM. Kung target ay rollup-as-a-service sa existing parachain, makikipag-ugnayan ka sa host at hindi ka bibili ng coretime mismo; susundin pa rin ang steps sa itaas para sa Relay-attached route. (Depende sa arkitektura.)

Minimum na requirements (checklist)

Technical:

• Polkadot SDK runtime (WASM) + chain spec, genesis head, at ParaID.
• Collator nodes, RPC endpoints, telemetry/monitoring.
• XCM configuration at minimum isang HRMP channel para sa integration.

Economic:

• DOT budget para sa coretime (Bulk o Instantaneous) at transaction fees; tandaan na sinusunog ang coretime spend.
• Registrar deposit para mag-reserve/register ng ParaID (amount chain-specific).

Governance touchpoints:

• Wala para sa ordinaryong registrar-based onboarding bukod sa sariling governance ng chain; system chains ay ina-onboard ng OpenGov (halimbawa: Coretime chain registration).

Native DOT vs wrapped/derivative DOT:

• Native DOT ay nasa loob mismo ng Polkadot (Relay Chain at system chains gaya ng Asset Hub). Sa loob ng Polkadot, gumagalaw ang DOT sa XCM (teleport, Relay ↔ Asset Hub), o sa reserve-based transfer kung represented ito sa ibang parachains. Nakabinbin ang migration ng DOT reserve location (XCM config) mula Relay Chain papunta Asset Hub; dapat ituring ng parachains ang Asset Hub bilang DOT reserve location simula ngayon.
• Wrapped/derivative DOT ay nasa labas ng Polkadot (hal., sa Ethereum) o ERC-20 compatible form sa loob ng EVM parachain. Sa Moonbeam, ang DOT ay xcDOT, isang XC-20: ERC-20 compatible representation na ang underlying DOT ay naka-lock sa sovereign account ng reserve chain, at ang ERC-20 interface ang ginagamit locally.

XCM sa Polkadot vs bridges sa panlabas na network:

• XCM (sa ecosystem): Format at pattern ng message para sa asset movement sa pagitan ng Relay Chain at parachains. Para sa DOT, teleporting ay enable sa trusted route (Relay ↔ Asset Hub); transfers papuntang ibang parachain ay reserve-based, reserve chain ang nagtatala ng total supply.
• Bridges (out of ecosystem): Sa paglipat sa networks gaya ng Ethereum, gumagamit ng bridge na naka-host sa Bridge Hub ang Polkadot. Ang opisyal na bridge (Snowbridge) ay light-client at Polkadot↔Ethereum. Nag-mint ito ng ERC-20 sa Asset Hub’s ForeignAssets pallet, at XCM reserve transfer ang naglilipat sa target parachain—so magkasama ang XCM at bridge dito.

EVM compatibility sa Moonbeam (XC-20s):

• XC-20 standard: Sa Moonbeam, ang cross-chain asset ay ginagawang XC-20 na may ERC-20 at Permit interfaces. Para sa DOT ito ay xcDOT. Developers ay pamilyar sa XC-20 gamit ang Ethereum tooling habang Polkadot ang bahala sa reserve accounting.
• Local vs external XC-20s: Ang home/reserve ng asset ay “local” kapag sa Moonbeam mismo; kung gaya ng DOT ay “external” XC-20, mananatili ang canonical balance sa reserve chain (Relay/Asset Hub), ang ERC-20 ay umiikot lang locally.

Practical notes:

• Kailan at ano gagamitin: Gamitin ang XCM sa loob ng Polkadot (hal., DOT sa Asset Hub at parachain). Gamitin ang bridge (hal., Snowbridge) papunta/pabalik sa panlabas na networks tulad ng Ethereum; ang bridged tokens ay hiwalay na representasyon na may iba’t ibang trust at risk model kompara sa native DOT.
• Patuloy na pagbabago: Ang migration ng DOT reserve location (papuntang Asset Hub) ay isang active process; dapat mag-update ng XCM config ang mga parachain at app para laging canonical ang transfer at accounting. Ipinapaskil ang guidance sa Polkadot Support at forum.

Sinimulan ang Polkadot ng Web3 Foundation (W3F), isang non-profit na nakabase sa Switzerland na ang flagship project ay Polkadot. Ang founder ng W3F ay si Dr Gavin Wood, na sumulat ng original Polkadot whitepaper noong 2016 na nagtukoy ng heterogeneous multi-chain na disenyo.

Ang development ng protocol at runtime ay pinangunahan ng Parity Technologies, engineering team na ka-partner ng W3F para maipalabas ang Polkadot mainnet noong 2020.

Ang founding team ng Polkadot ay kadalasang binabanggit sina Gavin Wood, Robert Habermeier at Peter Czaban. Sa launch announcement ng W3F, binanggit si Robert Habermeier bilang Polkadot co-founder at core developer, at si Peter Czaban bilang co-founder ng Polkadot at Web3 Foundation.

Inilunsad ng W3F ang live network rollout ng Polkadot noong 26 Mayo 2020, matapos ang ilang taon ng development; kasunod ng mga phase na ito, nailipat sa token holders ang control at nag-enable ng DOT issuance on-chain. Ang mechanics ng supply at redenomination ay nasa naunang sections.