Međutim, sa ekonomskog stanovišta, stejking nije automatski prihod, niti automatski znači pasivno uvećavanje bogatstva.

Kontrolna tabla za stejking može pokazati da ste zaradili 12% više tokena. Taj broj sam po sebi ne govori ništa o tome da li:

• Se vaš udeo u ukupnoj ponudi mreže povećao

• Je tržišna cena tokena zadržala vrednost

• Je nova emisija razvodnila postojeće vlasnike

• Su validatori ili platforme odbili provizije

• Je vaš kapital ostao likvidan

• Je protokol ostvario dovoljno prihoda od naknada da podrži svoje nagrade

• Se vaša kupovna moć povećala, izraženo u USD

Glavna zabluda malih investitora je jednostavna: uvećavanje broja jedinica neke imovine ne znači nužno i uvećavanje bogatstva.

Visok APY od stejkinga predstavlja stopu raspodele. On govori koliko brzo protokol, pod određenim pretpostavkama, dodeljuje tokene vašem novčaniku. Ne govori odakle je nagrada došla, šta se dogodilo sa ukupnom ponudom niti koliko će nagrada vredeti kada konačno budete mogli da je prodate.

Stejking i dalje može biti ekonomski racionalan. On pomaže u obezbeđivanju mreža koje koriste dokaz o ulogu, odnosno proof-of-stake, a neke mreže ostvaruju značajne prihode od transakcionih naknada. Greška nije u samom stejkingu. Greška je u tretiranju svakog oglašenog APY-a kao da je bankarska kamata, slobodan novčani tok ili garantovani investicioni prinos.

Tri vrste prinosa koje kripto-investitori često mešaju

Pre poređenja bankarske kamate sa nagradama od stejkinga, korisno je razdvojiti tri različita merila prinosa.

1. Nominalni prinos u tokenima

Ovo meri koliko ste dodatnih jedinica tokena dobili.

Nominalni prinos u tokenima = krajnje stanje tokena podeljeno početnim stanjem tokena, minus 1

Ako ste počeli sa 1.000 tokena, a završili sa 1.120, vaš nominalni prinos u tokenima bio je 12%.

To je broj koji većina kontrolnih tabli za stejking stavlja u prvi plan.

2. Prinos vlasničkog udela prilagođen razvodnjavanju

Ovo meri da li se vaš procentualni udeo u ukupnoj ponudi tokena mreže povećao ili smanjio.

Prinos vlasničkog udela prilagođen razvodnjavanju = krajnji procenat ponude podeljen početnim procentom ponude, minus 1

Ako se broj vaših tokena povećao za 12%, dok je ukupna ponuda porasla za 25%, vaš udeo u mreži se smanjio. Imate više tokena, ali svaki token predstavlja manji deo ukupne monetarne baze.

3. Prinos spoljne kupovne moći

Ovo meri šta vaša pozicija može da kupi izvan protokola.

Prinos portfolija u USD = (1 + neto prinos u tokenima) pomnoženo sa (1 + promena cene tokena), minus 1

Ako se broj vaših tokena poveća za 12%, ali cena tokena padne za 30%, vaše bogatstvo izraženo u USD smanjuje se za 21,6%, pre poreza, troškova gasa, proklizavanja cene i drugih troškova.

U tradicionalnoj monetarnoj ekonomiji, realni prinos obično znači nominalni prinos prilagođen inflaciji potrošačkih cena. Na kripto-tržištima izraz „realni prinos” koristi se slobodnije. Može da označava:

• Prinos od stejkinga prilagođen inflaciji ponude tokena

• Prinos koji se isplaćuje iz naknada protokola, a ne iz emisije tokena

• Prinos koji se isplaćuje u navodno stabilnoj ili neinflatornoj imovini

Ova značenja su povezana, ali nisu međusobno zamenljiva.

1. Bankarska kamata i blokčejn stejking ekonomski se razlikuju

Bankarska kamata, nagrade od nativnog stejkinga, prinosi od kripto-pozajmljivanja i podsticaji za obezbeđivanje likvidnosti često se prikazuju istim znakom procenta. Takav prikaz skriva činjenicu da potiču iz različitih ekonomskih aktivnosti.

Bankarska kamata je naknada po osnovu potraživanja iz duga

Kada se novac položi na bankarski depozitni račun, depozit postaje obaveza banke. Banka koristi depozite i druge izvore finansiranja za finansiranje imovine kao što su krediti, hartije od vrednosti i kamatonosna sredstva.

Zajmoprimci otplaćuju glavnicu i kamatu. Hartije od vrednosti stvaraju kamatni prihod. Banka deo svog prihoda isplaćuje deponentima, a zadržava kamatnu maržu nakon troškova finansiranja, kreditnih gubitaka, operativnih troškova i troškova kapitala.

Federalne rezerve opisuju neto kamatni prihod kao razliku između prihoda koji banka ostvaruje od kredita i druge kamatonosne imovine i kamate koju plaća na depozite i druge izvore finansiranja. U Sjedinjenim Američkim Državama, prihvatljivi depoziti u osiguranim institucijama imaju i regulatornu zaštitu i osiguranje depozita, u okviru važećih ograničenja. Kripto-stejking i kripto-proizvodi koji donose kamatu uglavnom ne pružaju ekvivalentnu zaštitu. (Izvori 1, 2 i 3.)

To ne znači da je bankarska kamata potpuno bezbedna niti da automatski donosi realnu dobit. Ako štedni račun plaća 4%, dok potrošačke cene rastu za 5%, deponent gubi kupovnu moć.

Ključna razlika nalazi se u izvoru i strukturi isplate. Bankarska kamata je trošak finansiranja podržan novčanim tokovima i bilansom stanja finansijske institucije. Ona se obično ne pripisuje programskim povećavanjem broja jedinica valutnog potraživanja pojedinačnog deponenta.

Proof-of-stake nagrade predstavljaju naknadu za bezbednost mreže

U proof-of-stake mreži validatori zaključavaju kapital i učestvuju u aktivnostima kao što su:

• Predlaganje blokova

• Potvrđivanje validnih blokova

• Održavanje dostupnosti mreže

• Sprovođenje pravila konsenzusa

• Obezbeđivanje ekonomskog kolaterala koji može biti kažnjen u slučaju nedozvoljenog ponašanja

Mreža mora da nadoknadi učesnicima pružanje ovih usluga, kao i prihvatanje rizika od slashing kazni, operativnih rizika, rizika likvidnosti i promena cene tokena.

Ta naknada može dolaziti iz nekoliko izvora:

• Emisije novoiskovanih tokena

• Transakcionih naknada

• Prioritetnih naknada ili napojnica

• Maksimalne vrednosti koja se može izvući, poznate kao MEV

• Podsticaja finansiranih iz trezora

• Prihoda od aplikacija ili usluga

Dokumentacija Ethereuma, na primer, razlikuje nagrade u novoiskovanom ETH-u od transakcionih napojnica i prihoda od MEV-a. Takođe objašnjava da se osnovna transakciona naknada spaljuje, umesto da se isplaćuje validatorima. To pokazuje zašto investitori moraju da prouče sastav nagrada od stejkinga, umesto da svaki nagradni token tretiraju kao ekonomski identičan. (Izvori 4 i 5.)

Novoiskovana nagrada jeste legitimna naknada za stvarnu uslugu — bezbednost mreže. Ali ona ne predstavlja nužno novo bogatstvo za vlasnike tokena kao grupu. Ako se isplata stvara povećavanjem ponude, budžet za bezbednost delimično se finansira razvodnjavanjem.

Stejking nije isto što i pozajmljivanje ili kreiranje tržišta

Kripto-platforme često svrstavaju nekoliko suštinski različitih aktivnosti pod zajednički naziv „zarada”.

Dokumentacija Aavea, na primer, navodi da se prinosi dobavljača kapitala finansiraju kamatama zajmoprimaca, umanjenim za rezervni faktor protokola. To se ekonomski razlikuje od nagrade za stejking koja se prvenstveno finansira novom emisijom tokena. (Izvor 9.)

Isto tako, pružalac likvidnosti koji zarađuje naknade od razmene dobija nadoknadu za pružanje zaliha i prihvatanje rizika trgovanja. Nazivanje sve tri aktivnosti „pasivnim prihodom” uklanja informaciju koja je investitorima najpotrebnija: ko plaća prinos i zašto?

Više jedinica ne garantuje veće bogatstvo

Zamislite da je tržišna vrednost mreže jedna pita.

Broj vaših tokena predstavlja broj parčića koje posedujete. Ukupna ponuda tokena predstavlja broj parčića na koje je pita podeljena.

Ako broj vaših parčića poraste za 12%, dok ukupan broj parčića poraste za 25%, vaš deo pite postaje manji. Postajete bogatiji samo ako sama pita dovoljno poraste da nadoknadi to razvodnjavanje.

To je imenilac koji nedostaje u većini marketinških poruka o visokom APY-u.

2. Mehanika razvodnjavanja tokena

U diskusijama o kriptovalutama, „inflacija” obično označava rast ponude tokena. To se razlikuje od inflacije potrošačkih cena, koja meri promene cena robe i usluga.

Važno je nekoliko pokazatelja ponude.

Bruto emisija

Bruto emisija predstavlja broj novih tokena stvorenih i distribuiranih tokom određenog perioda.

Ti tokeni mogu biti dodeljeni:

• Validatorima

• Delegatorima

• Pružaocima likvidnosti

• Zajmoprimcima

• Programerima

• Trezoru protokola

• Programima grantova za ekosistem

Spaljivanje tokena

Spaljivanjem se tokeni trajno uklanjaju iz ponude.

Neke mreže spaljuju transakcione naknade. Druge koriste prihode protokola za kupovinu i spaljivanje tokena. Spaljivanje može nadoknaditi deo ili celu bruto emisiju, ali investitor mora da proveri stvarni neto efekat.

Neto rast ukupne ponude

Neto rast ukupne ponude = novoizdati tokeni minus spaljeni tokeni, podeljeno početnom ukupnom ponudom

Ako mreža izda 10 miliona tokena i spali 2 miliona, neto emisija iznosi 8 miliona.

Rast ponude u opticaju

Ponuda u opticaju može porasti čak i kada se ne iskuje nijedan novi token.

Ranije stvoreni tokeni mogu ući na tržište putem:

• Otključavanja tokena tima i investitora

• Distribucija fondacije

• Trošenja sredstava iz trezora

• Grantova za ekosistem

• Airdrop kampanja

• Rudarskih ili stejking rezervi

• Alokacija market mejkerima

Otključavanje ne mora povećati ukupnu ponudu, jer tokeni možda već postoje. Međutim, ono povećava količinu dostupnu za trgovanje i potencijalnu prodaju.

Token sa fiksnom maksimalnom ponudom zato može imati značajnu inflaciju ponude u opticaju.

Učešće u stejkingu

Odnos između inflacije tokena i APY-a od stejkinga u velikoj meri zavisi od procenta ponude koji je stejkovan.

Pretpostavimo sledeće:

• Ukupna ponuda iznosi 100 tokena

• Protokol godišnje stvara 10 novih tokena

• Stejkovano je samo 50 tokena

• Svih 10 novih tokena dodeljuje se učesnicima u stejkingu

Stopa inflacije ukupne ponude mreže iznosi 10%. Međutim, bruto stopa nagrade na stejkovane tokene iznosi približno 20%, jer se 10 novih tokena deli na samo 50 stejkovanih tokena.

Ta istaknuta stopa od 20% nije nastala ni iz čega. Protokol je povećao ukupnu ponudu za 10%.

Učesnici u stejkingu povećavaju relativni vlasnički udeo na štetu onih koji ne stejkuju. Kada bi svaki vlasnik proporcionalno stejkovao tokene, nagrada bi uglavnom očuvala relativni udeo svakog vlasnika, pre naknada i razlika u poslovanju. Sama emisija ne bi stvorila ukupno novo bogatstvo.

Zbog toga neke nagrade od stejkinga prvenstveno funkcionišu kao mehanizam zaštite od razvodnjavanja. Investitori stejkuju zato što bi ih izostanak iz stejkinga još brže razvodnio.

Akademski modeli opisuju nagrade za blokove kao inflatorne transfere između vlasnika sa različitim ponašanjem u stejkingu i različitim investicionim horizontima. Istraživanja proof-of-stake sistema takođe pokazuju da su visoke nominalne stope stejkinga često povezane sa visokom inflacijom, zbog čega su prinosi prilagođeni inflaciji znatno manje privlačni od istaknutih stopa. (Izvori 6, 7 i 8.)

Konkretan primer: nagrade od 12% i inflacija ponude od 25%

Razmotrimo hipotetičku mrežu.

Novčanik investitora pokazuje uspešnu godinu:

• Početno stanje: 1.000 tokena

• Nagrada od stejkinga: 120 tokena

• Krajnje stanje: 1.120 tokena

• Nominalni prinos u tokenima: 12%

Ali ukupna ponuda povećala se za 25%.

Udeo investitora u ponudi promenio se na sledeći način:

• Početni udeo: 1.000 podeljeno sa 100.000.000, odnosno 0,001000%

• Krajnji udeo: 1.120 podeljeno sa 125.000.000, odnosno 0,000896%

• Promena vlasničkog udela: −10,4%

Investitor je zaradio 12% više jedinica, ali je izgubio 10,4% svog relativnog udela u mreži.

Precizan obračun prinosa prilagođenog razvodnjavanju glasi:

Prinos prilagođen razvodnjavanju = 1,12 podeljeno sa 1,25, minus 1

Prinos prilagođen razvodnjavanju = −10,4%

Brza aproksimacija oduzela bi inflaciju ponude od 25% od nominalnog prinosa od 12% i dala rezultat od −13 procentnih poena. Ta aproksimacija je korisna za početnu procenu, ali je obračun odnosa precizniji kada su stope visoke.

Šta se dešava sa cenom tokena?

Inflacija tokena ne primorava cenu mehanički da padne za isti procenat. Cena zavisi i od ponude i od tražnje.

Osnovni odnos glasi:

Cena tokena = tržišna vrednost mreže podeljena ponudom tokena u opticaju

Na početku primera:

• Ponuda: 100 miliona tokena

• Cena: 10 USD

• Tržišna vrednost mreže: 1 milijarda USD

Ako tržišna vrednost mreže ostane tačno 1 milijarda USD, dok ponuda poraste na 125 miliona tokena, cena postaje:

1 milijarda USD podeljena sa 125 miliona tokena = 8 USD po tokenu

To predstavlja pad cene od 20%, a ne od 25%. Razlika postoji zato što poništavanje povećanja ponude od 25% zahteva deljenje sa 1,25.

Krajnja vrednost portfolija investitora bila bi:

1.120 tokena pomnoženo sa 8 USD = 8.960 USD

Uprkos zaradi od 12% kroz stejking, investitor gubi 1.040 USD, odnosno 10,4%.

Pretpostavimo sada da slaba tražnja i kontinuirana prodaja obore cenu tokena na 7 USD.

Vrednost portfolija postaje:

1.120 tokena pomnoženo sa 7 USD = 7.840 USD

Broj tokena investitora povećao se za 12%, ali je vrednost pozicije izražena u USD pala za 21,6%.

Da bi bio na nuli nakon što zaradi 12% više tokena, cena mora ostati iznad približno 8,93 USD.

Cena za pokriće troškova = 10 USD podeljeno sa 1,12

Pad cene veći od približno 10,7% briše celokupan prinos od 12% u tokenima.

Ovaj obračun i dalje ne obuhvata:

• Proviziju validatora

• Naknade platforme

• Troškove gasa

• Troškove preuzimanja i reinvestiranja nagrada

• Raspon između kupovne i prodajne cene

• Proklizavanje cene

• Poreze

• Inflaciju potrošačkih cena

Nemojte dvaput računati inflaciju i pad cene

Prinos vlasničkog udela prilagođen razvodnjavanju i prinos portfolija u USD odgovaraju na različita pitanja.

Rast ponude koristite da utvrdite da li se vaš udeo u ekonomiji tokena povećao ili smanjio.

Stvarnu tržišnu cenu koristite da utvrdite svoj stvarni tržišni prinos.

Ako je cena tokena već pala kao odgovor na emisije, ponovno oduzimanje pune stope inflacije od realizovanog prinosa u USD značilo bi da deo istog ekonomskog efekta računate dvaput.

Ispravna pitanja su:

Ko finansira inflatorne nagrade od stejkinga?

Na nivou protokola, budžet za bezbednost ima dva osnovna izvora:

1. Korisnici plaćaju mrežne usluge putem naknada.

2. Vlasnici tokena finansiraju bezbednost kroz monetarno razvodnjavanje.

Kada se nagrade prvenstveno finansiraju novom emisijom, ekonomski teret se raspoređuje nejednako.

Oni koji ne stejkuju trpe direktno razvodnjavanje

Vlasnik koji ne učestvuje u stejkingu ne dobija nijedan novoisporučeni token, dok se ukupna ponuda povećava. Njegov relativni udeo opada.

To može pretvoriti stejking iz opcione strategije prihoda u odbrambenu obavezu. Vlasnik ne stejkuje zato što mreža stvara privlačan prinos, već zato što bi ostanak van stejkinga bio još nepovoljniji.

I učesnici u stejkingu mogu biti razvodnjeni

Učesnik u stejkingu može zaraditi manje od stope rasta ponude mreže zbog:

• Provizija validatora

• Zastoja u radu

• Propuštenih potvrda

• Slashing kazni

• Odloženog reinvestiranja

• Pravila o minimalnom stanju

• Nejednakog pristupa MEV-u

• Naknada platforme

• Promena stope učešća u stejkingu

APY veći od nule ne garantuje da će učesnik u stejkingu sačuvati svoj relativni vlasnički udeo.

Kupci finansiraju prodate nagrade

Validatori i delegatori često moraju da pretvore nagrade u stabilne kriptovalute ili fiat valutu kako bi platili:

• Hosting i infrastrukturu

• Zaposlene i izvođače

• Poreze

• Upravljanje rizikom

• Isplate investitorima

• Operativne troškove

Prodaja nagrada sama po sebi nije manipulativna. To je normalno upravljanje trezorom.

Tržišna posledica je ipak važna. Za svaki prodati token mora postojati kupac. Ako je organska tražnja dovoljno snažna, tržište može apsorbovati emisije bez velikog pada. Ako je tražnja slaba, tržišna ravnotežna cena mora pasti dok kupci ne postanu spremni da drže dodatnu ponudu.

flowchart LR
    A[Protokol raspodeljuje nagrade od stejkinga] --> B[Validatori i delegatori dobijaju tokene]
    B --> C{Reinvestirati, zadržati ili prodati}
    C -->|Prodati| D[Tokeni ulaze u likvidnost otvorenog tržišta]
    D --> E{Postoji li dovoljna organska tražnja?}
    E -->|Da| F[Emisije su apsorbovane]
    E -->|Ne| G[Tržišna ravnotežna cena pada]
    C -->|Reinvestirati| H[Investitor povećava izloženost tokenu]

Veliki vlasnici mogu imati strukturne prednosti

Institucionalni validatori, rani investitori, fondacije i profesionalne kompanije za stejking mogu imati prednosti koje mali investitori nemaju:

• Niže operativne troškove po tokenu

• Veću pouzdanost validatora

• Automatizovano preuzimanje nagrada

• Pristup MEV infrastrukturi

• Niže troškove trgovanja

• Mogućnost zaštite od rizika promene cene tokena

• Znatno nižu prvobitnu nabavnu cenu

• Bolju likvidnost i izvršenje naloga

• Profesionalno upravljanje porezima i trezorom

Profesionalni validator može svakodnevno prodavati nagrade, dok glavni ulog ostaje nepromenjen. Rani investitor može ostati profitabilan i pri cenama daleko nižim od ulazne cene novijeg malog investitora.

Nasuprot tome, mali investitori često se podstiču da automatski reinvestiraju nagrade. Reinvestiranje može biti korisno kada je osnovni realni prinos pozitivan. Kada je očekivani realni prinos negativan, reinvestiranje samo povećava izloženost imovini koja gubi vrednost.

Otključavanje tokena ranih investitora takođe treba odvojiti od emisija za stejking. Oba događaja mogu povećati tržišnu ponudu, ali predstavljaju različite tokenomske događaje. Ozbiljna analiza prati ih odvojeno.

3. Nelikvidnost i zamka perioda odvezivanja

APY od stejkinga obično se prikazuje na godišnjem nivou. Gubici na kripto-tržištu ne nastaju po godišnjem rasporedu.

Token može izgubiti 30% ili 40% za nekoliko dana, dok se nagrade od stejkinga sporo akumuliraju tokom više meseci. Ako pozicija podleže periodu odvezivanja, odnosno unbonding periodu, vlasnik možda neće moći da reaguje.

Zašto postoje periodi odvezivanja

Odvezivanje nije samo nepraktična karakteristika proizvoda. Ono često ima bezbednosnu funkciju.

Protokolu može biti potrebno vreme da otkrije nedozvoljeno ponašanje, obradi izlazak validatora, primeni slashing kazne ili sačuva ekonomske posledice radnji preduzetih dok je validator bio aktivan.

U zavisnosti od mreže i načina stejkinga, periodi čekanja mogu trajati danima ili nedeljama. Prema stanju iz septembra 2026. godine, zvanična dokumentacija novčanika Keplr navodi primere od 21 dana za Cosmos Hub i 14 dana za Osmosis. Neki mrežni modeli i proizvodi za stejking koriste ili su ranije koristili periode koji se približavaju 28 dana. Parametri se mogu promeniti kroz upravljanje protokolom, pa investitori moraju proveriti aktuelna pravila umesto da se oslanjaju na stari članak ili interfejs berze. (Izvor 10.)

Tokom odvezivanja investitori se mogu suočiti sa nekim od sledećih ograničenja:

• Tokeni ne mogu da se prenesu

• Tokeni ne mogu da se prodaju

• Tokeni ne mogu da se koriste kao kolateral

• Nagrade prestaju da se obračunavaju

• Izloženost slashing kaznama se nastavlja

• Potrebna je posebna transakcija za povlačenje

• Redovi za izlazak produžavaju stvarno kašnjenje

• Obrada berze ili kastodijana dodaje još vremena

Matematika sporog prinosa i brzih gubitaka

Pretpostavimo da token oglašava APY od 12% i ima period odvezivanja od 28 dana.

Kada bi se godišnja stopa od 12% ravnomerno obračunavala tokom 28 dana, u tom periodu bi donela približno 0,87%.

Pad cene tokena od 30% više je od 34 puta veći od nagrade akumulirane tokom 28 dana.

U mnogim sistemima investitori ne dobijaju nagrade tokom odvezivanja. Investitor zato može snositi ceo rizik promene cene, a da tokom izlaznog perioda ne zarađuje ništa.

Razmotrimo duži period držanja:

• Početna pozicija: 1.000 tokena

• APY: 12%

• Vreme provedeno u stejkingu: dve godine

• Krajnje stanje nakon godišnjeg ukamaćivanja: 1.254,4 tokena

• Nominalni dobitak u tokenima: 25,44%

Pretpostavimo sada da cena tokena padne za 40% pre nego što investitor uspe da završi izlazak.

Faktor vrednosti portfolija postaje:

1,2544 pomnoženo sa 0,60 = 0,75264

Investitor je u gubitku od približno 24,7% u odnosu na prvobitnu vrednost izraženu u USD, čak i nakon dve pune godine nominalnih nagrada od stejkinga.

Višegodišnje akumuliranje tokena može biti izbrisano naglim padom za svega nekoliko dana.

Zbog toga se na kripto-stejkingu može izgubiti novac čak i kada svaka nagrada bude isplaćena tačno onako kako je obećano.

Likvidnost je ekonomska opcija

Mogućnost trenutne prodaje ima vrednost. Odricanje od te mogućnosti znači odricanje od opcije da:

• Smanjite izloženost

• Zaštitite se od rizika

• Otplatite dug

• Izbegnete likvidaciju

• Premestite kolateral

• Pređete u bezbedniju imovinu

• Reagujete na zloupotrebu ili hakovanje protokola

• Odgovorite na promene upravljanja

• Izađete nakon velikog otključavanja tokena

• Napustite poziciju kada se promeni rizik validatora ili kastodijana

Duže zaključavanje zato bi trebalo da donese premiju za nelikvidnost. Oglašeni APY možda delimično nadoknađuje izgubljenu fleksibilnost, ali tu naknadu treba proceniti u odnosu na volatilnost tokena.

Premija prinosa od 3 procentna poena nije privlačna ako se vrednost pozicije može promeniti za 20% dok je zarobljena u redu za izlazak.

Likvidni stejking menja rizik umesto da ga uklanja

Tokeni likvidnog stejkinga pokušavaju da povrate likvidnost tako što investitorima daju prenosivu potvrdu koja predstavlja stejkovanu imovinu.

To može smanjiti potrebu za čekanjem nativnog perioda odvezivanja pre izlaska. Međutim, uvodi dodatne rizike:

• Rizik pametnih ugovora

• Rizik upravljanja protokolom

• Koncentraciju validatora

• Rizik proročanstava, odnosno oracle sistema

• Rizik reda za otkup

• Rizik likvidnosti na sekundarnom tržištu

• Diskont između prijemnog tokena i osnovne imovine

• Rizik mostova na drugim mrežama

• Rizik finansijske poluge kada se prijemni token ponovo koristi kao kolateral

Istraživanja derivata likvidnog stejkinga pokazala su da razlika između cene tokena likvidnog stejkinga i njegove osnovne imovine zavisi od faktora koji obuhvataju volatilnost, tržišnu likvidnost, nagrade od stejkinga, rizik koncentracije i ograničenja arbitraže. (Izvor 11.)

Diskont nije samo tehnička zanimljivost. To je tržišna cena trenutne likvidnosti i dodatnih rizika povezanih sa derivatom.

Ako se token likvidnog stejkinga tokom krize trguje uz diskont od 7%, investitor koji odmah izađe može se odreći višemesečnog prihoda od stejkinga. Ako umesto toga sačeka otkup, može se suočiti sa istim rizikom odvezivanja ili čekanja u redu koji je pokušao da izbegne.

Pitanja na koja treba odgovoriti pre prihvatanja zaključavanja

• Koliko dana traje nativno odvezivanje?

• Da li odbrojavanje počinje odmah?

• Da li se tokom odvezivanja zarađuju nagrade?

• Može li ulog i dalje biti predmet slashing kazne tokom izlaznog perioda?

• Može li upravljanje produžiti ili drugačije promeniti proces izlaska?

• Postoji li red za izlazak ili dnevno ograničenje otkupa?

• Može li validator ili platforma odložiti povlačenje?

• Da li trenutni izlazak zavisi od tokena likvidnog stejkinga?

• Koliko je duboko sekundarno tržište tog tokena?

• Koliki je bio njegov diskont tokom prethodnih tržišnih kriza?

• Da li se stejkovana imovina koristi kao kolateral na drugom mestu?

• Može li pad cene izazvati likvidaciju pre završetka odvezivanja?

Period odvezivanja treba tretirati kao deo trajanja i profila rizika investicije, a ne kao nevažan tehnički detalj.

4. Realni prinos naspram inflatornih emisija

Izraz „realni prinos” često se koristi u kripto-marketingu bez dosledne definicije.

Stroga analiza koristi najmanje dva odvojena koncepta:

1. Prinos u tokenima prilagođen razvodnjavanju

2. Prinos podržan prihodima ili finansiran naknadama

Nijedan od ova dva koncepta ne garantuje pozitivan prinos u USD.

Početni obračun realnog prinosa od stejkinga

Za brzu procenu investitori mogu koristiti:

Približni realni prinos od stejkinga = nominalni APY od stejkinga minus godišnji neto rast ponude tokena minus godišnje naknade i troškovi

To je najjednostavnija verzija poređenja APY-a od stejkinga sa inflacijom tokena.

Pretpostavimo da mreža oglašava APY od 18%.

Validator naplaćuje proviziju od 10% na nagrade. Ta provizija ne smanjuje APY za 10 procentnih poena. Ona uzima 10% od nagrade od 18%:

• Bruto APY od stejkinga: 18%

• Provizija validatora: 1,8 procentnih poena

• Neto APY od stejkinga: 16,2%

• Neto rast ponude tokena: 14%

• Godišnji troškovi gasa i poslovanja: 0,4%

Približan prinos prilagođen razvodnjavanju iznosi:

16,2% minus 14% minus 0,4% = 1,8%

Istaknuta stopa iznosi 18%. Približan realni prinos u tokenima iznosi samo 1,8%.

Precizniji obračun

Kada su stope visoke, koristite odnos umesto jednostavnog oduzimanja.

Precizan prinos prilagođen razvodnjavanju = (1 + neto prinos od stejkinga nakon provizije) podeljeno sa (1 + neto rast ponude), minus 1

Za isti primer:

1,162 podeljeno sa 1,14, minus 1 = približno 1,93%

Nakon oduzimanja procenjenih godišnjih troškova od 0,4%, rezultat iznosi približno 1,53%.

Tačan broj zavisi od vremena isplate nagrada, naplate naknada, emisije i reinvestiranja. Svrha obračuna nije stvaranje lažne preciznosti. Svrha je da pokaže kako oglašeni APY od 18% može predstavljati samo mali jednocifreni rast relativnog vlasničkog udela.

Pozitivan prinos prilagođen razvodnjavanju i dalje može doneti gubitak u USD

Pretpostavimo da investitor ostvaruje neto prinos u tokenima od 16,2%, ali cena tokena padne za 20%.

Prinos u USD pre transakcionih troškova iznosi:

1,162 pomnoženo sa 0,80, minus 1 = −7,04%

Investitor je povećao relativni vlasnički udeo u poređenju sa pasivnim vlasnicima tokena, ali je i dalje izgubio novac izraženo u USD.

To nije protivrečnost. Investitor je nadmašio razvodnjavanje ponude tokena, dok je sam token izgubio tržišnu vrednost.

Tri obračuna, tri različita odgovora

Investitori ne bi trebalo da sabijaju sva ova pitanja u jedan APY.

Odakle održivi kripto-prinos zaista dolazi

Prinos je ekonomski održiv kada se može utvrditi ko plaća vrednu uslugu i kada isplata može da se nastavi bez beskonačnog razvodnjavanja tokena.

To investiciju ne čini bezbednom. Samo čini izvor prinosa razumljivijim.

Mrežne naknade

Korisnici mogu plaćati za:

• Prostor u bloku

• Poravnanje transakcija

• Izvršavanje pametnih ugovora

• Dostupnost podataka

• Prioritetno uključivanje

• Komunikaciju između različitih blokčejnova

• Aplikacione usluge

Ako validatori dobijaju deo tih plaćanja, deo nagrade od stejkinga podržan je stvarnom tražnjom za mrežnim uslugama.

Analizom ipak treba utvrditi gde naknade odlaze. One mogu biti:

• Isplaćene validatorima

• Isplaćene pružaocima likvidnosti

• Spaljene

• Položene u trezor

• Zadržane u aplikaciji

• Podeljene vlasnicima tokena

• Iskorišćene za otkup tokena

Mreža može ostvarivati značajne naknade, a da ih ne raspodeljuje investitorima u njen token.

Kamate zajmoprimaca

U protokolu za pozajmljivanje, zajmoprimci plaćaju pristup kapitalu. Dobavljači kapitala dobijaju deo te kamate.

To je sličnije kreditnom posredovanju nego nativnom stejkingu. Dokumentacija Aavea, na primer, objašnjava da se stope za dobavljače kapitala finansiraju kamatama zajmoprimaca i menjaju u skladu sa stopom iskorišćenosti. (Izvor 9.)

Prinos i dalje može biti dopunjen podsticajima u upravljačkim tokenima. Investitori treba da razdvoje:

• Osnovni APY od dobavljanja kapitala, ostvaren plaćanjima zajmoprimaca

• Podsticajni APY isplaćen kroz emisije tokena

Pozicija sa ukupnim APY-em od 14% može se sastojati od 4% kamate koju finansiraju zajmoprimci i 10% subvencije u nagradnim tokenima. Te komponente imaju različitu održivost i različite rizike.

Naknade od trgovanja

Decentralizovane berze naplaćuju trgovcima izvršavanje razmena. Pružaoci likvidnosti mogu dobiti deo tih naknada.

To jeste stvarno stvaranje prihoda od naknada, ali prihod od naknada nije isto što i neto dobit. Pružaoci likvidnosti mogu izgubiti novac zbog:

• Privremenog gubitka

• Nepovoljnog izbora

• Arbitraže

• Troškova rebalansiranja

• MEV-a

• Razilaženja cena tokena

• Pozicija koje izađu iz zadatog raspona

• Neuspeha pametnih ugovora

Fond likvidnosti može ostvariti visoke naknade, dok njegovi pružaoci prolaze lošije nego da su jednostavno držali osnovnu imovinu.

Prihod od imovine iz stvarnog sveta

Neki protokoli raspodeljuju prihod povezan sa:

• Državnim hartijama od vrednosti

• Korporativnim kreditima

• Privatnim zajmovima

• Finansiranjem trgovine

• Nekretninama

• Instrumentima za upravljanje gotovinom

Ekonomski izvor može biti poznat, ali tokenizacija uvodi pravne, kastodijalne, oracle, emitentske, jurisdikcione i rizike otkupa.

Blokčejn omotač ne uklanja osnovni kreditni rizik.

Emisije tokena

Nagrade finansirane emisijama predstavljaju subvencije. Postojeći ili budući vlasnici tokena na kraju ih finansiraju kroz razvodnjavanje, trošenje sredstava iz trezora ili povećanje ponude u opticaju.

Subvencije nisu automatski nelegitimne. Mladim mrežama one mogu biti potrebne da:

• Izgrade skup validatora

• Privuku likvidnost

• Raspodele upravljačka prava

• Pokrenu mrežne efekte

• Subvencionišu rano korišćenje

• Nadoknade učesnicima rad pre razvoja prihoda od naknada

Ključno pitanje je da li subvencionisana aktivnost postaje samoodrživa pre završetka subvencija.

Ako korisnici nestanu čim se nagrade smanje, protokol nije stvorio trajnu tražnju. Samo je iznajmio privremeni kapital.

BIS opisuje rudarenje likvidnosti kao raspodelu upravljačkih tokena radi podsticanja učešća u protokolu, uz razlikovanje tih podsticaja od naknada koje plaćaju stvarni korisnici. (Izvor 12.)

Praktična tabela izvora prinosa

Prihod protokola nije automatski prinos vlasnika tokena

Jedna od najčešćih grešaka u tokenomici jeste pretpostavka da prihod protokola nužno koristi tokenu.

Protokol može ostvariti 100 miliona USD godišnjih naknada, a sav taj prihod usmeriti:

• Validatorima

• Programerima aplikacija

• Pružaocima likvidnosti

• Centralizovanoj kompaniji

• Trezoru protokola

• Rezervama osiguranja

Upravljački token možda nema nikakvo ugovorno ili programsko pravo na taj prihod.

Pre nego što prihod protokola nazovete „realnim prinosom”, utvrdite da li token dobija vrednost kroz izričit mehanizam kao što su:

• Direktna raspodela naknada

• Otkup tokena

• Spaljivanje

• Obavezna tražnja za stejkingom

• Upotreba kao kolaterala

• Trezori za raspodelu prihoda

• Upravljanje ekonomski vrednim novčanim tokovima

Čak i ti mehanizmi zahtevaju pažljivu proveru.

Program otkupa može izgledati privlačno dok protokol istovremeno izdaje više tokena nego što kupuje. Spaljivanje može smanjivati ukupnu ponudu, dok otključavanje investitorskih tokena u većoj meri povećava ponudu u opticaju. Zahtev za stejking može stvarati tražnju dok povezana aplikacija posluje sa gubitkom.

Pravo merilo je neto zahvatanje vrednosti, a ne bruto prihod.

Isplate u stabilnim kriptovalutama ne dokazuju da je prinos realan

Nagrada isplaćena u USDC-u, USDT-u ili drugoj stabilnoj kriptovaluti i dalje može biti finansirana:

• Prodajom novoizdatih upravljačkih tokena

• Trošenjem ograničenih sredstava iz trezora

• Zaduživanjem

• Leveridžovanim kružnim strategijama

• Prilivom novih deponenata

• Privremenim promotivnim budžetima

• Neodrživim subvencijama za trgovanje

Valuta u kojoj je nagrada iskazana nije njen ekonomski izvor.

Isplata u stabilnoj kriptovaluti može smanjiti izloženost promeni cene nagradnog tokena, ali ne uklanja rizik pametnih ugovora, druge ugovorne strane, solventnosti, likvidnosti ili subvencija.

Test bez podsticaja

Jedno od najkorisnijih pitanja pri proceni protokola glasi:

Šta bi se dogodilo kada bi podsticaji u tokenima sutra bili smanjeni na nulu?

Potražite dokaze da bi:

• Zajmoprimci nastavili da pozajmljuju

• Trgovci nastavili da trguju

• Korisnici nastavili da plaćaju transakcione naknade

• Likvidnost ostala odgovarajuća

• Aplikacije zadržale aktivne korisnike

• Validatori mogli da budu plaćeni iz naknada

• Prihod protokola ostao pozitivan

• Tražnja za tokenom postojala i bez APY kampanje

Ako čitav ekosistem zavisi od novoemitovanih tokena, oglašeni prinos nije dokaz ekonomske produktivnosti. On je deo budžeta za pridobijanje korisnika.

Zašto visoki APY prinosi iscrpljuju portfolije malih investitora

Visoki APY prinosi naročito su štetni kada se nekoliko slabosti međusobno pojačava.

1. Nagrada se meri u tokenu koji gubi vrednost

Investitor dobija 20% više jedinica, ali cena nagradnog tokena pada za 60%. APY je isplaćen tačno onako kako je oglašeno, ali investitor ipak gubi znatan deo bogatstva.

2. Protokol oglašava bruto, a ne neto prinos

Istaknuta stopa može isključivati:

• Proviziju validatora

• Naknade platforme

• Naknade za učinak

• Naknade za povlačenje

• Gas

• Proklizavanje cene

• Troškove mostova

• Neuspele transakcije

• Troškove reinvestiranja

Male pozicije su naročito ranjive, jer fiksni transakcioni troškovi troše veći procenat kapitala.

3. Inflacija ponude skrivena je iza istaknute stope

APY od 20% izgleda privlačno dok investitor ne otkrije da se očekuje povećanje ponude u opticaju od 30%.

Nagrada možda neće nadoknaditi razvodnjavanje.

4. APY pretpostavlja da će nestabilna stopa trajati celu godinu

Mnoge kontrolne table godišnje projektuju stopu iz poslednjeg sata, dana, nedelje ili epohe nagrađivanja.

Privremena kampanja podsticaja može prikazati trocifreni APY iako:

• Budžet za nagrade traje samo nekoliko nedelja

• Više depozita deliće nagradu na veći kapital

• Emisije tokena opadaju prema rasporedu

• Upravljanje može promeniti stopu

• Obim trgovanja je privremen

• Cena nagradnog tokena ubrzano pada

APY je projekcija, a ne obećanje.

5. Reinvestiranje povećava koncentraciju u istom riziku

Automatsko reinvestiranje predstavlja se kao pokretač stvaranja bogatstva. Ekonomski gledano, svaka nagrada ponovo se ulaže u isti token ili istu strategiju.

Ako imovina ima negativan očekivani realni prinos, reinvestiranje samo povećava izloženost.

Reinvestiranje ne popravlja lošu tokenomiku.

6. Zaključavanje uklanja mogućnost upravljanja rizikom

Investitor polako ostvaruje godišnji prinos, ali ostaje izložen trenutnim događajima kao što su:

• Padovi cena

• Zloupotrebe i hakovanja

• Gubitak vezanosti stabilne kriptovalute

• Kvarovi validatora

• Napadi na upravljanje

• Nesolventnost berze

• Regulatorni događaji

• Otključavanja tokena

• Navale na povlačenje likvidnosti

APY može biti naknada za prihvatanje ovog rizika, a ne besplatan bonus.

7. Veliki vlasnici mogu prodavati dok mali investitori nastavljaju da reinvestiraju

Profesionalni učesnici mogu kontinuirano pretvarati nagrade u novac, štititi glavnicu od rizika ili imati znatno nižu nabavnu cenu.

Mali investitori često tumače pad cene kao priliku da zarade još više tokena. Mehanizam nagrađivanja tako može postati kanal kroz koji likvidna tražnja apsorbuje izlaske vlasnika sa nižom nabavnom cenom.

Takav ishod nije garantovan, ali strukturu podsticaja treba proučiti pre pretpostavke da svi učesnici imaju jednaku korist.

8. Potraga za prinosom privlači privremeni kapital

Visoke emisije mogu privući kapital koji nema nikakvu posvećenost dugoročnom korišćenju protokola.

Kada se podsticaji smanje:

• Depoziti odlaze

• Ukupna zaključana vrednost opada

• Tržišna likvidnost postaje plića

• Proklizavanje cene raste

• Tražnja za tokenom slabi

• Preostali vlasnici imaju veće troškove izlaska

Početni APY stvorio je aktivnost, ali ne nužno i trajnu ekonomiju.

Praktična kontrolna lista za tokenomiku

Korisna analiza stejkinga počinje izvorom prinosa, a ne njegovom veličinom.

Minimalni model stejkinga sa šest brojeva

Pre stejkinga investitor bi trebalo da ume da zapiše najmanje šest brojeva.

1. Neto APY nagrade

Počnite od oglašenog APY-a, a zatim oduzmite provizije validatora, naknade platforme i realne troškove reinvestiranja.

2. Neto rast ukupne ponude

Izmerite novu emisiju nakon spaljivanja.

3. Rast ponude u opticaju

Dodajte planirana otključavanja, distribucije iz trezora, grantove i druge prethodno zaključane tokene za koje se očekuje da uđu u opticaj.

4. Udeo nagrada finansiran naknadama

Procenite koji procenat nagrada dolazi od korisnika, zajmoprimaca ili trgovaca, umesto iz subvencija u tokenima.

Udeo nagrada finansiran naknadama = ekonomski ostvarene nagrade podeljene ukupno raspodeljenim nagradama

5. Cena tokena za pokriće troškova

Krajnja cena za pokriće troškova = početna cena tokena podeljena sa (1 + neto prinos u tokenima)

Ako token počinje na 10 USD, a neto prinos od stejkinga iznosi 12%, približna cena za pokriće troškova iznosi 8,93 USD.

To pokazuje koliki pad cene tokena nagrada može da apsorbuje pre nego što prinos u USD postane negativan.

6. Vreme do likvidnosti

Zabeležite ukupno vreme od odluke o izlasku do dobijanja slobodno prenosive imovine.

Uključite:

• Pokretanje prekida stejkinga

• Period odvezivanja

• Redove za izlazak validatora

• Obradu otkupa

• Kašnjenja mostova

• Vreme uplate na berzu

• Očekivano proklizavanje pri prodaji

Token koji može izgubiti 30% za nedelju dana ne treba procenjivati kao da je kašnjenje izlaska od 28 dana ekonomski nevažno.

Kako tumačiti rezultat

Obračuni obično svrstavaju priliku za stejking u jednu od četiri kategorije.

Zaštita od inflacije

Prinos od stejkinga približno odgovara rastu ponude nakon naknada.

Investitor prvenstveno štiti postojeću poziciju od razvodnjavanja. Nagradu ne treba opisivati kao značajan pasivni prihod.

Pozitivan relativni prinos, negativan tržišni prinos

Prinos od stejkinga premašuje rast ponude, ali cena tokena dovoljno pada da izazove gubitak u USD.

Investitor prolazi bolje od onih koji ne stejkuju, ali i dalje gubi novac.

Subvencionisani spekulativni prinos

Veći deo nagrade dolazi iz emisija, trošenja sredstava trezora ili privremenih podsticaja.

Strategija može biti profitabilna ako investitor dobro odabere trenutak ulaska i izlaska, ali prinos zavisi od trajne tražnje za nagradnim tokenom. To nije samofinansirajući tok prihoda.

Prinos podržan prihodima

Značajan deo nagrade dolazi iz ponovljenih transakcionih naknada, kamata zajmoprimaca, naknada od trgovanja ili druge ekonomske aktivnosti.

To je ekonomski najjača kategorija, ali i dalje zahteva analizu:

• Održivosti prihoda

• Mehanizma kojim token zahvata vrednost

• Rizika glavnice

• Likvidnosti

• Bezbednosti pametnih ugovora

• Izloženosti drugoj ugovornoj strani

• Tržišne volatilnosti

„Realni prinos” znači da nagrada ima verodostojniji izvor. Ne znači da je investicija niskorizična.

Ispravan način razmišljanja o APY-u od stejkinga i inflaciji tokena

Visok APY nije dokaz dobre investicije. Nizak APY nije dokaz loše investicije.

Prinos od stejkinga od 5% na korisnoj mreži sa niskom neto emisijom, snažnom tražnjom za uslugama koje stvaraju naknade, likvidnim izlazom i verodostojnim mehanizmom kojim token zahvata vrednost može biti ekonomski bolji od prinosa od 25% na mreži čija se ponuda u opticaju povećava za 40%.

Ispravan redosled analize je:

1. Utvrdite ekonomsku aktivnost.

2. Utvrdite ko plaća nagradu.

3. Odvojite naknade i kamate od podsticaja u tokenima.

4. Izračunajte neto emisiju tokena.

5. Izračunajte rast ponude u opticaju.

6. Prilagodite nagradu za provizije i troškove.

7. Uporedite nagradu sa razvodnjavanjem ponude.

8. Izračunajte cenu tokena za pokriće troškova.

9. Testirajte scenario ozbiljnog tržišnog pada.

10. Procenite celokupan vremenski period izlaska.

11. Proverite da li prihod protokola zaista koristi tokenu.

12. Tek na kraju pogledajte APY.

Generička lista „Pet najboljih tokena sa APY-em od 20%” preokreće ovaj redosled. Ona rangira marketinški rezultat pre nego što ispita ekonomske ulazne podatke.

Nagrade od stejkinga nisu same po sebi lažne, a emisija tokena nije sama po sebi prevara. Proof-of-stake mrežama potreban je budžet za bezbednost, naročito tokom ranih faza razvoja.

Ali emisija i dalje predstavlja trošak. Ako naknade ne pokrivaju taj trošak, vlasnici tokena finansiraju ga kroz razvodnjavanje. Ako veliki primaoci prodaju nagrade, kupci na otvorenom tržištu moraju da apsorbuju ponudu. Ako tražnja ne uspe da održi korak, cena tokena pada. Ako su investitori zaključani tokom tog pada, godine nominalnog prinosa mogu nestati pre završetka perioda odvezivanja.

Najkorisniji princip ujedno je i najjednostavniji:

APY meri raspodelu tokena. Stvaranje bogatstva zahteva ekonomsku vrednost, trajnu tražnju, zdravu tokenomiku i održiv način izlaska.

Rast broja tokena može biti pasivan. Rast životnog standarda zahteva mnogo više.

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti i prodati kriptovalute. Više informacija nalazi se na stranici Volet za korisnike iz Srbije. Za otvaranje naloga koristi Volet referral link. Link je referral link autora članka.

Izvori

1. Julianne Baer, „Banking Analytics: Lower Asset Yields Squeeze Bank Interest Margins”, Federal Reserve Bank of St. Louis, 2026.

2. Federal Deposit Insurance Corporation, „Deposit Accounts”.

3. U.S. Securities and Exchange Commission, „Investor Bulletin: Crypto Asset Interest-Bearing Accounts”.

4. Ethereum.org, „Technical Introduction to Ether”.

5. Ethereum.org, „Proof-of-Stake”.

6. Lin William Cong, Zhiheng He i Ke Tang, „The Tokenomics of Staking”, NBER Working Paper 33640, 2025.

7. Kose John, Thomas J. Rivera i Fahad Saleh, „Equilibrium Staking Levels in a Proof-of-Stake Blockchain”.

8. Nicolas Oderbolz, Beatrix Marosvölgyi i Matthias Hafner, „Towards an Optimal Staking Design: Balancing Security, User Growth, and Token Appreciation”.

9. Dokumentacija Aave protokola, „Aave 101”.

10. Zvanična podrška novčanika Keplr, „Staking and Unstaking”.

11. Stefan Scharnowski i Hossein Jahanshahloo, „The Economics of Liquid Staking Derivatives: Basis Determinants and Price Discovery”, Journal of Futures Markets, 2025.

12. Raphael Auer, Bernhard Haslhofer, Stefan Kitzler, Pietro Saggese i Friedhelm Victor, „The Technology of Decentralized Finance”, BIS Working Paper 1066, 2023.

13. Volet Srbija

English version: Read on Dev.to: Staking's Passive Income Mirage: APY vs Token Inflation

Propisi o nasleđivanju i ostavinskom postupku određuju ko ima pravo na imovinu preminule osobe. Blokčejn određuje da li transakcija sadrži važeći potpis. On ne čita testamente, ne prepoznaje umrlice, ne postupa po nalozima ostavinskih sudova i ne prenosi novčanik na imenovanog naslednika.

Zbog toga izvršilac testamenta može imati pravno ovlašćenje nad kripto-imovinom, a da ipak ne može da je prenese. Nasuprot tome, svako ko dođe do privatnih ključeva može da premesti sredstva, čak i ako na njih nema nikakvo zakonsko pravo.

Nekastodijalni novčanik, odnosno novčanik sa samostalnim čuvanjem ključeva, nije nalog koji neka kompanija može da otključa. Imovina ostaje evidentirana na blokčejnu, dok novčanik upravlja ključevima potrebnim za odobravanje transakcija. Ako se ti ključevi izgube, možda neće postojati postupak za resetovanje lozinke, korisnička podrška niti sudski nalog koji može da ih rekonstruiše.

Praktično rešenje nije da seed frazu, odnosno frazu za oporavak, stavite u testament ili podesite da je usluga u oblaku pošalje imejlom nakon nekoliko meseci neaktivnosti. Pouzdan plan za nasleđivanje kripto-imovine razdvaja četiri stvari:

1. Pravno ovlašćenje

2. Pronalaženje i identifikovanje imovine

3. Kriptografski oporavak

4. Kontrolisani prenos ili likvidaciju

Ovaj članak objašnjava kako da izgradite takav sistem, bez potrebe da naslednici postanu stručnjaci za sajber bezbednost.

Ovo su operativne smernice, a ne individualni pravni ili poreski savet. Propisi o zaostavštini, trastovima, imovini i fiducijarnim dužnostima razlikuju se u zavisnosti od jurisdikcije. Advokat treba da prilagodi pravni deo plana propisima koji se primenjuju na vlasnika, zaostavštinu, trast, izvršioca testamenta i korisnike ili naslednike.

Šta se dešava sa nekastodijalnim novčanikom kada umrete?

Na blokčejnu se ništa ne dešava automatski.

Adresa nastavlja da postoji. Tokeni ostaju na toj adresi. Pametni ugovori nastavljaju da rade u skladu sa svojim kodom. Staking pozicije, kolateralizovani zajmovi, pozicije likvidnosti i vremenski zaključana imovina mogu ostati aktivni. Blokčejn nema ugrađen način da sazna da je osoba koja kontroliše ključeve preminula.

Ono što će se zatim dogoditi zavisi od modela čuvanja imovine.

Kod kastodijalnog naloga izvršilac testamenta možda će moći da dostavi umrlicu, sudsko rešenje o imenovanju, dokumenta trasta i druge evidencije pružaocu usluge.

Kod nekastodijalnog novčanika ta dokumenta dokazuju ovlašćenje, ali ne stvaraju važeći blokčejn potpis. Nekome su i dalje potrebni odgovarajući privatni ključevi, materijal za oporavak, uređaji za potpisivanje i podaci o konfiguraciji novčanika.

To stvara dva različita oblika kontrole:

• Pravna kontrola: pravo na upravljanje imovinom ili njeno nasleđivanje

• Tehnička kontrola: sposobnost da se napravi važeća transakcija

Potpun plan nasleđivanja mora da obezbedi oba oblika kontrole.

Zašto tradicionalni testamenti zakazuju kod imovine na blokčejnu

Testament je pravno uputstvo, a ne mehanizam za oporavak ključeva.

Tokom ostavinskog postupka originalni testament se uglavnom predaje sudu. Sud utvrđuje da li je dokument punovažan i imenuje izvršioca testamenta ili zastupnika zaostavštine. To lice zatim identifikuje imovinu zaostavštine, rešava dugove i poreske obaveze i raspodeljuje preostalu imovinu.

U Njujorku, na primer, izvršilac testamenta predaje originalni testament, umrlicu, predlog za pokretanje ostavinskog postupka i prateća dokumenta Sudu za zaostavštine. Masačusets uglavnom tretira predmete koji se odnose na zaostavštine i upravljanje njima kao javno dostupne, osim ako je neki spis posebno ograničen ili stavljen pod zaštitu suda. Druge jurisdikcije imaju sopstvena pravila o podnošenju dokumenata i javnom pristupu, ali ostavinski spisi i testamenti često postaju dostupni za uvid ili kopiranje.

Zbog toga je standardni testament jedno od najgorih mesta za objavljivanje:

• Privatnog ključa

• Seed fraze ili fraze za oporavak

• PIN-a hardverskog novčanika

• BIP39 dodatne fraze, odnosno passphrase-a

• Dovoljnog broja delova tajne da se dostigne prag za oporavak

• Šifrovane seed fraze zajedno sa uputstvima za njeno dešifrovanje

Fraza za oporavak nije samo lozinka. Ona može da omogući potpunu kontrolu nad svakim novčanikom izvedenim iz nje. Objavljivanje takve fraze u ostavinskom spisu funkcionalno je bliže objavljivanju potpisanog blanko čeka nego objavljivanju broja računa.

Čak i kada ostavinski spis nije pretraživ na internetu, možda je i dalje dostupan u zgradi suda ili ga ovlašćeni učesnici mogu kopirati. Svaka osoba i svaki sistem koji obrađuje dokument postaju deo bezbednosnog perimetra.

Javna adresa nije privatni ključ, ali je ipak osetljiv podatak

Javna adresa novčanika uglavnom ne može da se koristi za trošenje imovine. Ipak, ona može da otkrije stanje, istoriju transakcija, druge strane u transakcijama, tokene, pozicije u protokolima i buduće prenose.

Objavljivanje adrese sa imovinom velike vrednosti u testamentu može da pretvori ostavinski predmet u spisak potencijalnih meta. Kriminalci mogu da je koriste za identifikovanje naslednika, praćenje aktivnosti zaostavštine, lažno predstavljanje kao korisnička podrška za novčanike ili slanje phishing poruka u trenutku kada započne proces nasleđivanja.

Javne adrese zato treba tretirati kao osetljive inventarske podatke, iako nisu tajni materijal za potpisivanje.

Šta testament ili trast treba da sadrže

Dokumenta koja se odnose na zaostavštinu treba da uspostave ovlašćenje i nameru vlasnika, a da pritom ne otkrivaju ključeve.

U zavisnosti od lokalnih propisa i okolnosti vlasnika, advokat će možda morati da uredi ovlašćenje poverenog lica da:

• Pristupi digitalnim uređajima i obezbedi ih

• Upravlja digitalnom imovinom i virtuelnim valutama

• Pristupi kastodijalnim nalozima i povezanim evidencijama

• Angažuje kvalifikovane pravne, poreske, bezbednosne ili blokčejn stručnjake

• Plaća mrežne, kastodijalne, skladišne i transakcione naknade

• Prenosi imovinu u naturi

• Likvidira imovinu kada je to primereno

• Upravlja stakingom, pozajmljivanjem, kolateralom, upravljačkim pravima i pozicijama u protokolima

• Pribavlja poresku i transakcionu evidenciju

• Uspostavi privremeno čuvanje imovine u ime zaostavštine ili trasta

• Raspodeljuje imovinu korisnicima ili naslednicima

• Postupa tokom nesposobnosti vlasnika, kao i nakon njegove smrti

Dokument može da navede postojanje zasebnog inventara digitalne imovine ili memoranduma o nasleđivanju. Ne treba da sadrži same tajne za oporavak.

Pravno dejstvo zasebnog memoranduma može da se razlikuje. On može biti administrativni vodič, a ne obavezujući dokument kojim se raspolaže imovinom. Advokat za nasledno pravo treba da odluči na koji način će memorandum biti pomenut, čuvan, potvrđen kao autentičan, ažuriran i dostavljen.

Propisi o digitalnoj imovini ne mogu da rekonstruišu privatne ključeve

Revidirani jedinstveni zakon o fiducijarnom pristupu digitalnoj imovini pruža poverenim licima okvir za upravljanje digitalnom imovinom, uključujući virtuelne valute i naloge na internetu. On takođe uređuje slučajeve u kojima pružaoci usluga mogu da otkriju digitalnu imovinu ili elektronsku komunikaciju.

To može pomoći kada kompanija kontroliše odgovarajući nalog ili podatke.

Ne rešava, međutim, problem samostalnog čuvanja. Kod nekastodijalnog novčanika možda ne postoji pružalac usluge koji bilo šta može da otkrije ili resetuje. Zakon može da imenuje osobu ovlašćenu da postupa, ali blokčejn će i dalje zahtevati odgovarajući potpis.

Pravilno osnovan i finansiran trast može da poboljša kontinuitet i smanji izloženost ostavinskom postupku. Ipak, on ne uklanja potrebu za testiranim postupkom oporavka ključeva. Nasledni poverenik trasta bez ključeva ima isti tehnički problem kao izvršilac testamenta bez ključeva.

Bezbednosni problem nasleđivanja

Plan nasleđivanja mora istovremeno da štiti od nekoliko različitih rizika:

• Krađe dok je vlasnik živ

• Trajnog gubitka nakon smrti

• Preranog pristupa naslednika ili insajdera

• Uništenja jedine fizičke rezervne kopije

• Gubitka dodatne fraze ili konfiguracije novčanika

• Zabune u vezi sa mrežama, nalozima ili derivacionim putanjama

• Kvara hardvera ili zastarevanja softvera

• Grešaka izvršioca testamenta

• Phishing napada tokom perioda žalosti

• Pravnih sporova između naslednika

• Nepotpune poreske i transakcione evidencije

• Prevelike složenosti zbog koje niko ne može da sprovede plan

Ovi rizici su međusobno suprotstavljeni.

Ako jedna osoba danas dobije kompletnu frazu za oporavak, nasleđivanje postaje jednostavno, ali je bezbednost tokom života vlasnika slabija. Ako niko ne može da pristupi ključu do smrti vlasnika, neka osoba, institucija ili sistem mora da odluči kada pristup treba da bude odobren. Ako su za oporavak potrebni svi delovi tajne, gubitak samo jednog dela uništava ceo plan. Ako je potreban premali broj delova, dogovor i zloupotreba više učesnika postaju lakši.

Ne postoji mehanizam koji bez pouzdane treće strane ili dodatnih tehničkih pretpostavki može istovremeno da garantuje sve sledeće:

1. Niko osim vlasnika ne može da pristupi imovini pre njegove smrti.

2. Naslednici mogu da pristupe imovini odmah nakon smrti.

3. Nijednoj instituciji ili osobi nije povereno da potvrdi smrt.

Realističan plan prihvata ovaj kompromis i zajedno koristi pravno ovlašćenje, pristup zasnovan na pragu, nezavisna mesta čuvanja i ljudsku proveru.

Zašto „prekidači za slučaj smrti” zakazuju u praksi

Automatizovani „prekidač za slučaj smrti”, poznat i kao dead man’s switch, obično funkcioniše ovako:

1. Vlasnik čuva tajnu ili podešava automatizovanu transakciju.

2. Vlasnik mora periodično da potvrđuje da je živ.

3. Ako potvrda ne stigne, sistem objavljuje informacije ili prenosi imovinu.

Ideja deluje elegantno jer kašnjenje ostavinskog postupka zamenjuje automatizacijom. Problem je u tome što neaktivnost nije dokaz smrti.

Lažna aktiviranja

Živi vlasnik može da propusti potvrdu zbog:

• Hospitalizacije

• Dužeg putovanja

• Boravka u pritvoru ili zatvoru

• Gubitka telefona ili bezbednosnog ključa

• Filtriranja imejlova

• Suspenzije naloga

• Zaboravljenih podsetnika u kalendaru

• Kognitivnog propadanja

• Promene broja telefona

• Neuspele autentifikacije

• Prirodne katastrofe ili prekida komunikacija

Ako sistem objavljuje privatni ključ, samo jedna propuštena potvrda može da izloži ceo novčanik.

Izostanak aktiviranja

Može se dogoditi i suprotno. Sistem možda neće biti aktiviran nakon smrti zato što:

• Uređaj na kome je vlasnik ostao prijavljen nastavlja da se sinhronizuje

• Imejl klijent nastavlja da proverava poruke

• Automatizovani proces registruje aktivnost na nalogu

• Član porodice koristi računar vlasnika

• Usluga pogrešno protumači pozadinsku aktivnost kao ljudsku

• Napadač kompromituje nalog i namerno ga održava aktivnim

Google-ov Menadžer neaktivnih naloga, na primer, procenjuje signale kao što su prijavljivanje, aktivnost na nalogu, korišćenje Gmaila i provere Android uređaja. Automatska sinhronizacija uređaja takođe može da stvori privid nedavne aktivnosti na nalogu.

Zbog toga je takav sistem koristan za obaveštenja i deljenje odabranih podataka, ali ne predstavlja pouzdan način utvrđivanja smrti.

Zavisnost od pružaoca usluge u oblaku

Prekidač zasnovan na usluzi u oblaku zavisi od mnogo više stvari nego što su samo uputstva korisnika. Može da zavisi od toga da:

• Pružalac usluge nastavi da nudi tu funkciju

• Nalog ostane otvoren

• Adrese za oporavak naloga ostanu važeće

• Primalac zadrži isti broj telefona

• Pružalac usluge pravilno potvrdi identitet primaoca

• Formati za čuvanje podataka ostanu čitljivi

• Podaci ne budu izbrisani u skladu sa pravilima o neaktivnosti

• Uslovi korišćenja i zakonski zahtevi ostanu usklađeni sa planom

To su prihvatljive zavisnosti za sistem podsetnika ili dostavljanje dokumenata. Opasne su ako je u pitanju jedina kopija seed fraze.

Rizici pametnih ugovora

Pametni ugovor može da primeni tajmer, postupak sa starateljima ili pravila oporavka. Pametni nalozi i sistemi apstrakcije naloga mogu da podrže fleksibilna pravila oporavka, više staratelja i programabilni pristup.

Takvi sistemi mogu biti korisni, naročito kada su profesionalno implementirani i stalno održavani. Ipak, ni oni ne znaju da je neka osoba umrla. Oni znaju samo da je:

• Tajmer istekao

• Izostala potvrda određenog ključa

• Potreban broj staratelja odobrio zahtev

• Orakul dostavio određenu tvrdnju

• Nastupio unapred definisan uslov transakcije

Pametni ugovor može da sadrži ranjivost, da zavisi od ključa za nadogradnju, releja ili orakula ili da nepredviđeno reaguje u interakciji sa drugim ugovorom. Pametni ugovori mogu da kontrolišu veliku vrednost, teško ih je ispraviti nakon postavljanja i ostaju izloženi greškama u kontroli pristupa, logici, orakulima i integracijama.

Nova površina za phishing napade

Sistemi za periodičnu potvrdu stvaraju ponavljajući i predvidiv bezbednosni ritual. Napadači mogu da imitiraju:

• Poruke „Potvrdite da ste živi”

• Obaveštenja o verifikaciji novčanika

• Zahteve za odobrenje staratelja

• Stranice za prijavljivanje na usluge u oblaku

• Zahteve za ažuriranje hardverskog novčanika

• Transakcije za oporavak putem pametnih ugovora

Primalac koji očekuje vremenski određenu poruku u vezi sa nasleđivanjem verovatnije će poverovati i dobro napravljenoj lažnoj poruci.

Pravilna uloga automatizacije

Automatizacija može biti korisna za:

• Podsećanje vlasnika da pregleda plan

• Obaveštavanje advokata ili člana porodice nakon dužeg perioda neaktivnosti

• Dostavljanje paketa uputstava koji ne sadrži tajne

• Identifikovanje izvršioca testamenta i advokata

• Pokretanje procesa ljudske provere

• Potvrđivanje da inventar imovine postoji

Ne treba automatski da objavi kompletnu seed frazu, privatni ključ ili dovoljan broj delova za dostizanje praga.

Bezbedno pravilo je jednostavno: automatizaciju koristite za pokretanje postupka nasleđivanja, a ne za dovršavanje kriptografskog prenosa.

Realističan protokol nasleđivanja kripto-imovine u četiri koraka

Nijedan sistem nasleđivanja nije doslovno nepogrešiv. Najbliže praktično rešenje jeste plan otporan na greške, bez tajni u javnim spisima, bez jedne fizičke tačke otkaza i bez koraka koji primorava naslednika da improvizuje.

Sledeći protokol u četiri koraka namenjen je ljudima koji nisu programeri i može da se primeni kako na skroman hardverski novčanik, tako i na portfelj velike vrednosti.

Korak 1: Uspostavite ovlašćenje i napravite mapu imovine bez tajnih podataka

Počnite razdvajanjem uloga osoba uključenih u plan.

Plan može da obuhvati:

• Vlasnika: osobu koja trenutno kontroliše imovinu

• Povereno lice: izvršioca testamenta, zastupnika zaostavštine ili naslednog poverenika trasta sa pravnim ovlašćenjem

• Tehničkog operatera: pouzdanu osobu ili stručnjaka koji razume oporavak novčanika

• Čuvare delova tajne: osobe ili institucije koje čuvaju pojedinačne delove za oporavak

• Naslednike ili korisnike: osobe koje imaju zakonsko pravo na imovinu

• Advokata i poreskog stručnjaka: savetnike odgovorne za pravna i poreska pitanja

Kod portfelja velike vrednosti jedna osoba ne bi trebalo automatski da obavlja sve uloge. Naslednik možda nije najbolji izvršilac testamenta. Izvršilac testamenta možda nije tehnički osposobljen za rukovanje hardverskim novčanikom. Tehničkom operateru ne treba dozvoliti da samostalno radi sa dovoljnom količinom materijala za oporavak.

Napravite tri odvojena sloja informacija

Sloj 1: Dokumenta zaostavštine

Ona utvrđuju ko ima ovlašćenje i ko prima imovinu. Ne sadrže ključeve, fraze, PIN-ove ni delove tajne.

Sloj 2: Ograničena mapa imovine i oporavka

Ona ovlašćenom poverenom licu govori šta postoji, kako se čuva, koji se standard oporavka primenjuje i gde se nalaze odvojene komponente za oporavak. I dalje ne sadrži dovoljno tajnog materijala za trošenje imovine.

Sloj 3: Tajne za oporavak

To su seed fraza, kriptografski delovi tajne, dodatna fraza ili ključevi za potpisivanje. Čuvaju se van mreže i odvojeno od testamenta i potpune mape imovine.

Šta mapa imovine treba da sadrži

Navođenje samo simbola tokena nije dovoljno. Mapa mora da identifikuje mrežu i vrstu pozicije. Stabilni token na jednoj mreži operativno se razlikuje od istog stabilnog tokena na drugoj mreži. Token uložen u protokol za pozajmljivanje razlikuje se od istog tokena koji se nalazi neposredno u novčaniku.

Za svaki novčanik evidentirajte:

• Prvu proverenu adresu za prijem

• Mrežu

• Naziv naloga ili novčanika

• Aplikaciju novčanika

• Standard rezervne kopije

• Da li se koristi dodatna fraza

• Da li novčanik koristi jedan potpis ili multisig

• Svaku neuobičajenu derivacionu putanju ili vrstu naloga

• Lokaciju konfiguracionih podataka koji nisu tajni

• Lokaciju i uslove predaje materijala za oporavak

Inventar može da se čuva u šifrovanom digitalnom dokumentu, na bezbednom portalu advokata ili u zapečaćenom fizičkom paketu. Treba da postoje najmanje dve kopije sa kontrolisanim pristupom.

Metod za dešifrovanje inventara mora da ima sopstveni plan nasleđivanja, ali ne treba da koristi iste pristupne podatke koji kontrolišu kripto-imovinu.

Korak 2: Uspostavite oporavak zasnovan na pragu i bezbednu hardversku proceduru

Cilj oporavka zasnovanog na pragu jeste da jedan ukradeni dokument ne bude dovoljan za pražnjenje novčanika, uz istovremenu mogućnost oporavka ako jedno mesto čuvanja bude uništeno.

Nemojte ručno deliti seed frazu na delove

Zapisivanje prvih 12 reči na jednom mestu, a poslednjih 12 na drugom, nije pravilan način kriptografske podele tajne.

Ručno deljenje stvara nekoliko problema:

• Svaki fragment otkriva deo originalne tajne.

• Možda ne postoji nikakva redundantnost.

• Gubitak jednog fragmenta može da onemogući oporavak.

• Uputstva mogu biti nejasna.

• Naslednici možda neće znati pravilan redosled.

• Kratku ili delimično otkrivenu seed frazu možda je lakše napasti.

• Podela možda nije kompatibilna sa softverom novčanika.

• Ne postoji standardizovan postupak oporavka.

BIP39 definiše kako se mnemonička fraza pretvara u seed materijal za deterministički novčanik. Ne definiše bezbedan način da se ta fraza iseče na fragmente za nasleđivanje.

Koristite priznati standard za kriptografsku podelu tajne ili izvorna multisig pravila.

Opcija A: Podela tajne zasnovana na standardu

U pravilnim sistemima podeljenog znanja tajna se matematički deli na više delova. Manji broj delova od propisanog praga ne bi trebalo da otkrije nikakve korisne informacije o ključu koji se rekonstruiše.

SLIP39 je jedna implementacija ovog koncepta prilagođena novčanicima. Omogućava pravljenje više delova za oporavak u obliku reči i određivanje broja potrebnog za oporavak. Postavka 2 od 3 pravi tri dela, od kojih bilo koja dva mogu da oporave novčanik. Jedan deo nije dovoljan.

SLIP39 se razlikuje od BIP39. Novčanik koji podržava standardnu BIP39 frazu od 12 ili 24 reči ne mora nužno da podržava SLIP39 delove. Eksplicitno evidentirajte standard i proverite kompatibilnost sa hardverom za oporavak.

Uobičajene postavke praga obuhvataju:

Za mnoga domaćinstva postavka 2 od 3 predstavlja najbolju ravnotežu između mogućnosti oporavka i složenosti. Postavka 3 od 5 može biti primerena kada je portfelj dovoljno veliki da opravda više mesta čuvanja i više učesnika.

Izbegavajte pragove koji zahtevaju svaki deo. Plan 3 od 3 može delovati bezbedno, ali gubitak samo jednog dela čini novčanik nepopravljivo nedostupnim.

Praktična raspodela po modelu 2 od 3

Jedan od mogućih modela izgleda ovako:

• Deo A nalazi se na bezbednom mestu pod kontrolom vlasnika, uz dokumentovan pravni put kojim izvršilac testamenta može da mu pristupi

• Deo B čuva advokat, profesionalni čuvar dokumenata ili drugo nezavisno lice, u skladu sa pisanim pravilima predaje

• Deo C nalazi se na geografski odvojenom bezbednom mestu ili kod drugog pouzdanog čuvara

Mesta čuvanja ne treba da budu izložena istom požaru, poplavi, provali ili riziku vezanom za jedno domaćinstvo.

Ako se koristi sef u banci, proverite kako će izvršilac testamenta ili nasledni poverenik trasta moći da mu pristupi. Pravila pristupa se razlikuju, a kašnjenje ostavinskog postupka može učiniti bankarski sef neprikladnim kao jedinu putanju za oporavak.

Struktura 2 od 3 i dalje omogućava bilo kojim dvama čuvarima delova da se dogovore i zloupotrebe pristup. Sistem podele tajne ne zna da li je vlasnik živ niti da li je oporavak pravno odobren.

Kod portfelja sa većim rizikom razmotrite:

• Prag 3 od 5

• Institucionalno čuvanje dokumenata

• Pisane uslove predaje

• Ambalažu koja pokazuje pokušaj otvaranja i evidenciju pregleda

• Multisig čuvanje

• Profesionalno povereno lice

• Regulisanog pružaoca usluge čuvanja za deo imovine ili celokupnu imovinu

Nemojte se oslanjati samo na to da čuvari delova ne znaju jedni za druge. To može da smanji oportunistički rizik, ali nije zamena za kvalitetne kontrole.

Obeležite delove bez reklamiranja portfelja

Svaki deo treba da sadrži dovoljno informacija da se spreči zabuna:

• Oznaku plana

• Broj dela

• Prag za oporavak

• Standard rezervne kopije

• Datum izrade

• Uputstvo da deo nikada ne sme da se fotografiše niti unosi u telefon ili računar

Ne treba da prikazuje:

• Potpun inventar imovine vlasnika

• Približnu vrednost novčanika

• Sva druga mesta čuvanja

• Imena svih čuvara delova

• Dodatnu frazu

• Javnu adresu koja otkriva portfelj

Papir može biti dovoljan ako se čuva u profesionalno zaštićenom prostoru. Izdržljiv metal može da poboljša otpornost na požar, vodu i fizičko propadanje.

Metal povećava trajnost, ali ne kontroliše pristup. Zakopana metalna ploča i dalje može da bude ukradena, zaboravljena, pronađena tokom građevinskih radova, oštećena ili pravno nedostupna.

Migracija postojećeg novčanika

Nemojte postavljati postojeću BIP39 frazu na internet servis koji nudi „deljenje seed fraze”.

Ako trenutni novčanik izvorno ne podržava izabrani standard praga, bezbedniji postupak obično izgleda ovako:

1. Napravite novi novčanik na kompatibilnom hardverskom uređaju.

2. Generišite delove sa pragom direktno na uređaju.

3. Proverite delove.

4. Pošaljite mali probni iznos u novi novčanik.

5. Oporavite novčanik na drugom kompatibilnom uređaju.

6. Potvrdite da se prikazuje ista proverena adresa.

7. Pošaljite probni iznos iz novčanika.

8. Tek tada prenesite glavni iznos.

Neki uređaji nude dokumentovane metode za pravljenje ili menjanje formata rezervne kopije neposredno na uređaju. Ako koristite takvu funkciju, proverite šta se dešava sa starom rezervnom kopijom.

Stara seed fraza može i nakon pravljenja novih delova ostati sposobna da oporavi novčanik. Ne treba je uništavati dok nova putanja oporavka ne bude potpuno testirana, ali je ne treba ni zaboraviti kao nenadgledanu mogućnost pristupa.

Napravite hardversku putanju oporavka

Plan nasleđivanja ne treba da zavisi od toga da li će originalni hardverski novčanik preživeti.

Hardver se kvari. Baterije propadaju. Ekrani pucaju. Kablovi nestaju. Firmver se menja. Kompanije prestaju da podržavaju stare uređaje.

Trajna osnova za oporavak jeste standardizovana rezervna kopija sa odgovarajućim metapodacima, a ne originalni uređaj.

Plan treba da navede:

• Porodicu kompatibilnih hardverskih novčanika

• Standard rezervne kopije

• Zvaničan izvor softvera

• Da li se reči za oporavak unose direktno na uređaju

• Vrstu naloga ili podatke o derivaciji

• Način provere prve adrese za prijem

• Način nabavke zamenskog uređaja

• Način sprovođenja probnog oporavka

• Postupak u slučaju oštećenja originalnog uređaja

Reči za oporavak treba unositi direktno u pouzdan hardverski uređaj, a ne u običan računar, obrazac u internet pregledaču, telefon, dokument u oblaku ili razgovor sa korisničkom podrškom.

Fraza za oporavak daje potpun pristup novčaniku. Nikada ne treba da bude sačuvana u digitalnom obliku niti dostavljena zaposlenima u korisničkoj podršci.

Aktivni hardverski novčanik i delovi za oporavak ne treba da budu na istom mestu. Osoba koja ukrade uređaj ne treba istovremeno da dobije materijal potreban za njegov oporavak ili zaobilaženje zaštite.

Rezervni hardverski uređaj može biti koristan, ali ne treba da ostane inicijalizovan aktivnim novčanikom, osim ako je ta dodatna kopija ključa namerno i odgovarajuće zaštićena. Neinicijalizovan rezervni uređaj, ili uređaj koji se koristi za testiranje pa zatim briše, stvara manju izloženost tokom života vlasnika.

Proverite rezervnu kopiju pre čuvanja imovine

Fraza koja nikada nije testirana nije rezervna kopija. Ona je samo pretpostavka.

Koristite:

• Postupak za proveru rezervne kopije koji obezbeđuje proizvođač

• Test oporavka na drugom kompatibilnom uređaju

• Poseban probni novčanik napravljen istim postupkom

Nemojte brisati jedini funkcionalni uređaj dok materijal za oporavak ne bude proveren.

Proveru rezervne kopije ili probni oporavak treba završiti pre oslanjanja na zapisani materijal za oporavak ili sprovođenja operacije koja može da resetuje uređaj.

Tretirajte dodatne fraze kao naprednu funkciju

Opciona BIP39 dodatna fraza, odnosno passphrase, pravi zaseban novčanik iz iste osnovne fraze za oporavak. Ona nije nužno doslovna „25. reč”, a svako veliko i malo slovo, razmak i znak imaju značaj.

Pogrešna dodatna fraza može da otvori važeći, ali potpuno drugačiji novčanik. Softver može da prikaže prazan novčanik umesto poruke o grešci. Ako se dodatna fraza izgubi, sama seed fraza možda neće moći da oporavi željenu imovinu.

Za plan nasleđivanja namenjen osobama bez tehničkog znanja, rezervna kopija sa pragom zasnovana na standardu često je bezbednija od dodavanja passphrase-a.

Ako dodatna fraza već postoji:

• Evidentirajte njeno postojanje u mapi imovine.

• Čuvajte njen tačan sadržaj kao zaseban zaštićeni faktor.

• Nemojte se oslanjati na nejasan nagoveštaj.

• Sačuvajte tačnu upotrebu velikih i malih slova, interpunkcije, razmaka i rasporeda tastature.

• Testirajte potpuni oporavak pomoću seed fraze i dodatne fraze.

• Obezbedite da učesnici u postupku nasleđivanja mogu da dođu do obe komponente.

• Imajte u vidu da dodatna fraza postaje zasebna jedinstvena tačka otkaza ako i sama nije zaštićena redundantno.

Opcija B: Multisig

Multisig, odnosno višestruki potpis, nije isto što i podela tajne.

Kod podele tajne više delova rekonstruiše jednu glavnu tajnu. Kada se ona rekonstruiše, taj jedan ključ može da potpisuje transakcije.

Kod multisig sistema nezavisni ključevi potpisuju transakcije u skladu sa pravilima na blokčejnu ili pametnom nalogu. Novčanik 2 od 3 zahteva važeće potpise dva od tri odvojena potpisnika. Ključevi ne moraju da se spajaju.

Bitcoin multisig može biti veoma otporan, ali pojedinačne seed fraze nisu kompletna rezervna kopija. Novčaniku će možda biti potreban i potpun deskriptor ili ekvivalentna konfiguracija, uključujući javne ključeve, otiske ključeva, tip skripte, prag i podatke o derivaciji.

Obnavljanje multisig novčanika zahteva i odgovarajuće rezervne kopije privatnih ključeva i deskriptor novčanika ili ekvivalentne podatke o supotpisnicima.

Naslednik koji ima dve od tri seed fraze, ali nema odgovarajuću multisig konfiguraciju, možda neće moći da pronađe ili potroši sredstva.

Multisig pametni ugovori i novčanici za društveni oporavak mogu da podrže pravila nasleđivanja na programabilnim mrežama. Oni takođe dodaju zavisnosti od ugovora, nadogradnji, staratelja, releja i aplikacija. Treba ih koristiti samo kada porodica ima dokumentovan put do podrške i kada su ugovori široko pregledani i provereni.

Za osobu koja nije programer i ima imovinu na više mreža, standardizovani hardverski delovi za oporavak mogu biti jednostavniji. Za Bitcoin portfelj velike vrednosti, profesionalno podešen multisig može da pruži snažnije razdvajanje ovlašćenja.

Korak 3: Napišite operativno uputstvo koje ne pretpostavlja poznavanje kripta

Tehnički ispravna rezervna kopija i dalje može da zakaže ako porodica ne zna šta je ona, gde da je pronađe ili kako da je bezbedno upotrebi.

Paket uputstava treba da bude napisan za osobu koja nikada nije koristila hardverski novčanik.

Na prvoj strani treba da se nalaze pravila za vanredne situacije, a ne tehnička teorija.

Uputstva na prvoj strani

1. Ne unosite reči za oporavak u telefon, računar, internet stranicu, dodatak za pregledač, imejl ili čet.

2. Ne fotografišite, skenirajte, fotokopirajte, diktirajte niti čitajte reči za oporavak naglas.

3. Ne pokušavajte više puta da pogodite PIN hardverskog novčanika.

4. Ne resetujte, brišite niti ažurirajte originalni uređaj.

5. Ne odgovarajte na direktne poruke osoba koje nude oporavak novčanika.

6. Ne objavljujte javno podatke o imovini.

7. Obratite se imenovanom izvršiocu testamenta ili naslednom povereniku trasta.

8. Obratite se imenovanom advokatu i tehničkom operateru koristeći odštampane kontakt podatke.

9. Ne premeštajte imovinu dok se ne potvrde pravno ovlašćenje i plan odredišta.

10. Nikada ne dozvolite jednom spoljnom tehničaru da samostalno radi sa dovoljno materijala za kontrolu novčanika.

Ova pravila odnose se na period najvećeg rizika: dane nakon smrti, kada naslednici tuguju, uređaji se prikupljaju, a prevaranti možda već prate javne spise ili čitulje.

Šta kompletno operativno uputstvo treba da sadrži

Identitet i ovlašćenje

• Ime izvršioca testamenta ili naslednog poverenika trasta

• Ime rezervnog poverenog lica

• Kontakt podatke advokata

• Kontakt podatke tehničkog operatera

• Kontakt podatke poreskog stručnjaka

• Dokumenta potrebna pre oporavka

• Podatak o tome ko sme da odobri prenos

Pronalaženje imovine

• Inventar novčanika i naloga

• Mreže koje se koriste

• Javne adrese

• Kastodijalne pružaoce usluga

• Hardverske uređaje

• Pozicije u protokolima

• Podatke o stakingu ili periodima zaključavanja

• Neizmirene dugove obezbeđene kolateralom

• Lokaciju poreske i transakcione evidencije

Arhitekturu oporavka

• Standard rezervne kopije

• Broj delova

• Prag za oporavak

• Lokacije delova

• Uslove predaje

• Kompatibilni hardver

• Podatak o tome da li dodatna fraza postoji

• Lokaciju multisig deskriptora ili konfiguracije pametnog naloga

Pravila za odredište

• Da li imovinu treba preneti u naturi, likvidirati ili premestiti kod profesionalnog pružaoca usluge čuvanja

• Ko može da odobri odredišnu adresu

• Da li treba otvoriti račun zaostavštine ili trasta

• Da li naslednik mora da napravi novi hardverski novčanik

• Kako se postupa u slučaju maloletnika, trastova ili korisnika sa posebnim potrebama

• Koliku slobodu odlučivanja povereno lice ima tokom tržišne volatilnosti

Postupak transakcije

• Način provere odredišne adrese

• Mrežu koja treba da se koristi

• Da li je potreban memo ili odredišna oznaka

• Izvorni token koji se koristi za plaćanje mrežnih naknada

• Najveći dozvoljeni iznos probnog prenosa

• Koliko treba čekati pre slanja preostalog iznosa

• Koju evidenciju treba sačuvati

Bezbednosni postupak

• Telefoni i kamere ostaju van prostorije za oporavak

• Nema softvera za daljinski pristup

• Nema deljenja ekrana

• Ne koriste se sponzorisani rezultati pretrage

• Seed fraza se ne unosi u softverske novčanike, osim ako plan to izričito zahteva

• Oporavku i prenosu prisustvuju najmanje dve osobe

• Odredišne adrese proveravaju se nezavisno

• Vodi se pisana evidencija transakcija

Operativno uputstvo treba da koristi jednostavan jezik. Nemojte napisati: „Obnovite HD novčanik i prenesite sve UTXO izlaze.” Navedite tačne radnje koje će izvršilac testamenta videti na ekranu, ko mora da bude prisutan i u kom trenutku postupak mora da se zaustavi radi stručne provere.

Imenujte tehničkog operatera, ali ograničite njegova ovlašćenja

Tehnički operater može da pomogne izvršiocu testamenta da:

• Identifikuje odgovarajući hardver

• Instalira zvanični softver novčanika

• Potvrdi standard rezervne kopije

• Rekonstruiše novčanik na bezbednom uređaju

• Pronađe naloge i mreže

• Pripremi podatke za nepotpisanu transakciju

• Proveri zahteve za mrežne naknade

• Evidentira identifikatore transakcija

Operater ne treba da:

• Odnosi delove za oporavak kući

• Fotografише delove

• Samostalno radi sa oporavljenim novčanikom

• Bira naslednike

• Odlučuje da li će imovina biti likvidirana

• Zameni odredišnu adresu svojom ličnom adresom

• Zadrži inicijalizovan uređaj nakon završetka postupka

• Zahteva plaćanje na neproverenu adresu

Povereno lice ostaje donosilac pravnih odluka. Operater je tehnički pomoćnik čiji rad mora biti kontrolisan.

Uvežbajte plan

Plan nasleđivanja treba testirati na tri nivoa.

Pregled dokumentacije

Potvrdite da su imena, brojevi telefona, mesta čuvanja, aplikacije novčanika, adrese i podaci o uređajima i dalje aktuelni.

Simulacija postupka

Vlasnik, povereno lice i tehnički operater zajedno prolaze kroz proceduru bez sastavljanja potrebnog broja delova za oporavak.

Tehnički test oporavka

Pomoću kompatibilnog hardverskog uređaja proverite da li propisani broj delova oporavlja očekivanu prvu adresu za prijem i mali probni iznos.

Pregledajte plan nakon:

• Promene hardverskog novčanika

• Preseljenja na novu adresu

• Pravljenja nove seed fraze

• Dodavanja passphrase-a

• Promene praga za oporavak

• Otvaranja ili zatvaranja naloga na berzi

• Ulaska u novu staking ili DeFi poziciju

• Promene izvršioca testamenta, poverenika, advokata ili naslednika

• Premeštanja dela na novu lokaciju

• Značajne promene softvera novčanika

Svaki paket treba da sadrži broj verzije i datum poslednjeg pregleda. Zastarele kopije treba povući ili jasno označiti kao opozvane, kako naslednici ne bi pratili protivrečna uputstva.

Korak 4: Sprovedite kontrolisan prenos ili likvidaciju

Nakon smrti cilj nije da se novčanik preminulog vlasnika koristi neograničeno dugo. Kada se materijal za oporavak sastavi i više osoba učestvuje u procesu, originalni novčanik treba smatrati potencijalno izloženim.

Zaostavština treba da prenese imovinu na nove ključeve, kroz kontrolisan i dokumentovan postupak.

1. Potvrdite pravno ovlašćenje

Pre premeštanja imovine utvrdite ko ima zakonsko ovlašćenje da postupa.

U zavisnosti od strukture, to može biti:

• Izvršilac testamenta ili zastupnik zaostavštine koga je imenovao sud

• Nasledni poverenik trasta

• Drugo ovlašćeno povereno lice

• Osoba koja postupa prema pravilima konkretne jurisdikcije za zaostavštine male vrednosti

Posedovanje seed fraze samo po sebi ne ovlašćuje osobu da raspodeljuje imovinu iz zaostavštine. Izvršilac testamenta ili poverenik može imati obaveze prema poveriocima, poreskim organima, naslednicima i sudu.

2. Obezbedite fizički materijal

Prikupite i zaštitite:

• Hardverske novčanike

• Koverte sa delovima za oporavak

• Računare i telefone

• Odštampanu evidenciju o novčanicima

• Izvode sa berzi

• Uputstva za menadžer lozinki

• Poresku dokumentaciju

• Multisig deskriptore

• Evidenciju o pametnim nalozima

Ne uključujte, ne ažurirajte i ne resetujte originalni hardver dok ne utvrdite stanje rezervne kopije.

3. Popišite i evidentirajte stanje zaostavštine

Pre prenosa evidentirajte:

• Datum i vreme

• Adrese novčanika

• Vrste i količine imovine

• Mreže

• Relevantne pozicije u protokolima

• Neizmirene dugove ili kolateral

• Staking nagrade koje još nisu primljene

• Istoriju transakcija

• Dostupne podatke o nabavnoj vrednosti i sticanju

• Izvor vrednovanja koji je izabrao poreski stručnjak

Poreski obveznici moraju da čuvaju evidenciju dovoljnu za dokazivanje podataka navedenih u poreskim prijavama. Ona može da obuhvati potvrde o digitalnoj imovini, prodaje, zamene, raspolaganja, prenose, fer tržišnu vrednost i poresku osnovicu.

Nemojte pretpostaviti da će berza ili blokčejn pretraživač pružiti potpunu evidenciju o nabavnoj vrednosti. Sačuvajte originalne datoteke sa transakcijama preminulog vlasnika, podatke izvezene sa berzi, istoriju novčanika i prethodnu poresku dokumentaciju.

4. Pripremite odredište pre oporavka novčanika

Odredište treba uspostaviti i nezavisno proveriti pre sastavljanja delova tajne.

Moguća odredišta obuhvataju:

• Privremeni novčanik pod kontrolom zaostavštine ili trasta

• Nalog kod regulisanog pružaoca usluge čuvanja, otvoren za zaostavštinu ili trast

• Novi hardverski novčanik pod kontrolom naslednika

• Ovlašćeni nalog na berzi koji se koristi za likvidaciju

• Profesionalno vođenu multisig strukturu

Odredišna adresa treba da bude potvrđena na ekranu odgovarajućeg hardverskog uređaja ili drugim pouzdanim metodom. Dve osobe treba da uporede kompletnu adresu, mrežu i svaki potreban memo ili odredišnu oznaku.

Nemojte se oslanjati na adresu kopiranu iz imejla. Zlonamerni softver koji menja sadržaj clipboarda i kompromitovani nalozi za razmenu poruka mogu da podmetnu adresu napadača.

5. Sprovedite oporavak uz prisustvo dve osobe

Koristite:

• Privatnu prostoriju bez kamera

• Pouzdan, potpuno ažuriran računar bez nepotrebnog softvera

• Zvanični softver novčanika preuzet iz proverenog izvora

• Nov ili pouzdan hardverski uređaj

• Najmanji potreban broj ovlašćenih učesnika

• Pisanu evidenciju događaja

Ažurirajte prazan zamenski uređaj pre unošenja materijala za oporavak. Ako koristite originalni uređaj, izbegavajte promene firmvera dok rezervna kopija ne bude proverena.

Reči za oporavak unesite direktno na hardverskom uređaju. Nakon oporavka:

1. Postavite novi PIN uređaja.

2. Otvorite dokumentovanu aplikaciju novčanika.

3. Omogućite potrebne mreže.

4. Potvrdite očekivanu prvu adresu.

5. Uporedite stanje sa podacima na blokčejnu.

6. Razrešite sva odstupanja pre potpisivanja bilo čega.

Ako se očekivana adresa ne pojavi, zaustavite postupak. Uzrok može biti:

• Pogrešna dodatna fraza

• Pogrešna rezervna kopija

• Drugi broj naloga

• Druga derivaciona putanja

• Nepodržana mreža

• Nedostajuća multisig konfiguracija

• Pogrešna aplikacija novčanika

• Neotkriveni pametni nalog ili pozicija u protokolu

Nemojte nasumično isprobavati različita podešavanja dok je kompletna tajna za oporavak izložena.

6. Pošaljite probnu transakciju

Za svaku relevantnu mrežu:

1. Proverite odredišnu adresu na prijemnom hardverskom uređaju.

2. Potvrdite mrežu.

3. Potvrdite da li je potreban memo ili odredišna oznaka.

4. Ostavite dovoljno izvorne valute za mrežne naknade.

5. Pošaljite mali probni iznos.

6. Sačekajte odgovarajući broj potvrda.

7. Potvrdite prijem sa odredišne strane.

8. Evidentirajte identifikator transakcije.

Uspešan test na jednoj mreži ne dokazuje da je druga mreža ili prenos drugog tokena pravilno podešen.

Tokom nasleđivanja izbegavajte nepotrebne mostove, zamene, interakcije sa ugovorima ili uvoz novčanika. Svaka dodatna radnja predstavlja novi mogući izvor greške i novi događaj koji može zahtevati poresku evidenciju.

7. Prenesite, likvidirajte ili premestite imovinu kod profesionalnog čuvara

Plan zaostavštine treba da izrazi želje vlasnika, ali i da poverenom licu ostavi dovoljno slobode da reaguje na:

• Volatilnost

• Tržišnu likvidnost

• Zagušenje mreže

• Ograničenja berzi

• Sposobnost naslednika da bezbedno čuva imovinu

• Poreske zahteve

• Rizike čuvanja

• Sudske rokove

• Zaključavanja u protokolima

• Vanredne bezbednosne okolnosti

Kod prenosa u naturi naslednik treba da primi imovinu na novoj, posebno generisanoj adresi. Oporavljeni novčanik preminulog vlasnika ne treba da postane trajni novčanik naslednika.

Kod likvidacije povereno lice treba, kada je moguće, da koristi pravilno otvoren i ovlašćen nalog na ime zaostavštine ili trasta, umesto da imovinu usmerava preko ličnog naloga naslednika na berzi.

Kod prenosa profesionalnom pružaocu usluge čuvanja, povereno lice treba da proveri:

• Ko je pravni vlasnik naloga

• Pravila povlačenja sredstava

• Mogućnosti imenovanja naslednika ili naslednog ovlašćenog lica

• Tvrdnje i uslove u vezi sa osiguranjem

• Podržane vrste imovine i mreže

• Naknade

• Geografska ograničenja

• Mogućnosti čuvanja evidencije

8. Zaključite postupak oporavka

Nakon svih odobrenih prenosa:

• Sačuvajte identifikatore transakcija.

• Sačuvajte potvrde o trgovini sa berze.

• Evidentirajte mrežne naknade i naknade za usluge.

• Uskladite završno stanje.

• Pratite stare adrese zbog eventualnih kasnijih uplata.

• Zadržite pristup samo za praćenje kada je to korisno.

• Obrišite privremene uređaje za oporavak koji neće ostati u upotrebi.

• Vratite neupotrebljene delove tajne na kontrolisana mesta čuvanja.

• Zadržite originalni materijal za oporavak dok povereno lice i advokat ne potvrde da nema dodatne imovine, povraćaja sredstava, nagrada ili potraživanja.

• Dokumentujte eventualno uništenje zastarelog materijala za oporavak.

Oporavljeni novčanik treba smatrati potencijalno kompromitovanim nakon postupka, čak i kada se svim učesnicima veruje. Više osoba je posmatralo proces, uređaji su povezivani, a delovi tajne su doneti na isto mesto.

Premeštanje na nove ključeve ponovo uspostavlja manji bezbednosni perimetar.

Izbor odgovarajuće arhitekture

Najbezbednija arhitektura nije uvek i najsloženija. Složenost je i sama izvor rizika od gubitka.

Za novčanik vredan nekoliko stotina USD ili EUR skupo institucionalno rešenje može biti nesrazmerno. Jednostavna, testirana hardverska rezervna kopija i precizan paket uputstava mogu biti bezbedniji od složene šeme koju niko ne uvežbava.

Kako vrednost portfelja raste, troškovi stručnog pravnog pregleda, nezavisnog čuvanja ključeva, multisig sistema ili profesionalnog čuvanja postaju lakše opravdani.

Vrednost nije jedini faktor. Važna je i složenost. Skroman novčanik sa imovinom na nekoliko mreža, u pametnim ugovorima i staking sistemima može da zahteva detaljniji plan od većeg novčanika koji sadrži samo jednu jednostavnu vrstu imovine.

Operativni troškovi i kompromisi

Kvalitetan plan nasleđivanja ima i finansijske i administrativne troškove.

Skriveni trošak je održavanje. Plan postaje opasan kada opisuje novčanik, uređaj, advokata ili mesto čuvanja koji više ne postoje.

Dobar sistem svodi broj zavisnosti na najmanju moguću meru, uz dovoljno redundantnosti da preživi jedan uobičajeni kvar ili gubitak.

Uobičajene greške pri nasleđivanju kripto-imovine

Stavljanje seed fraze u testament

Time se ostavinski spis može pretvoriti u sredstvo za krađu. Testament treba da uspostavi ovlašćenje, a ne da sadrži podatke koji svakom posedniku daju kontrolu nad imovinom.

Davanje kompletne seed fraze jednom nasledniku unapred

To pojednostavljuje nasleđivanje tako što žrtvuje bezbednost tokom života vlasnika. Telefon, dom, odnosi i finansijski pritisci naslednika postaju deo modela pretnji vlasnika.

Deljenje BIP39 fraze na grupe reči

To nije podela tajne zasnovana na standardu. Stvara nejasnoće, slabi redundantnost i može da proizvede plan koji nije moguće oporaviti.

Čuvanje svih delova u istoj zgradi

Tri koverte u jednom domu predstavljaju tri kopije izložene istom požaru, poplavi, provali ili slučajnom bacanju.

Zahtevanje svih delova

Plan 3 od 3 nema toleranciju na gubitak. Jedna izgubljena koverta trajno zaključava novčanik.

Čuvanje uređaja i rezervne kopije zajedno

Ukradeni sef, torba ili kutija sa dokumentima mogu napadaču da obezbede i hardver i mehanizam za njegov oporavak.

Tretiranje hardverskog PIN-a kao plana nasleđivanja

PIN može da obezbedi jednostavan pristup trenutnom uređaju, ali ne može da oporavi pokvaren, obrisan ili zastareo uređaj.

Zaboravljanje dodatne fraze

Ispravna seed fraza sa nedostajućim passphrase-om može da oporavi drugi novčanik. Svaki znak mora da bude sačuvan i testiran.

Čuvanje multisig seed fraza bez konfiguracije

Za multisig oporavak mogu biti potrebni deskriptor, javni ključevi supotpisnika, prag, tip skripte, otisci ključeva i podaci o derivaciji.

Čuvanje glavne seed fraze u imejlu ili običnom skladištu u oblaku

Šifrovanje može da smanji rizik, ali dodaje zavisnosti od oporavka naloga, pružaoca usluge, zlonamernog softvera, pristupnih podataka i ključa za dešifrovanje.

Naslednik bez tehničkog znanja ne bi trebalo prvo da savlada digitalni bezbednosni sistem kako bi zatim mogao da koristi hardverski bezbednosni sistem.

Korišćenje automatizovanog prekidača za objavljivanje ključa

Neaktivnost nije smrt. Lažna aktiviranja i izostanak aktiviranja neizbežni su kada sistem nema pouzdan postupak za potvrdu smrti.

Neidentifikovanje mreže

Sam naziv tokena ne govori izvršiocu testamenta gde se imovina nalazi niti koja je valuta potrebna za plaćanje naknada.

Zanemarivanje stakinga, pozajmljivanja i kolaterala

Stanje novčanika možda ne prikazuje imovinu uloženu u protokol, zaključanu u ugovoru, delegiranu ili upotrebljenu kao obezbeđenje duga.

Premeštanje svega bez probne transakcije

Blokčejn prenosi uglavnom su nepovratni. Mali test može da otkrije pogrešnu mrežu, adresu, memo, novčanik ili konfiguraciju čuvanja pre nego što cela zaostavština bude ugrožena.

Dozvoljavanje internet „stručnjaku za oporavak” da radi sam

Tehničar koji vidi kompletnu seed frazu može kasnije ponovo da napravi novčanik. Oporavak treba sprovoditi uz kontrolu dve osobe i neposredan unos na hardverskom uređaju.

Neažuriranje plana

Savršen plan za novčanik koji je ispražnjen pre tri godine beskoristan je. Svaka migracija novčanika mora da pokrene pregled plana nasleđivanja.

Kontrolna lista za vlasnika

Koristite ovu listu da protokol pretvorite u operativan plan:

• [ ] Odredite izvršioca testamenta, naslednog poverenika trasta, rezervno povereno lice i naslednike.

• [ ] Odredite tehničkog operatera koji može da pomogne bez preuzimanja pravnih odluka.

• [ ] Zatražite od lokalnog advokata da uredi ovlašćenja za pristup digitalnoj imovini, upravljanje, angažovanje stručnjaka, prenos i likvidaciju.

• [ ] Uklonite svaki privatni ključ, seed frazu, dodatnu frazu i PIN iz testamenta.

• [ ] Napravite potpun inventar imovine prema mreži, adresi, novčaniku, vrsti čuvanja i poziciji u protokolu.

• [ ] Evidentirajte softver novčanika, porodicu hardverskog uređaja, standard rezervne kopije i konfiguraciju naloga.

• [ ] Odlučite da li trenutni novčanik treba da ostane sa jednim potpisnikom, koristi podelu tajne ili pređe na multisig.

• [ ] Ako koristite delove za oporavak, izaberite prag tolerantan na gubitak, kao što je 2 od 3 ili 3 od 5.

• [ ] Generišite delove pomoću dokumentovanog hardverskog postupka ili standardizovanog sistema.

• [ ] Čuvajte delove na nezavisnim fizičkim lokacijama.

• [ ] Dokumentujte kako izvršilac testamenta može legalno da pribavi potreban broj delova.

• [ ] Držite aktivni uređaj odvojeno od materijala za oporavak.

• [ ] Testirajte oporavak na kompatibilnom hardverskom uređaju.

• [ ] Proverite očekivanu prvu adresu za prijem.

• [ ] Pošaljite i prenesite mali probni iznos pre premeštanja glavnog portfelja.

• [ ] Napišite kontrolnu listu za vanredne situacije na prvoj strani, namenjenu naslednicima bez tehničkog znanja.

• [ ] Dokumentujte odredište, probni prenos i postupke provere uz prisustvo dve osobe.

• [ ] Sačuvajte podatke o sticanju, transakcijama, vrednovanju i porezima.

• [ ] Sprovedite simulaciju postupka.

• [ ] Navedite datum i broj verzije na svakoj kopiji plana.

• [ ] Pregledajte plan nakon svake značajne promene novčanika, pravnog statusa, porodice ili načina čuvanja.

• [ ] Zakažite redovan pregled čak i kada deluje da se ništa nije promenilo.

Osnovno načelo

Nasleđivanje kripto-imovine ne treba da zavisi od objavljivanja privatnog ključa nakon smrti. Treba da zavisi od kontrolisanog postupka koji ovlašćene osobe mogu da sprovedu bez nagađanja.

Testament ili trast odgovara na pitanje ko ima ovlašćenje.

Mapa imovine odgovara na pitanje šta postoji.

Oporavak zasnovan na pragu odgovara na pitanje kako pristup može da se rekonstruiše bez jedne ranjive glavne kopije.

Operativno uputstvo za naslednike odgovara na pitanje kojim redosledom treba obaviti posao.

Postupak prenosa odgovara na pitanje gde imovina odlazi i kako zaostavština dokumentuje rezultat.

To razdvajanje je ono što tradicionalno planiranje nasleđivanja najčešće propušta. Pravni dokument bez oporavka ključeva stvara vlasništvo bez pristupa. Seed fraza bez pravnih uputstava stvara pristup bez ovlašćenja.

Bezbedan plan nasleđivanja povezuje obe strane, dok tajne drži van ostavinskih spisa, tajmera u oblaku i improvizovanih porodičnih postupaka.

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti i prodati USDT i USDC. Više informacija nalazi se na stranici Volet za korisnike iz Srbije. Za otvaranje naloga koristi Volet referral link. Link je referral link autora članka.

Izvori

1. Njujorški sudovi: ostavinski postupak kada osoba umre sa testamentom

2. Pravosudni sistem Masačusetsa: pristup javnim spisima Suda za ostavinske i porodične predmete

3. Pravosudni sistem Kalifornije: javni spisi

4. Komisija za jednoobrazne zakone: Revidirani jedinstveni zakon o fiducijarnom pristupu digitalnoj imovini

5. NIST: podeljeno znanje

6. NIST SP 800-57, deo 1, revizija 5: preporuka za upravljanje ključevima

7. Bitcoin predlog za unapređenje 39: mnemonički kod za generisanje determinističkih ključeva

8. SatoshiLabs predlog za unapređenje 39: Šamirova podela tajne za mnemoničke kodove

9. Trezor: šta je Shamir Backup?

10. Trezor: kako koristiti rezervnu kopiju novčanika

11. Trezor: rešavanje problema sa rezervnom kopijom i oporavkom novčanika

12. Trezor: korišćenje novčanika sa dodatnom frazom

13. Bitcoin predlog za unapređenje 380: opšte funkcionisanje deskriptora izlaznih skripti

14. Pomoć za Google naloge: o Menadžeru neaktivnih naloga

15. Ethereum: apstrakcija naloga

16. Ethereum: bezbednost pametnih ugovora

17. Ethereum: bezbednost i sprečavanje prevara

18. Američka poreska uprava: digitalna imovina

19. Volet Srbija

English version: Read on Dev.to: Crypto Inheritance: What Happens to Wallets at Death?

To je razlika između tržišne vrednosti koju korisnik daje i tržišne vrednosti koju dobije nakon trgovine.

Novčanik može sasvim tačno da navede da njegova naknada za zamenu iznosi 0,875%, dok korisnik trgovinu vrednu 1.000 USD završi sa 35 do 70 USD manje ekonomske vrednosti. Ta razlika ne mora da bude tajna naknada. Obično nastaje zato što se nekoliko troškova prikazuje odvojeno, ugrađuje u kurs ili izostavlja iz istaknutog procenta.

Ta razlika je važna.

Korisnici ne gube nužno od 3% do 7% pri svakoj zameni unutar novčanika. Trgovina na likvidnom tržištu i jeftinoj mreži može da košta znatno manje. Međutim, trošak od 3% do 7% postaje potpuno moguć kada se u istoj transakciji pojave naknada novčanika, uticaj na cenu, mrežni trošak, naknada za most i nepovoljno izvršenje.

Naknada je ono što proizvod naplaćuje.

Trošak je ono što korisnik izgubi.

Naknada nije isto što i trošak

Zamena unutar novčanika je trgovina tokenima pokrenuta iz kripto-novčanika. Novčanik obično traži ponude od decentralizovanih berzi, agregatora, market mejkera ili pružalaca usluga mosta, bira rutu, dodaje eventualnu naknadu novčanika ili integratora i priprema transakciju koju korisnik treba da potpiše.

Novčanik predstavlja interfejs i sloj za rutiranje. On nije nužno izvor likvidnosti.

Zbog toga poređenje samo objavljene naknade novčanika daje nepotpun odgovor.

Korisnija računica glasi:

ukupan gubitak = referentna vrednost ulaza - referentna vrednost izlaza + eksterni troškovi

Eksterni troškovi su izdaci koji se plaćaju izvan ponuđenih iznosa tokena, kao što su gas, transakcija odobrenja ili naknada za povlačenje sredstava sa centralizovane berze.

Pretpostavimo da korisnik prodaje imovinu vrednu 1.000 USD, prima tokene vredne 972 USD po istoj referentnoj tržišnoj ceni i zasebno plaća 9 USD za gas.

Ukupan gubitak iznosi:

1.000 USD - 972 USD + 9 USD = 37 USD

Trošak transakcije iznosio je 3,7%, čak i ako je naknada samog novčanika bila manja od 1%.

Ovde postoji jedna računovodstvena zamka. Ako je naknada već odbijena od ponuđenog izlaznog iznosa, nemojte je dodavati drugi put. Razlika između ulazne i izlazne vrednosti već je sadrži.

Pregled naknada objašnjava gde je vrednost otišla. Poređenje ulazne i izlazne vrednosti govori koliko je ukupno izgubljeno.

Šta zapravo navode aktuelne stranice sa naknadama

Istaknuti brojevi koje objavljuju veliki novčanici i interfejsi za trgovanje nisu direktno uporedivi.

Zbog toga se rasprave o troškovima zamene često vrte ukrug.

Jedna osoba govori o prihodu novčanika. Druga govori o gasu. Treća meri koliko je tokena stiglo. Sve tri mogu da navedu različite procente i da pritom budu u pravu.

MetaMask svoju strukturu troškova opisuje kroz ponuđeni kurs, mrežnu naknadu i MetaMask naknadu od 0,875%.

Phantom navodi da zamena može da uključuje njegovu naknadu od 0,85%, mrežnu naknadu i uticaj na cenu. Kod međulančanih zamena naknada pružaoca usluge mosta može da bude uračunata u uticaj na cenu, umesto da se prikazuje kao posebna stavka.

Uniswap Labs trenutno ne naplaćuje naknadu za interfejs, ali trgovina i dalje može da uključuje naknade pružalaca likvidnosti, uticaj na cenu i mrežni trošak.

Kraken Pro koristi maker-taker raspored naknada. Na početnom nivou objavljena stopa iznosi 0,40% za maker naloge i 0,80% za taker naloge. To ne uključuje trošak prelaska preko raspona između kupovne i prodajne cene u knjizi naloga, niti prebacivanje imovine na berzu i sa nje.

Nijedan od ovih opisa sam po sebi nije obmanjujući. Oni jednostavno opisuju različite slojeve transakcije.

Gde odlazi novac koji nedostaje

Razlika između naknade novčanika manje od 1% i ukupnog gubitka od 3% do 7% obično nastaje kombinovanjem sledećih troškova.

Naknada novčanika

Ovo je trošak koji je najlakše prepoznati.

Kod zamene vredne 1.000 USD:

• MetaMask naknada od 0,875% iznosi 8,75 USD.

• Phantom naknada od 0,85% iznosi 8,50 USD.

Ti iznosi sami po sebi nisu katastrofalni. Problem je u tome što se dodaju troškovima koji bi postojali i bez naknade novčanika.

Ruta novčanika koja naplaćuje 0,875% mora da donese najmanje 8,75 USD kroz bolje rutiranje ili niže troškove izvršenja da bi kod trgovine od 1.000 USD bila bolja od alternative bez naknade.

Naknada pula ili mesta trgovanja

Automatizovani market mejker naplaćuje naknadu pružaoca likvidnosti svaki put kada trgovina prolazi kroz pul. Ako ruta prolazi kroz više pulova, može da obuhvati više od jedne takve naknade.

To ne znači automatski da je ruta sa više koraka lošija.

Ruta od tokena A do tokena C preko tokena B i dalje može da bude jeftinija ako posredni pulovi imaju dublju likvidnost. Važno pitanje nije koliko koraka ruta koristi, već koliki izlazni iznos ostaje nakon naknada pulova, uticaja na cenu i gasa.

Centralizovana berza ima drugačiju strukturu, ali je ekonomski efekat sličan. Umesto plaćanja AMM pulu, taker prelazi preko raspona u knjizi naloga i plaća naknadu za trgovanje.

Odstupanje ponuđenog kursa

Ljudi ovo često nazivaju rasponom rutiranja ili skrivenim rasponom cena, ali to nije standardizovana protokolska naknada.

Bolje ga je razumeti kao neobjašnjenu razliku između nezavisne referentne cene i kursa koji nudi interfejs.

Ta razlika može da obuhvati:

• Naknade pružalaca likvidnosti

• Raspon između kupovne i prodajne cene

• Uticaj na cenu

• Maržu market mejkera

• Troškove pružaoca usluge mosta

• Neefikasnost rute

• Kratkotrajne razlike u cenama između mesta trgovanja

• Troškove gasa ugrađene u ponudu bez potrebe za nativnim gas tokenom

Korisniku nije potrebna savršena oznaka za svaku komponentu. Međutim, interfejs bi trebalo da prikaže ukupnu ekonomsku razliku koja iz njih proizlazi.

Uticaj na cenu

Uticaj na cenu predstavlja pomeranje cene koje izaziva sama trgovina.

Zamena vredna 1.000 USD na dubokom ETH-USDC tržištu može jedva da pomeri cenu. Isti nalog od 1.000 USD može da pomeri cenu tokena sa plitkim pulom za nekoliko procentnih poena.

Zbog toga sama veličina transakcije govori veoma malo. Trgovina mora da se uporedi sa količinom i koncentracijom aktivne likvidnosti koja je dostupna po aktuelnoj ceni.

Uticaj na cenu takođe nije isto što i naknada platforme. Novac ne mora da pripadne novčaniku. To je posledica korišćenja likvidnosti duž krive formiranja cene.

Korisnik ipak gubi vrednost, bez obzira na to ko je prima.

Odstupanje pri izvršenju

Tolerancija odstupanja, odnosno slippage tolerance, nije naknada.

Ako korisnik postavi maksimalno odstupanje na 1%, transakcija neće automatski koštati 1%. To podešavanje definiše najlošije izvršenje koje je korisnik spreman da prihvati pre nego što transakcija ne uspe i bude poništena.

Stvarni ekonomski gubitak predstavlja ostvareno odstupanje, odnosno razliku između očekivanog izlaznog iznosa i iznosa koji je na kraju primljen.

Ova razlika je važna jer mnogi interfejsi prikazuju toleranciju uočljivije od verovatnog troška izvršenja. Korisnik može da protumači taj broj kao naknadu, iako je zapravo reč o zaštitnoj granici.

Visoka tolerancija ipak stvara rizik. Ona proširuje raspon ishoda koje je korisnik pristao da prihvati, uključujući izvršenje po znatno lošijoj ceni.

Mrežni troškovi i troškovi odobrenja

Mrežni troškovi uglavnom ne zavise od veličine trgovine.

Ako zamena zahteva 15 USD za gas, njen procentualni uticaj drastično se menja u zavisnosti od veličine trgovine:

Zbog toga mala zamena na glavnoj mreži Ethereuma može da izgleda apsurdno skupo čak i kada je kurs razuman.

ERC-20 token može da zahteva i odobrenje pre nego što ugovor za zamenu dobije dozvolu da ga potroši. Ako je to odobrenje zasebna transakcija, ono stvara dodatni mrežni trošak.

Odobrenje treba uračunati samo kada je zaista potrebno. Ako je korisnik već dao dovoljno odobrenje za trošenje, dodavanje hipotetičkog troška novog odobrenja preuveličalo bi trošak trenutne transakcije.

Međulančano izvršenje

Međulančana zamena može da sadrži više ekonomskih operacija:

1. Zamenu na izvornom lancu

2. Mrežnu transakciju na izvornom lancu

3. Naknadu pružaoca usluge mosta

4. Izvršenje na odredišnom lancu

5. Još jednu zamenu na odredišnom lancu

6. Opcionu isporuku tokena za gas na odredišnom lancu

Interfejs sve to može da prikaže kao jednu ponudu.

Time se korisničko iskustvo pojednostavljuje, ali se cena teže proverava. U zavisnosti od pružaoca usluge i novčanika, naknada mosta može da se grupiše sa uticajem na cenu, mrežnim troškom ili konačnim kursom.

Izvršenje bez nativnog gas tokena

„Bez gasa” ne znači uvek „bez troška”.

Ponekad novčanik ili druga strana zaista subvencioniše mrežnu naknadu. U drugim slučajevima korisnik plaća podržanim ERC-20 tokenom umesto nativnom imovinom mreže. U sistemima zasnovanim na nameri treća strana koja izvršava nalog može da plati gas na lancu i očekivani trošak uključi u ponuđeni kurs.

Sva tri modela uklanjaju potrebu da korisnik poseduje nativni token za gas. Samo prvi nužno uklanja ekonomski trošak za korisnika.

Za programere je oznaka „nativni token nije potreban” često preciznija od oznake „besplatan gas”.

Zašto su MetaMask zamene toliko skupe?

MetaMask zamena počinje naknadom za uslugu od 0,875%.

To je 87,5 baznih poena pre uračunavanja gasa, naknada pulova, uticaja na cenu ili pomeranja pri izvršenju. Kod transakcije od 1.000 USD to stvara početni minus od 8,75 USD u odnosu na rutu koja ne naplaćuje istu naknadu za interfejs.

MetaMask ipak može da pobedi u poređenju.

On pretražuje više izvora likvidnosti i simulira predložene transakcije. Ako taj proces pronađe rutu sa manjim uticajem na cenu, izbegne skup dodatni korak ili odbaci transakciju koja će verovatno biti neuspešna, ostvarena ušteda može da nadmaši naknadu novčanika.

Izbegavanje neuspešne transakcije takođe ima ekonomsku vrednost. Tradicionalna transakcija na lancu može da potroši gas čak i kada ne uspe.

Međutim, kvalitet rute mora da se meri, a ne da se podrazumeva. Ako MetaMask i direktni DEX vraćaju gotovo identične osnovne rute, dodatnih 0,875% obično će učiniti rutu unutar novčanika skupljom.

Odgovor na pitanje „zašto su MetaMask zamene toliko skupe?” zato nije da MetaMask tajno naplaćuje 4%.

Odgovor je da je vidljivih 0,875% samo jedan sloj transakcije čiji ukupan trošak može da bude nekoliko puta veći.

Šta korisnici podrazumevaju pod „skrivenom naknadom” za Phantom zamene

Phantom navodi naknadu od 0,85% za većinu zamena.

Kod transakcije od 1.000 USD to iznosi 8,50 USD. Trgovina može da uključi i mrežne troškove i uticaj na cenu.

Do zabune češće dolazi kod prikaza međulančanih transakcija. Phantom navodi da naknada pružaoca usluge mosta može da bude uračunata u uticaj na cenu, umesto da se prikaže kao zasebna naknada mosta.

Trošak jeste dokumentovan, ali oznaka i dalje može da iznenadi korisnike.

Neko ko pročita „uticaj na cenu” može razumno da pretpostavi da taj broj meri samo efekat njegovog naloga na AMM pul. Kod međulančane rute taj broj može da predstavlja mnogo više od toga.

Izraz „skrivena naknada za Phantom zamenu” obično opisuje ovaj problem prikazivanja. Naknada novčanika je vidljiva, ali je deo ostalih troškova rute grupisan u šire kategorije.

Bolji interfejs bi odvojio tržišni uticaj od troškova mosta i izvršenja kad god osnovni pružalac usluge pruža dovoljno informacija za takvu podelu.

Da li je zamena unutar novčanika jeftinija od DEX agregatora?

Ponekad jeste, ali ne po pravilu.

Važan detalj je da zamena unutar novčanika i DEX agregator ne pristupaju uvek različitim tržištima. Novčanik u pozadini može da koristi agregator ili sličnu infrastrukturu za rutiranje.

Poređenje se često svodi na:

• Rutu agregatora sa naknadom novčanika

• Direktnu DEX rutu bez naknade novčanika

• Rutu drugog agregatora sa sopstvenom naknadom integratora

• Rutu zasnovanu na nameri, sa gasom uključenim u kurs

Novčanik može da bude jeftiniji ako pronađe znatno bolji put. Može da podeli nalog između više pulova, koristi posredni token, pribavi ponudu market mejkera ili pronađe jeftiniji most.

Međutim, poboljšanje rute mora da bude veće od naknade novčanika i svih dodatnih mrežnih troškova.

Direktni Uniswap nije samo jedan pul. Njegov sistem za rutiranje može da proceni više pulova, verzija protokola, podeljenih ruta, posrednih tokena i mrežnih troškova. Može da odbaci dodatni korak ako očekivano poboljšanje cene ne opravdava dodatni gas.

Ni samostalni agregator nije automatski bez naknade. API servisi kao što je 0x dozvoljavaju integratoru da postavi naknadu aplikacije pomoću parametara kao što je swapFeeBps. Odgovor na zahtev za ponudu može da prikaže tu naknadu kroz polja kao što je fees.integratorFee.

Oznaka proizvoda manje je važna od konačnih brojeva.

Kod trgovine sa tačno definisanim ulazom treba uporediti:

• Očekivani izlazni iznos

• Minimalni izlazni iznos

• Mrežni trošak

• Trošak odobrenja

• Naknadu integratora ili novčanika

• Trošak mosta

• Vreme isteka ponude

• Politiku raspodele viška pri izvršenju

• Verovatnoću uspešnog izvršenja

Najjeftinija ruta je ona sa najvećom neto izlaznom vrednošću nakon eksternih troškova, a ne ona sa najmanjim reklamiranim procentom.

Poređenje na primeru 1.000 USD

Razmotrimo primer fiktivnog korisnika koji poseduje 1.000 USD u USDC-u i želi da kupi token srednje likvidnosti dostupan preko rute unutar novčanika, Uniswapa i Krakena.

Korisnik počinje sa samostalnim čuvanjem sredstava i želi da kupljeni token ponovo bude u njegovom novčaniku.

Pretpostavke su sledeće:

• Ponude se prikupljaju u istom kratkom vremenskom periodu.

• Za sve platforme koristi se ista referentna cena u USD.

• Potrebno odobrenje tokena već postoji.

• Token ne naplaćuje naknadu ili porez na prenos.

• Ruta unutar novčanika koristi MetaMask naknadu od 0,875%.

• Direktna DEX ruta koristi aktuelnu naknadu interfejsa Uniswap Labsa od 0%.

• CEX ruta koristi Kraken Pro taker naknadu od 0,80% na početnom nivou.

• Tržišni, mrežni i troškovi prenosa predstavljaju ulazne vrednosti modela, a ne ponude u realnom vremenu.

Samo prvi red koristi aktuelne objavljene rasporede naknada. Ostali redovi predstavljaju izričite pretpostavke koje služe za demonstraciju računice.

Ovaj scenario sadrži nekoliko korisnih pouka.

Novčanik je pronašao bolju rutu, ali je ipak koštao više

Modelovana ruta novčanika ima odstupanje zbog likvidnosti od 10 USD, u poređenju sa 14 USD kod direktne Uniswap rute.

Rutiranje novčanika uštedelo je 4 USD.

To nije bilo dovoljno da nadoknadi naknadu novčanika od 8,75 USD i nešto skuplju transakciju. Ruta unutar novčanika ipak je završila sa 7,75 USD lošijim rezultatom od Uniswapa.

Dobro rutiranje ne proizvodi automatski najjeftiniju transakciju. Najpre mora da nadoknadi naknadu aplikacije.

DEX nije imao naknadu za interfejs, ali nije bio besplatan

Modelovani ukupni trošak Uniswapa iznosi 28 USD, iako je naknada za interfejs nula.

Korisnik je ipak platio kroz:

• Ekonomiku pula ili rute

• Uticaj na cenu

• Gas

• Pomeranje pri izvršenju

Naknada za interfejs od 0% znači da korisnički interfejs ne dodaje upravo tu naknadu. Ne znači da trgovina nema ekonomski trošak.

Rezultat na CEX-u zavisi od toga gde se imovina nalazi na početku i na kraju

Kraken scenario uključuje modelovanih 11 USD troškova prenosa jer korisnik počinje i završava sa samostalnim čuvanjem sredstava.

Ako bi USDC već bio na Krakenu i kupljena imovina mogla tamo da ostane, tih 11 USD nestalo bi iz ovog modela. Ukupan trošak pao bi sa 23 USD na 12 USD, odnosno na 1,2%.

To bi bilo jeftinije, ali više ne bi predstavljalo poređenje pod istim uslovima sa samostalnim čuvanjem sredstava.

Korisnik bi prihvatio:

• Čuvanje sredstava na berzi

• Zahteve za verifikaciju naloga

• Regionalna ograničenja proizvoda

• Pravila povlačenja sredstava

• Moguća kašnjenja pri povlačenju

• Operativni rizik specifičan za platformu

Profesionalna CEX knjiga naloga može da bude veoma isplativa kada se imovina već nalazi na berzi. Prebacivanje imovine na berzu i sa nje može da poništi deo te prednosti.

Maker nalog je jeftiniji, ali nije ekvivalentan

Na aktuelnom početnom nivou Krakena maker nalog ima nižu objavljenu naknadu od taker naloga.

Kompromis predstavlja neizvesnost izvršenja.

Taker nalog se odmah izvršava prema dostupnoj likvidnosti. Maker nalog mora da ostane u knjizi naloga i može da bude izvršen kasnije, delimično ili da uopšte ne bude izvršen. Za to vreme tržište može da se pomeri u nepovoljnom smeru.

Niža naknada predstavlja nadoknadu za pružanje likvidnosti i prihvatanje rizika izvršenja.

Instant Buy je drugačiji proizvod

Jednostavan ekran za kupovinu na centralizovanoj berzi ne treba smatrati ekvivalentom profesionalne knjige naloga iste berze.

Dokumentacija za Kraken Instant Buy opisuje prikazanu naknadu i, kada je primenljivo, raspon uključen u cenu. Taj praktičniji tok zato može da bude skuplji od Kraken Pro platforme, iako oba proizvoda nudi ista kompanija.

Kada zamenu unutar novčanika poredite sa centralizovanom berzom, uporedite je sa konkretnim CEX proizvodom koji bi korisnik zaista koristio.

Kako isti novčanik dostiže trošak od 3% do 7%

Raspon od 3% do 7% nije univerzalna naknada novčanika. On se pojavljuje kada nekoliko troškova istovremeno postane značajno.

Sledeći primeri koriste naknadu sličnu MetaMask naknadi od 0,875%. Preostali procenti predstavljaju transparentne pretpostavke scenarija.

Prva ruta pokazuje zašto bi bilo pogrešno tvrditi da svaka zamena unutar novčanika košta od 3% do 7%.

Druga pokazuje kako naizgled obična transakcija od 1.000 USD može da pređe 3%, a da nijedna pojedinačna naknada ne bude ekstremna.

Treća pokazuje kako ruta sa tankom likvidnošću ili međulančana ruta može da se približi trošku od 7%, iako novčanik i dalje reklamira naknadu manju od 1%.

Ukupan trošak može dodatno da poraste kada:

• Token ima porez na kupovinu, prodaju ili prenos

• Potrebno je zasebno odobrenje

• Ruta koristi više pulova

• Naknade naplaćuju i izvorna i odredišna mreža

• Ponuda zastari

• Korisnik prihvati preveliko odstupanje

• Most nema dovoljno likvidnosti

• Transakcija bude izložena nepovoljnom redosledu izvršenja

• Trgovina bude mala u odnosu na fiksne mrežne troškove

Zašto programeri ipak ugrađuju zamene u novčanike

Ako zamene unutar novčanika mogu da koštaju više, zašto ih uopšte ugrađivati u proizvod?

Zato što najjeftinija teorijska ruta nije uvek ruta koju korisnik može uspešno da završi.

Zamislite korisnika koji:

• Poseduje USDC u ugrađenom novčaniku

• Nema ETH niti drugi nativni token za gas

• Potreban mu je ETH da bi koristio neku aplikaciju

• Nema spreman nalog na berzi

• Ne želi da prebacuje sredstva preko drugog novčanika

Bez integrisane zamene korisnik mora da napusti aplikaciju, pronađe izvor ETH-a, kopira adresu, prenese imovinu, sačeka potvrdu i vrati se u aplikaciju.

Zamena bez potrebe za nativnim gas tokenom ili sa uključenim gasom može da pretvori deo postojećeg USDC stanja u ETH, a da korisnik ne mora prvo da nabavi ETH.

Ruta možda ne nudi apsolutno najbolju cenu izvršenja. Ipak može da bude ekonomski racionalna jer rešava blokiran radni tok.

Drugi opravdani slučajevi upotrebe uključuju:

• Pretvaranje uplate u imovinu koju aplikacija zahteva

• Plaćanje računa u određenom stabilnom tokenu

• Rebalansiranje portfolija u ugrađenom novčaniku

• Nabavku tokena za gas na odredišnom lancu

• Objedinjavanje malih stanja različitih tokena

• Završavanje međulančane kupovine u jednom toku

• Izbegavanje ručne interakcije sa nepoznatim ugovorima

Vrednost proizvoda nije samo u „jednom kliku manje”. Reč je o manjem broju prilika da korisnik kopira pogrešnu adresu, izabere pogrešan lanac, odobri pogrešan ugovor ili odustane od transakcije.

Kompromis je u tome što praktičnost može da oteža proveru kvaliteta izvršenja.

Tok integracije koji uzima troškove u obzir

Zamenu unutar novčanika treba posmatrati kao proizvod za izvršenje trgovine, a ne samo kao dugme povezano sa API-jem za ponude.

1. Definišite stvarnu nameru korisnika

Pre nego što zatražite ponudu, utvrdite:

• Da li je tačno definisan ulazni ili izlazni iznos

• Izvorni lanac

• Odredišni lanac

• Token koji se prodaje

• Token koji se kupuje

• Da li se primalac razlikuje od pošiljaoca

• Da li je potreban gas na odredišnom lancu

• Da li korisnik na kraju mora samostalno da čuva sredstva

• Da li prednost imaju cena, brzina ili sigurnost izvršenja

Međulančano plaćanje koje zahteva da na odredište stigne tačno 100 USDC nije isti problem kao zamena u portfoliju kojom se prodaje tačno 100 USDC.

2. Istovremeno zatražite indikativne cene

Ponude treba tražiti približno u isto vreme.

Ako od jednog pružaoca usluge zatražite ponudu odmah, a od drugog 30 sekundi kasnije, tržišno kretanje može pogrešno da izgleda kao razlika u kvalitetu rutiranja.

To je naročito važno kod volatilne imovine ili imovine sa slabim obimom trgovanja.

Tipičan EVM tok koji koristi 0x Swap API v2 može da počne zahtevom GET /swap/allowance-holder/price radi dobijanja indikativne cene. Čvrsta, izvršiva ponuda zatim može da se zatraži preko GET /swap/allowance-holder/quote.

Čvrsta ponuda može da sadrži:

• buyAmount

• minBuyAmount

• totalNetworkFee

• fees.integratorFee

• issues.allowance

• route

• transaction

Tačna polja razlikuju se među pružaocima usluga, ali ekonomska normalizacija treba da bude dosledna.

3. Normalizujte jedinice tokena i referentne cene

Iznosi tokena koje vraća API obično su izraženi u osnovnim jedinicama.

USDC iznos mora da se konvertuje pomoću šest decimalnih mesta. Tipičan ERC-20 token može da koristi 18, ali programeri treba da pročitaju stvarne metapodatke tokena umesto da to pretpostavljaju.

Nakon konverzije, vrednujte ulaz i izlaz pomoću sinhronizovanih referentnih cena.

Za pošteno poređenje:

• Koristite isti izvor referentnih cena

• Koristite istu vremensku oznaku ili uzak vremenski period

• Koristite istu valutu za poređenje

• Zabeležite relevantan blok kada je to moguće

• Ne poredite poslednju cenu trgovine na CEX-u sa izvršivom ponudom na lancu

Srednja cena ili složena referentna cena obično je korisnija od cene poslednje transakcije.

4. Odvojite ugrađene i eksterne troškove

Većina ponuđenih izlaznih iznosa već odražava neku kombinaciju naknada platforme, naknada pulova, uticaja na cenu i naknada pružaoca usluge.

Te troškove ne treba ponovo dodavati prilikom izračunavanja ukupnog gubitka.

Eksterni troškovi mogu da uključuju:

• Gas koji se plaća zasebno

• Potrebno odobrenje

• Zasebnu transakciju mosta

• CEX naknadu za povlačenje

• Transakciju na odredišnom lancu koja nije uključena u rutu

Ako se gas odbija od tokena koji se prodaje ili je već uključen u ponudu, onda nije eksterni trošak.

5. Proverite postojeće odobrenje pre nego što zatražite novo

Kod ERC-20 trgovine proverite da li je trenutno odobrenje dovoljno.

Nemojte automatski tražiti neograničeno odobrenje i nemojte unapred upisivati adresu ovlašćenog ugovora kopiranu iz starog vodiča za integraciju. Koristite adresu vraćenu u aktuelnoj ponudi ili odgovoru za odobrenje i proverite je prema važećoj dokumentaciji pružaoca usluge.

Tok odobravanja utiče i na bezbednost i na troškove. Zasebno odobrenje dodaje još jedan potpis, još jednu transakciju i još jednu potencijalnu tačku neuspeha.

6. Simulirajte kompletnu transakciju

Najveći ponuđeni izlazni iznos bezvredan je ako će transakcija verovatno biti neuspešna.

Simulacija treba da proveri:

• Stanja tokena

• Odobrenja

• Očekivane promene stanja

• Zahteve za gas

• Poništavanja ugovora

• Minimalni izlazni iznos

• Ponašanje poreza ili naknade na prenos

• Nepodržane mehanizme tokena

• Izvršenje na odredištu, kada je dostupno

Nešto lošija ponuda sa visokom verovatnoćom poravnanja može da bude ekonomski bolja od optimistične ponude koja često ne uspeva.

7. Uporedite očekivani i najgori dozvoljeni ishod

Kompaktna pomoćna funkcija za troškove može da obezbedi doslednu računicu:

type QuoteEconomics = {
  inputUsd: number;
  expectedOutputUsd: number;
  minimumOutputUsd: number;
  externalCostsUsd: number;
};

export function summarizeQuote(quote: QuoteEconomics) {
  if (quote.inputUsd <= 0) {
    throw new Error("inputUsd must be positive");
  }

  const expectedLossUsd =
    quote.inputUsd -
    quote.expectedOutputUsd +
    quote.externalCostsUsd;

  const worstCaseLossUsd =
    quote.inputUsd -
    quote.minimumOutputUsd +
    quote.externalCostsUsd;

  return {
    expectedLossUsd,
    expectedLossBps:
      (expectedLossUsd / quote.inputUsd) * 10_000,
    expectedRetainedUsd:
      quote.inputUsd - expectedLossUsd,
    worstCaseLossUsd,
    worstCaseLossBps:
      (worstCaseLossUsd / quote.inputUsd) * 10_000,
  };
}

expectedOutputUsd i minimumOutputUsd treba vrednovati pomoću istog vremenskog perioda referentnih cena koji se koristi za inputUsd.

externalCostsUsd mora da sadrži samo troškove koji već nisu uračunati u ponuđeni izlazni iznos.

Time se dobijaju dva korisna broja:

• Očekivani ukupni trošak

• Najveći dozvoljeni ukupni trošak

Drugi broj često je korisniji od samostalnog prikazivanja tolerancije odstupanja.

8. Rangirajte rute prema neto vrednosti

Nemojte rangirati rute samo prema vrednosti buyAmount.

Ruta koja vraća više izlaznih tokena može istovremeno da zahteva:

• Skupo odobrenje

• Složeniju i skuplju transakciju

• Gas na odredišnom lancu

• Zasebnu operaciju mosta

• Više vremena i veću izloženost promeni cene

Bolja početna metrika glasi:

neto primljena vrednost = očekivana izlazna vrednost - eksterni troškovi

Rizik, vreme izvršenja i verovatnoću neuspeha zatim treba prikazati kao zasebne dimenzije.

9. Jasno prikažite naknadu aplikacije

API servisi agregatora mogu da dozvole integrisanoj aplikaciji da doda sopstvenu naknadu.

Na primer, 0x pruža parametre kao što su swapFeeBps, swapFeeRecipient i swapFeeToken. Kada se koriste, nastala naknada integratora može da bude vraćena u odgovoru na zahtev za ponudu.

Ta naknada nikada ne treba da bude skrivena iza generičke oznake za mrežne troškove.

Isti princip važi za višak pri trgovini, koji se ponekad naziva pozitivnim odstupanjem. Ako se izvršenje poboljša nakon što korisnik potpiše transakciju, aplikacija treba da ima jasnu politiku o tome ko dobija to poboljšanje.

Ako pružalac usluge nudi podešavanje kao što je tradeSurplusRecipient, programeri treba da ga posmatraju kao ekonomsku odluku o proizvodu, a ne samo kao opciju API-ja.

10. Uskladite podatke nakon poravnanja

Kvalitet ponude ne može da se meri isključivo podacima dostupnim u trenutku njenog dobijanja.

Sačuvajte dovoljno informacija da biste mogli da uporedite očekivano i ostvareno izvršenje:

• Ponuđeni izlazni iznos

• Minimalni izlazni iznos

• Stvarni izlazni iznos

• Procenjeni mrežni trošak

• Stvarni mrežni trošak

• Ponuđenu rutu

• Izvršenu rutu

• Vreme ponude

• Vreme poravnanja

• Referentne cene

• Eksplicitna polja sa naknadama

• Status transakcije

• Razlog neuspeha, kada je dostupan

Ostvareni ukupni trošak treba da postane metrika proizvoda.

Bez ovog usklađivanja tim može da zna da su korisnici završili zamene, a da pritom ne bude svestan da su redovno plaćali 300 ili 500 baznih poena više od očekivanog.

Šta pouzdan ekran za zamenu treba da prikaže

Korisniku ne bi trebalo da bude potrebna tabela da bi otkrio umanjenje vrednosti od 4%.

Koristan ekran za potvrdu treba da odgovori na tri pitanja.

Šta ću verovatno dobiti?

Prikažite:

• Očekivani izlazni iznos tokena

• Očekivanu referentnu vrednost

• Efektivni kurs

• Starost ponude ili vreme isteka

• Rutu ili pružaoca usluge

Koji je najgori prihvatljiv ishod?

Prikažite:

• Minimalni primljeni iznos

• Minimalni primljeni iznos u referentnoj valuti

• Toleranciju odstupanja

• Uslove pod kojima će transakcija biti poništena

Očekivani izlazni iznos i minimalni izlazni iznos nikada ne treba prikazivati kao da predstavljaju isti broj.

Koliko plaćam?

Prikažite:

• Naknadu novčanika ili integratora

• Naknadu za likvidnost ili pružaoca usluge, kada je dostupna

• Uticaj na cenu

• Procenjeni mrežni trošak

• Trošak odobrenja, ako je potrebno

• Trošak mosta

• Trošak odredišnog lanca

• Porez ili naknadu tokena

• Očekivani ukupni trošak kao procenat i u referentnoj valuti

Kod međulančane rute gas na izvornom lancu, trošak mosta, gas na odredišnom lancu i uticaj zamene na odredišnom lancu treba razdvojiti kad god pružalac ponude te informacije učini dostupnim.

Ako je naknada mosta grupisana sa uticajem na cenu, interfejs to treba jasno da navede razumljivim jezikom.

Uobičajene greške pri poređenju troškova zamene

Posmatranje samo reklamiranog procenta

Interfejs sa naknadom od 0% može da proizvede lošiji rezultat od novčanika sa naknadom od 0,875% ako njegova ruta ima znatno veći uticaj na cenu ili mrežni trošak.

Važi i obrnuto. Bolje rutiranje ne garantuje da će naknada novčanika biti nadoknađena.

Posmatranje tolerancije odstupanja kao naknade

Podešavanje odstupanja na 1% ne dokazuje da je korisnik izgubio 1%.

Nakon poravnanja izmerite stvarni izlazni iznos u odnosu na očekivani.

Poređenje ponuda prikupljenih u različito vreme

Cena tokena može da se promeni dovoljno za nekoliko sekundi da preokrene prividni poredak dve platforme.

Tražite ponude istovremeno i koristite isti vremenski period referentnih cena.

Zanemarivanje početne i krajnje lokacije imovine

CEX trgovina koja počinje i završava se na berzi nije direktno uporediva sa zamenom kod koje korisnik samostalno čuva sredstva.

Uključite uplate, povlačenja i mrežne troškove ako je stvarni cilj korisnika da završi sa imovinom u sopstvenom novčaniku.

Dvostruko uračunavanje ugrađenih naknada

Ako je naknada novčanika već smanjila ponuđeni izlazni iznos, njeno ponovno dodavanje preuveličaće gubitak.

Isto pravilo važi za:

• Gas uključen u ponudu bez potrebe za nativnim gas tokenom

• Naknade mosta uračunate u uticaj na cenu

• Naknade ili poreze tokena uključene u očekivani izlazni iznos

• CEX naknade odbijene od primljene imovine

Zanemarivanje troškova neuspešnih transakcija

Neuspešna tradicionalna transakcija na lancu i dalje može da potroši gas.

Simulacija, privatno rutiranje i izvršenje zasnovano na nameri mogu da pruže stvarnu ekonomsku vrednost čak i kada ne poboljšavaju prikazani kurs.

Automatsko povećavanje tolerancije odstupanja

Povećavanje tolerancije može da smanji broj neuspešnih transakcija, ali istovremeno proširuje raspon cena koje je korisnik pristao da prihvati.

Kod tokena sa tankom likvidnošću povećavanje tolerancije bez provere dubine pula ili naknada tokena može da pretvori problem rutiranja u mnogo veći ostvareni gubitak.

Stvarni kompromisi različitih mesta trgovanja

Ne postoji kategorija koja je uvek najjeftinija.

Direktni DEX može da pobedi kod likvidnog para na jeftinoj mreži.

CEX knjiga naloga može da pobedi kada se imovina već nalazi na berzi.

Agregator može da pobedi kada je likvidnost fragmentisana.

Zamena unutar novčanika može da bude racionalan izbor kada korisnik nema token za gas, potrebna mu je međulančana ruta ili bi u suprotnom odustao od transakcije.

Ispravan odgovor zavisi od početne pozicije korisnika, odredišta, veličine trgovine i njegove spremnosti da prihvati čuvanje sredstava kod treće strane ili dodatnu operativnu složenost.

Broj koji programeri treba da mere

Korisnici ne gube neprimetno od 3% do 7% zato što svaki novčanik sadrži jednu tajnu naknadu od 7%.

Gube zato što se više manjih troškova sabira, dok interfejs svaki prikazuje na drugom mestu, pod drugom oznakom ili unutar kursa.

Reklamirana naknada jeste korisna, ali nije konačna cena.

Iskrenija metrika glasi:

ostvarena ulazna vrednost - ostvarena izlazna vrednost + eksterni troškovi

Kada se dosledno meri, taj broj odgovara na pitanja koja korisnici zaista postavljaju:

• Zašto su MetaMask zamene toliko skupe?

• Da li je zamena unutar novčanika jeftinija od DEX-a?

• Da li je Phantom naknada zaista iznosila samo 0,85%?

• Da li je agregator dovoljno poboljšao izvršenje da opravda svoju naknadu?

• Da li bi CEX bio jeftiniji nakon troškova uplata i povlačenja?

Za programere stopa uspešno završenih zamena nije dovoljna. Tok sa jednim dodirom može da ima odličnu stopu konverzije, dok korisnicima neprimetno pruža loše izvršenje.

Bolja metrika proizvoda je ostvareni ukupni trošak izražen u baznim poenima i izmeren prema sinhronizovanoj referentnoj ceni.

Zamenu unutar novčanika može da vredi koristiti. Ona može da ukloni potrebu za nativnim tokenom za gas, smanji prebacivanje između aplikacija, spreči greške koje se mogu izbeći i završi tok koji bi u suprotnom propao.

Ipak, i dalje treba da dokaže da njena praktičnost vredi svoje cene.

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti i prodati USDT i USDC. Više informacija nalazi se na stranici Volet za korisnike iz Srbije. Za otvaranje naloga koristi Volet referral link. Link je referral link autora članka.

Izvori

1. MetaMask centar za pomoć: Korisnički vodič za zamene

2. Phantom pomoć: Zamena kriptovaluta u Phantomu

3. Phantom pomoć: Razumevanje EVM transakcija bez nativnog gas tokena

4. Phantom pomoć: Podešavanje parametara zamene

5. Uniswap Labs: Koje naknade naplaćuje Uniswap Labs?

6. Uniswap Labs: Šta je uticaj na cenu?

7. Uniswap Labs: Kako funkcioniše rutiranje?

8. Uniswap Labs: Da li UniswapX ima mrežne troškove?

9. 0x dokumentacija: Pregled API-ja

10. 0x dokumentacija: Allowance Holder endpoint za cenu

11. 0x dokumentacija: Allowance Holder endpoint za ponudu

12. 0x dokumentacija: Monetizacija EVM integracije za zamene

13. Kraken: Raspored naknada za spot trgovanje kriptovalutama

14. Kraken podrška: Upravljanje kupovinama i Instant Buy naknade

15. Kraken podrška: Naknade i minimalni iznosi za povlačenje kriptovaluta

English version: Read on Dev.to: Why In-Wallet Swaps Can Quietly Cost Users 3% to 7%

To je važna razlika za developere.

Ako napadač ukrade seed frazu, dobije neograničen allowance ili ubedi korisnika da pošalje sredstva na njegovu adresu, protokol može da radi potpuno ispravno. Transakcija je validno potpisana, konsenzus je postignut, a sredstva su ipak izgubljena.

Problem zato nije samo u smart contract kodu. Nalazi se i u korisničkom interfejsu, obradi transakcija, upozorenjima, korisničkoj podršci, evidenciji događaja i načinu na koji proizvod reaguje na rizično ponašanje.

U Srbiji ovaj problem nije teorijski. Nacionalni CERT upozorava na prevare povezane sa ulaganjem u kriptovalute i platforme za „brzu zaradu“, dok su Europol i Eurojust dokumentovali organizovane pozivne centre iz Srbije koji su korisnike usmeravali ka lažnim investicionim platformama. U akciji iz januara 2023. uhapšeno je 15 osoba, od kojih 14 u Srbiji, a među zaplenjenom imovinom bili su hardverski novčanici sa kriptovalutama vrednim približno milion USD.

Osam obrazaca u nastavku nisu zvanična statistička klasifikacija. To je praktičan threat model sastavljen od prevara na koje upozoravaju domaće institucije i napada koji proizlaze iz načina na koji savremeni novčanici, tokeni i decentralizovane aplikacije rade.

Zajednička arhitektura prevare

Većina kripto prevara izgleda različito samo na površini. Ispod nje se obično nalazi isti workflow:

1. Napadač pronalazi korisnika preko oglasa, društvene mreže, aplikacije za upoznavanje ili kompromitovanog naloga.

2. Gradi kredibilitet pomoću lažnog autoriteta, grupe navodno zadovoljnih korisnika ili male početne isplate.

3. Korisnika navodi da kupi kriptovalutu preko legitimne menjačnice.

4. Sredstva zatim prebacuje na lažnu platformu, napadačevu adresu ili zlonamerni smart contract.

5. Interfejs prikazuje izmišljeni profit ili nagradu.

6. Povlačenje sredstava se uslovljava dodatnom uplatom, „porezom“, verifikacijom ili novim zadatkom.

7. Kada korisnik odbije da uplati još novca, nalog se zaključava.

8. Nakon toga se često pojavljuje druga grupa koja naplaćuje navodni povraćaj izgubljenih sredstava.

Ovaj model je korisniji od liste sumnjivih domena. Domen može nestati za nekoliko sati, ali redosled događaja ostaje gotovo isti.

1. Lažne investicione platforme i pozivni centri

Najpoznatiji obrazac počinje oglasom koji obećava pristup automatizovanom trgovanju, ekskluzivnom investicionom programu ili navodno naprednom kripto sistemu.

Korisnik ne mora odmah da uplati novac. Dovoljno je da ostavi ime i broj telefona.

Nakon toga ga kontaktira „broker“, „account manager“ ili „finansijski savetnik“. Prva uplata je obično dovoljno mala da ne izazove ozbiljan otpor. Dashboard zatim prikazuje rast portfolija, uspešne pozicije i profit koji zapravo ne postoji.

U operaciji koju su Europol i Eurojust sproveli 11. januara 2023. kriminalne grupe koristile su oglase na društvenim mrežama da dovedu korisnike na lažne sajtove za ulaganje u kriptovalute. Žrtve su najpre ulagale manje trocifrene iznose, a prikazani lažni rast vrednosti služio je kao argument za veće uplate.

Kako platforma izgleda legitimno

Lažnoj platformi nije potreban pravi trading engine. Dovoljan je:

• obrazac za uplatu;

• tabela sa generisanim transakcijama;

• grafikon čiji se podaci čuvaju u lokalnoj bazi;

• administratorski panel za ručno menjanje salda;

• kontrola kojom operator može da odobri malu probnu isplatu;

• chat ili telefonski kanal kojim se korisnik navodi na sledeću uplatu.

Korisnik vidi broj koji raste i zaključuje da se iza njega nalazi stvarna pozicija na tržištu. U stvarnosti, frontend možda nikada nije poslao nalog bilo kojoj berzi.

Šta developer može da ugradi

Ako proizvod usmerava korisnike ka spoljnim provajderima, provera ne treba da se svodi na logo ili tekst u footeru.

Za pružaoce usluga povezanih sa virtuelnim valutama u Srbiji postoji javni registar Narodne banke Srbije. Registar ne garantuje profit niti eliminiše sve poslovne rizike, ali omogućava proveru da li određeni domaći pružalac ima dozvolu za tu vrstu usluge.

Korisno je proveravati:

• da li se domen podudara sa domenom pravnog lica;

• da li je primalac uplate ista kompanija koja se predstavlja korisniku;

• da li platforma prikazuje proverljiv txHash;

• da li je moguć mali test povlačenja bez razgovora sa „brokerom“;

• da li se od korisnika traži instalacija softvera za udaljeni pristup;

• da li se povlačenje uslovljava dodatnom uplatom.

Poslednji signal je naročito jak. Legitiman trošak može biti odbijen od postojećeg salda. Zahtev da korisnik pošalje novi depozit kako bi „otključao“ sopstveni novac tipičan je obrazac prevare.

2. Telegram i WhatsApp task prevare

Task prevara se predstavlja kao jednostavan posao: lajkovanje videa, ocenjivanje proizvoda, optimizacija sadržaja ili izvršavanje zadataka u aplikaciji.

Početni zadaci ponekad zaista donesu malu isplatu. To nije dokaz da sistem radi. Ta isplata je deo troška akvizicije žrtve.

Nakon nekoliko uspešnih zadataka korisnik dobija „premium“ zadatak. Da bi ga započeo, mora da uplati sopstveni novac, često u kriptovaluti. Aplikacija zatim prikazuje proviziju koju nije moguće povući bez još jedne uplate.

Američka Federalna trgovinska komisija opisuje isti obrazac: neočekivana ponuda za posao, jednostavni zadaci, rast izmišljenog salda i zahtev da korisnik uplati kriptovalutu kako bi nastavio ili povukao navodnu zaradu. Nacionalni CERT Srbije je sličan mehanizam opisao u upozorenju o platformama za „brzu zaradu“, ličnim brokerima, mentorima i investiranju u kriptovalute.

Tehnički trag

Task platforma obično ima nekoliko prepoznatljivih osobina:

• saldo nije povezan sa stvarnim platnim sistemom;

• status zadatka menja administratorski nalog;

• ista adresa prima uplate većeg broja korisnika;

• novi zadaci se otključavaju tek nakon depozita;

• korisnik ne može da izveze istoriju naloga;

• kompanija nema proverljive klijente ni poslovnu dokumentaciju;

• komunikacija se premešta sa javne platforme na privatnu grupu.

Šta ugraditi u proizvod

Ako razvijaš referral, rewards ili marketplace sistem, isti mehanizmi mogu biti zloupotrebljeni i u legitimnom proizvodu.

Korisne mere uključuju:

• ograničenje nagrada za novootvorene naloge;

• detekciju više naloga povezanih sa istim uređajem ili izvorom sredstava;

• odloženu isplatu kod naglog rasta aktivnosti;

• jasno odvajanje depozita od zarađenog salda;

• zabranu workflowa u kojem korisnik mora da uplati novac da bi primio zaradu;

• evidenciju ko je i kada promenio stanje naloga.

Najvažnije pitanje nije da li aplikacija prikazuje saldo, već iz kog proverljivog događaja je taj saldo nastao.

3. Prevare zasnovane na poverenju i emotivnom odnosu

Ovaj obrazac se često naziva relationship investment scam ili confidence-enabled investment fraud. Izraz „pig butchering“ i dalje se koristi, ali precizniji naziv opisuje suštinu: napadač prvo gradi odnos, a tek kasnije uvodi ulaganje.

Kontakt može početi navodno pogrešnim brojem, porukom na LinkedInu, aplikacijom za upoznavanje ili razgovorom u investicionoj grupi.

Napadač ne traži novac odmah. Nedeljama gradi kredibilitet, deli fotografije, razgovara o poslu i povremeno pominje sopstvene uspešne investicije. Tek kada uspostavi poverenje, predlaže platformu na kojoj će „pomoći“ korisniku da trguje.

Lažna platforma može dozvoliti jednu malu isplatu. Cilj nije da korisnik zaradi, već da zaključi da je sistem provereno funkcionalan i uplati znatno veći iznos.

Zašto klasičan KYC nije dovoljan

KYC proverava identitet korisnika koji otvara nalog. Ne proverava da li taj korisnik postupa pod tuđim uticajem.

Sa stanovišta berze ili novčanika, korisnik može biti potpuno legitiman:

• prijavio se sa svog uređaja;

• prošao proveru identiteta;

• kupio kriptovalutu svojim novcem;

• potpisao transakciju sopstvenim ključem.

Rizik se nalazi u kontekstu, a ne nužno u identitetu.

Mogući signali rizika

Proizvod može da registruje kombinaciju sledećih događaja:

• potpuno nova odredišna adresa;

• neuobičajeno veliki iznos u odnosu na istoriju naloga;

• kupovina i trenutno povlačenje celog iznosa;

• promena uređaja neposredno pre transakcije;

• više neuspelih pokušaja kopiranja ili izmene adrese;

• korisnik u podršci pominje mentora, savetnika ili porez za povlačenje.

Nijedan signal pojedinačno ne dokazuje prevaru. Kombinacija može opravdati dodatnu potvrdu, kratko odlaganje ili upozorenje napisano jezikom koji opisuje konkretan scenario.

Generičko „kriptovalute su rizične“ uglavnom se ignoriše. Upozorenje „Ako vam je ovu adresu poslao broker koga ste upoznali preko Telegrama, ne šaljite sredstva pre nezavisne provere“ mnogo je korisnije.

4. Lažna podrška i krađa seed fraze

Početnik koji naiđe na problem obično traži pomoć tamo gde se već nalazi: u komentarima, Telegram grupi, Discord serveru ili na društvenoj mreži.

Napadači prate upravo takve poruke.

Nekoliko minuta nakon pitanja „Zašto mi transakcija ne prolazi?“ korisniku se javlja nalog sa logotipom poznatog novčanika. Lažni agent zatim šalje obrazac za „sinhronizaciju“, „verifikaciju“ ili „oporavak“ novčanika.

Obrazac traži seed frazu, privatni ključ ili pristup ekranu.

Kod self-custody novčanika seed fraza nije lozinka koju podrška može da resetuje. Ona je osnova iz koje se izvode privatni ključevi. Ko je poseduje može da rekonstruiše novčanik i potpisuje transakcije bez dodatne saglasnosti vlasnika.

Zvanična dokumentacija MetaMaska izričito navodi da podrška nikada ne traži Secret Recovery Phrase i da se ona ne unosi na veb-sajt.

Zašto detekcija broja reči nije dovoljno dobra

Ponekad se predlaže da aplikacija prepozna niz od 12 ili 24 reči i blokira unos. To može sprečiti deo slučajnog deljenja, ali nije pouzdana bezbednosna kontrola.

Takva provera proizvodi i lažno pozitivne i lažno negativne rezultate:

• nije svaka rečenica od 12 reči seed fraza;

• ne koriste svi sistemi iste dužine;

• napadač može da traži reči pojedinačno;

• korisnik može da pošalje fotografiju;

• seed može biti podeljen kroz više poruka.

Bolji pristup je kombinacija:

• upozorenja pored svakog polja za podršku;

• automatskog maskiranja sumnjivog sadržaja;

• zabrane trajnog čuvanja takvih unosa;

• obuke agenata podrške;

• jasnog pravila da nijedan zaposleni nema workflow koji zahteva privatni ključ ili seed frazu.

Ako je seed fraza već otkrivena, promena lozinke novčanika nije dovoljna. Preostala sredstva treba prebaciti u nov novčanik formiran na bezbednom uređaju.

5. Wallet draineri i zlonamerna odobrenja

Korisnik ne mora da otkrije seed frazu da bi izgubio tokene. Dovoljno je da odobri smart contractu pravo da ih prenosi.

Kod ERC-20 tokena funkcija approve postavlja koliko određeni spender sme da potroši u ime vlasnika. Funkcija allowance vraća preostali odobreni iznos, a transferFrom omogućava prenos u okviru tog odobrenja.

Legitimne decentralizovane aplikacije koriste ovaj mehanizam da bi izvršile swap, depozit ili plaćanje. Wallet drainer koristi isti standard, ali korisnika navodi da odobri zlonamernog primaoca.

Napad obično stiže kroz:

• lažni airdrop;

• klonirani mint sajt;

• poruku da token uskoro ističe;

• lažnu proveru podobnosti;

• kompromitovani nalog poznatog projekta;

• oglas koji vodi na domen sličan originalnom.

Problem neograničenog allowancea

Aplikacije često traže veoma veliki ili praktično neograničeni allowance da korisnik ne bi plaćao mrežnu naknadu za svako novo odobrenje. To poboljšava UX, ali povećava posledice kompromitovanja.

Čak i ako korisnik odvoji novčanik od sajta, ranije odobrenje ostaje zapisano u stanju smart contracta. Prekid WalletConnect sesije ili zatvaranje taba ne poništava allowance.

Kod potpisa je situacija dodatno komplikovana. EIP-712 omogućava potpisivanje strukturiranih podataka koji mogu biti čitljiviji od sirovog heksadecimalnog sadržaja, ali strukturiran prikaz nije automatski dokaz da je zahtev bezbedan. Korisnik i dalje mora da vidi domen, chainId, ugovor koji verifikuje potpis i stvarnu nameru operacije.

Šta prikazati pre potpisa

Dobar interfejs ne treba da kaže samo „Potpisujete poruku“.

Treba da objasni:

• koji ugovor dobija ovlašćenje;

• koji token je obuhvaćen;

• maksimalan iznos;

• da li odobrenje ističe;

• da li primalac ranije postoji u istoriji korisnika;

• šta druga strana može da uradi nakon potpisa;

• da li transakcija prenosi sredstva odmah ili samo daje buduće pravo prenosa.

Ako proizvod zna da korisnik odobrava neograničenu potrošnju, to ne treba sakriti iza tehničke vrednosti poput maksimalnog uint256 broja.

6. Address poisoning

Address poisoning ne pokušava da ukrade privatni ključ. Napadač pokušava da kontaminira istoriju transakcija adresom koja liči na adresu koju korisnik već koristi.

Pretpostavimo da korisnik redovno šalje sredstva na:

0x12a4...91bf

Napadač generiše adresu sa sličnim početkom i krajem:

0x12a4...91bf

Skraćeni prikaz može biti isti, dok su karakteri u sredini potpuno različiti. Napadač zatim sa te adrese pošalje malu ili bezvrednu transakciju. Cilj je da korisnik kasnije kopira pogrešnu adresu iz istorije.

MetaMask ovaj napad opisuje kao pokušaj da se korisnik navede da kopira adresu koja liči na prethodno korišćenu, ali pripada napadaču.

Greška u dizajnu, ne u kriptografiji

Kriptografske adrese jesu jedinstvene. Problem nastaje kada ih UI prikazuje kao nekoliko početnih i završnih karaktera.

Za prikaz stanja to može biti prihvatljivo. Za potvrdu slanja velikog iznosa nije.

Korisne zaštite su:

• imenik pouzdanih primalaca;

• prikaz više karaktera kod nove adrese;

• posebno upozorenje kada se adresa samo delimično podudara sa ranijim primaocem;

• zabrana kopiranja adrese direktno iz neproverenog token transfera;

• test transakcija pre slanja velikog iznosa;

• potvrda primaoca drugim komunikacionim kanalom.

Jednostavan string similarity algoritam može pomoći, ali ne sme samostalno blokirati transakcije. Napadač može namerno generisati sličnu adresu, ali i legitimne adrese ponekad slučajno dele početne ili završne karaktere.

7. Lažni tokeni, airdropovi i pump grupe

Naziv i simbol tokena nisu jedinstveni identifikatori.

Napadač može da napravi novi ERC-20 ugovor sa istim nazivom i simbolom kao poznati token. Može da emituje Transfer događaje, dodeli saldo poznatim adresama ili pošalje lažni token velikom broju korisnika.

To ne znači da su vlasnici tih adresa kupili token niti da iza njega postoji legitiman projekat. Stanje tokena kontroliše njegov smart contract.

Zvanična dokumentacija Ethereum projekta upozorava da lažni token može koristiti naziv i simbol legitimnog tokena, dok je adresa ugovora ono što ih zaista razlikuje.

Airdrop kao ulaz u drainer

Samo pojavljivanje nepoznatog tokena u novčaniku obično nije dovoljno da napadač preuzme sredstva. Rizik nastaje kada korisnik:

• otvori URL iz naziva ili opisa tokena;

• pokuša da ga proda preko sajta koji preporučuje napadač;

• odobri ugovoru pristup drugim tokenima;

• potpiše poruku čije posledice ne razume;

• plati navodnu naknadu za otključavanje.

Zbog toga novčanik ne treba automatski da tretira svaki primljeni token kao vrednu imovinu. Nepoznati tokeni mogu biti skriveni ili označeni dok se ne utvrde ugovor, likvidnost i poreklo.

Pump grupe koriste drugi mehanizam

U pump-and-dump grupama organizatori unapred kupuju token sa slabom likvidnošću. Zatim objavljuju „signal“ stotinama korisnika. Cena raste jer grupa istovremeno kupuje, a organizatori prodaju svoj ranije stečen saldo.

Korisnicima izgleda kao da je signal bio tačan. U stvari, njihova kupovina je bila izlazna likvidnost za organizatore.

Proizvod može da prikaže:

• koncentraciju tokena po adresama;

• dubinu likvidnosti;

• očekivani price impact;

• starost ugovora;

• mogućnost prodaje;

• privilegije vlasnika ugovora;

• da li ugovor može da pauzira transfere ili menja naknade.

Ovi signali ne dokazuju prevaru, ali korisniku daju bolju sliku od samog grafikona cene.

8. Lažni servisi za povraćaj sredstava

Nakon prve prevare često sledi druga.

Napadač ili povezana grupa javljaju se žrtvi sa tvrdnjom da su pronašli sredstva, identifikovali vlasnika adrese ili dobili sudski nalog. Za povraćaj navodno treba platiti trošak istrage, porez, mrežnu naknadu ili depozit.

Ponekad se predstavljaju kao advokatska kancelarija, regulator, policijska jedinica ili blockchain forenzičari. FBI je posebno upozorio na lažne pravne kancelarije koje ciljaju osobe prethodno oštećene kripto prevarama.

Na javnom blokčejnu moguće je pratiti transakcije, ali to nije isto što i kontrolisati sredstva.

Ako su sredstva stigla do centralizovane menjačnice, postoji mogućnost da nadležni organi zatraže identifikaciju naloga ili zamrzavanje. Ako su prebačena na adresu čiji ključ kontroliše napadač, nijedan privatni „recovery agent“ ne može jednostavno poništiti potvrđenu transakciju.

Tvrdnja da je povraćaj zagarantovan treba da se tretira kao signal visokog rizika.

Kako izgleda razuman risk engine

Zaštita ne mora da počne skupom platformom za blockchain analitiku. Prva verzija može da bude skup objašnjivih pravila zasnovanih na događajima koje proizvod već poseduje.

type RiskContext = {
  unsolicitedContact: boolean;
  firstTimeRecipient: boolean;
  unusualAmount: boolean;
  depositRequiredForWithdrawal: boolean;
  unlimitedTokenAllowance: boolean;
  remoteAccessRequested: boolean;
  seedPhraseRequested: boolean;
  addressResemblesKnownRecipient: boolean;
};

const weights: Record<keyof RiskContext, number> = {
  unsolicitedContact: 10,
  firstTimeRecipient: 10,
  unusualAmount: 15,
  depositRequiredForWithdrawal: 35,
  unlimitedTokenAllowance: 20,
  remoteAccessRequested: 30,
  seedPhraseRequested: 100,
  addressResemblesKnownRecipient: 30,
};

function calculateRisk(context: RiskContext): number {
  return Object.entries(context).reduce((score, [signal, active]) => {
    if (!active) return score;
    return score + weights[signal as keyof RiskContext];
  }, 0);
}

function riskAction(score: number) {
  if (score >= 100) return "block-and-escalate";
  if (score >= 50) return "step-up-confirmation";
  if (score >= 25) return "show-contextual-warning";
  return "allow";
}

Ovaj kod nije model za detekciju prevare i težine nisu univerzalne. Poenta je u arhitekturi:

• signal ima jasno poreklo;

• odluka može da se objasni;

• pravilo može da se testira;

• pragovi mogu da se kalibrišu;

• događaj može da se sačuva za kasniju istragu.

U produkciji bi svaki signal trebalo da sadrži vreme, izvor, verziju pravila i nivo pouzdanosti. Bez toga je teško objasniti zašto je transakcija usporena ili blokirana.

Preporučeni workflow za kripto proizvod

Praktična implementacija može da se podeli na pet slojeva.

1. Prikupljanje signala

Prikupljaju se samo podaci relevantni za konkretnu operaciju:

• poreklo sesije;

• starost naloga;

• promena uređaja;

• istorija primaoca;

• vrsta ugovora;

• iznos tokena;

• traženi allowance;

• rezultat simulacije transakcije;

• poznati indikatori kompromitacije;

• prethodna upozorenja koja je korisnik ignorisao.

Više podataka ne znači automatski i bolju zaštitu. Telemetrija koja nema definisanu svrhu povećava troškove, regulatorni rizik i posledice eventualnog curenja.

2. Normalizacija

Ista adresa može postojati na različitim mrežama, a isti domen može imati više poddomena i internacionalizovanih zapisa.

Pre poređenja treba normalizovati:

• chainId;

• format adrese;

• checksummed prikaz gde je primenljiv;

• Unicode i Punycode domene;

• vremenske zone;

• vrednosti tokena i broj decimala.

Posebno je opasno porediti samo simbol tokena. USDT ili ETH u interfejsu nisu dovoljni da identifikuju ugovor i mrežu.

3. Objašnjiva odluka

Upozorenje treba da kaže šta je pronađeno:

Ova adresa ranije nije korišćena i veoma liči na adresu kojoj ste već slali sredstva. Proverite celu adresu pre nastavka.

To je korisnije od poruke:

Transakcija je rizična.

Korisnik mora da zna koju pretpostavku treba da proveri.

4. Proporcionalna frikcija

Nije svaki rizik razlog za blokadu.

Moguće reakcije su:

• informativna poruka;

• dodatni ekran sa detaljima;

• ponovno unošenje dela adrese;

• potvrda na drugom uređaju;

• kratko odlaganje;

• razgovor sa podrškom;

• privremena blokada;

• eskalacija security timu.

Previše upozorenja stvara alert fatigue. Posle nekoliko generičkih poruka korisnik razvija naviku da sve potvrđuje bez čitanja.

5. Audit trail

Za svaku rizičnu operaciju korisno je sačuvati:

• ID korisnika ili pseudonimizovani identifikator;

• vreme događaja;

• mrežu i adresu;

• txHash, ako postoji;

• aktivirana pravila;

• prikazano upozorenje;

• odluku korisnika;

• verziju risk enginea.

Ovo nije samo materijal za istragu. Bez kvalitetnog audit loga nije moguće proceniti da li upozorenja zaista sprečavaju gubitke ili samo ometaju legitimne korisnike.

Koliko ovakva zaštita košta

Ne postoji jedna cena jer različiti slojevi rešavaju različite probleme.

Osnovna pravila, kontekstualna upozorenja, provera nove adrese i audit log mogu se izgraditi unutar postojeće aplikacije. Glavni trošak je vreme product, frontend, backend i security tima.

Čitanje stanja tokena i allowance vrednosti može koristiti postojeću RPC infrastrukturu. Poništavanje odobrenja je on-chain transakcija i zato korisnik plaća mrežnu naknadu.

Simulacija transakcija, reputacija domena, detekcija wallet drainera i praćenje tokova sredstava mogu se kupiti kao spoljne usluge ili izgraditi interno. Samostalna implementacija smanjuje zavisnost od jednog dobavljača, ali zahteva održavanje čvorova, indeksera, pravila i izvora podataka.

Najskuplja greška često nije račun za infrastrukturu, već pogrešna odluka proizvoda:

• previše stroga pravila blokiraju legitimne korisnike;

• previše blaga pravila propuštaju očiglednu prevaru;

• nejasna upozorenja stvaraju lažan osećaj sigurnosti;

• oznaka „bezbedno“ može se protumačiti kao garancija.

Zato je bolje prikazivati konkretne signale nego donositi apsolutne presude.

Incident response u prvih nekoliko sati

Ako je korisnik već stupio u interakciju sa prevarom, najpre treba utvrditi šta je kompromitovano.

Ako je poslat samo novac

Sačuvati:

• txHash;

• mrežu;

• adresu primaoca;

• iznos i token;

• vreme transakcije;

• komunikaciju sa napadačem;

• URL, domen i korisničke naloge;

• potvrde kupovine ili povlačenja sa menjačnice.

Ako su sredstva poslata sa centralizovane menjačnice ili ka njoj, incident treba odmah prijaviti toj platformi. Brzina je važna jer se sredstva mogu prebaciti kroz više adresa.

Ako je odobren zlonamerni ugovor

Treba proveriti i opozvati aktivna token odobrenja. Samo odvajanje novčanika od sajta ne uklanja allowance.

Ako postoji sumnja da je napadač dobio seed frazu ili privatni ključ, opozivanje odobrenja nije dovoljno. Preostalu imovinu treba premestiti u nov novčanik čiji ključevi nisu izvedeni iz kompromitovanog seeda.

Ako je kompromitovan uređaj

Uređaj ne treba koristiti za formiranje novog novčanika dok se ne proveri ili ponovo instalira. U suprotnom, novi ključevi mogu završiti kod istog napadača.

Treba promeniti povezane lozinke, prekinuti aktivne sesije i uključiti višefaktorsku autentifikaciju tamo gde je dostupna.

Prijava u Srbiji

Nacionalni CERT prima prijave fizičkih lica, malih i srednjih preduzeća i operatora važnih IKT sistema. Formular predviđa unos indikatora kompromitacije kao što su domeni, URL-ovi, IP adrese i hash vrednosti. Na stranici za prijavu nalazi se i upućivanje na platformu „Sajber straža“ Ministarstva unutrašnjih poslova za slučajeve sumnje na visokotehnološki kriminal.

Prijava ne garantuje povraćaj sredstava, ali stvara trag koji može povezati više žrtava, domena, naloga i adresa sa istom operacijom.

Šta bi trebalo da ostane u proizvodu

Najbolja zaštita za početnike nije još jedan modal sa upozorenjem da su kriptovalute rizične.

Korisniku treba pomoći u trenutku kada donosi konkretnu odluku:

• kada prvi put šalje sredstva novoj adresi;

• kada adresa liči na onu iz istorije;

• kada ugovor traži neograničen allowance;

• kada potpis proizvodi ovlašćenje umesto obične prijave;

• kada token nema proverljiv ugovor ili likvidnost;

• kada se povlačenje uslovljava dodatnom uplatom;

• kada podrška traži podatak koji legitimna podrška nikada ne sme da traži.

Kripto prevare nisu samo problem edukacije. One su problem dizajna sistema.

Dobar proizvod ne pretpostavlja da će korisnik prepoznati svaki socijalni inženjering, pročitati svaki karakter adrese ili razumeti razliku između povezivanja novčanika, potpisa poruke, token odobrenja i prenosa sredstava.

On tu razliku prikazuje pre nego što korisnik napravi nepovratnu grešku.

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti i prodati USDT i USDC. Više informacija nalazi se na stranici Volet za korisnike iz Srbije. Za otvaranje naloga koristi Volet referral link. Link je referral link autora članka.

Izvori

1. Call centres selling fake crypto taken down in Bulgaria, Serbia and Cyprus, Europol

2. Takedown of fraudulent cryptocurrency network in Bulgaria, Cyprus and Serbia, Eurojust

3. Prevare u vezi sa ulaganjima u kriptovalute, Nacionalni CERT Republike Srbije

4. Registar pružalaca usluga povezanih s virtuelnim valutama, Narodna banka Srbije

5. Task scams create the illusion of making money, Federal Trade Commission

6. Confidence-Enabled Cryptocurrency Investment Fraud, FBI Internet Crime Complaint Center

7. MetaMask’s official support channels, MetaMask Help Center

8. ERC-20 Token Standard, Ethereum Improvement Proposals

9. How to revoke smart contract access to your crypto funds, ethereum.org

10. EIP-712: Typed structured data hashing and signing

11. Address poisoning scams, MetaMask Help Center

12. How to identify scam tokens, ethereum.org

13. Fictitious Law Firms Targeting Cryptocurrency Scam Victims, FBI Internet Crime Complaint Center

14. Prijavi incident, Nacionalni CERT Republike Srbije

15. Volet Srbija

English version: Tehničku analizu i threat-modeling na engleskom pročitajte na Dev.to: 30 Crypto Scams Every Web3 Developer Must Threat-Model

Na menjačnici najčešće poseduješ stavku u internom ledgeru operatora. Menjačnica kontroliše ključeve, bira kada će napraviti blockchain transakciju i određuje da li povlačenje može da bude izvršeno.

U self-custody novčaniku kontrolišeš mehanizam kojim se transakcija autorizuje. To može biti privatni ključ, hardverski uređaj, skup potpisa ili smart account sa sopstvenim pravilima.

Blockchain ne zna da si se prijavio mejlom, da je KYC odobren niti da Coinbase, Kraken ili neka druga platforma u internoj bazi vodi stanje na tvoje ime. Blockchain vidi adrese, skripte, smart contract naloge, potpise i promene stanja.

Za developera ova razlika nije filozofska. Ona određuje:

• ko može da zaustavi isplatu

• gde se nalazi tajna koja kontroliše sredstva

• šta se dešava kada API nije dostupan

• kako se sprečavaju duple isplate

• ko plaća mrežnu proviziju

• kako se radi oporavak posle incidenta

• koji sistem je izvor istine

• koliko infrastrukture moraš sam da izgradiš

Kratak odgovor: gde je kripto

Kripto nije fizički smešten u aplikaciji, browser ekstenziji, hardverskom uređaju ili fajlu sa seed frazom.

Na blockchainu postoji stanje koje određuje pod kojim uslovima određena sredstva mogu da budu potrošena. Novčanik čuva ili koristi podatke potrebne da zadovolji te uslove.

Kod Ethereum externally owned account, ili EOA naloga, kontrola se dokazuje potpisom napravljenim odgovarajućim privatnim ključem. Kod smart accounta pravila autorizacije izvršava ugovor. Kod Bitcoina wallet prati nepotrošene izlaze, odnosno UTXO skup, i pravi transakciju koja zadovoljava uslove njihovog trošenja.

Zato je preciznije reći:

Novčanik ne čuva coine. Novčanik čuva ili koristi autoritet za njihovo trošenje.

Ako je kripto na menjačnici, korisnik obično ne poseduje taj autoritet. Menjačnica ga poseduje, dok korisniku kroz internu evidenciju priznaje određeno stanje.

Šta se zapravo dešava na menjačnici

Centralizovana menjačnica je kombinacija više sistema:

• sistema naloga i identiteta

• KYC i risk servisa

• internog finansijskog ledgera

• trading enginea

• servisa za depozite

• servisa za povlačenja

• hot, warm i cold wallet infrastrukture

• procesa za usaglašavanje internih i onchain stanja

Kada korisnik A na menjačnici proda 0.1 BTC korisniku B, ne mora da postoji Bitcoin transakcija. Trading engine izvršava nalog, a interni ledger menja stanja korisnika.

Pojednostavljeno, rezultat može da izgleda ovako:

user_a.BTC -= 0.1
user_a.EUR += 5_800

user_b.EUR -= 5_800
user_b.BTC += 0.1

Ovi brojevi su ilustracija promene stanja, ne tržišna cena.

Za blockchain se ništa nije promenilo. BTC može ostati na istoj adresi koju kontroliše menjačnica. Promenio se samo interni odnos između korisnika i operatora platforme.

Onchain transakcija je obično potrebna tek kada:

• korisnik deponuje sredstva sa spoljne adrese

• korisnik povlači sredstva na spoljnu adresu

• menjačnica konsoliduje depozite

• menjačnica premešta likvidnost između svojih walleta

• menjačnica dopunjava hot wallet iz bezbednijeg skladišta

Depozitna adresa nije nužno mesto čuvanja

Kada menjačnica dodeli korisniku depozitnu adresu, to ne znači da će sredstva trajno ostati na toj adresi.

Adresa pre svega može služiti za atribuciju. Sistem prati dolazne transakcije i povezuje ih sa internim korisničkim nalogom. Posle dovoljnog broja potvrda, interni ledger knjiži depozit, a sredstva mogu biti prebačena u zajednički wallet.

Na nekim mrežama atribucija se radi jedinstvenom adresom. Na drugim se koristi zajednička adresa uz dodatni identifikator, kao što su memo, tag ili destination tag.

Zbog toga integracija ne sme da modeluje depozit kao običan par:

asset + address

Pouzdaniji model uključuje najmanje:

asset + network + address + optional_memo

USDC na Ethereumu, Base mreži i drugom podržanom lancu nisu ista ruta depozita, iako aplikacija svuda može prikazivati simbol USDC.

Stanje na menjačnici nije isto što i onchain stanje

Ako API menjačnice vrati da nalog ima 10 ETH, to ne znači da postoji blockchain adresa sa tačno 10 ETH rezervisana samo za tog korisnika.

To znači da interni sistem menjačnice priznaje određeno stanje nalogu. Sredstva mogu biti:

• raspoređena preko više walleta

• objedinjena sa sredstvima drugih korisnika

• delom u hot walletu

• delom u hladnijem skladištu

• u procesu konsolidacije

• rezervisana zbog otvorenih naloga ili povlačenja

Ovo je razlog zbog kojeg API menjačnice i blockchain explorer odgovaraju na različita pitanja.

API menjačnice odgovara na pitanje:

Koliko interni sistem platforme priznaje ovom nalogu?

Blockchain node odgovara na pitanje:

Koje stanje trenutno postoji na ovom lancu i pod kojim uslovima može biti promenjeno?

Ni jedno ni drugo samo po sebi nije dovoljno za finansijsko usaglašavanje aplikacije.

Šta je onda novčanik

Termin wallet se koristi za nekoliko različitih stvari:

1. Aplikaciju koja prikazuje stanje i istoriju.

2. Key store koji čuva šifrovani privatni ključ.

3. Signer koji potpisuje transakcije.

4. Sistem za derivaciju više naloga iz jednog seed materijala.

5. Smart account sa programabilnim pravilima.

6. Servis koji kombinuje custody, policy engine i API.

Klasičan full-service wallet obavlja najmanje četiri posla:

• generiše ili uvozi ključ

• izvodi adresu iz javnog ključa

• čita stanje sa mreže

• pravi i potpisuje transakcije

Ti poslovi ne moraju biti u istom procesu.

Bezbednija serverska arhitektura često ih razdvaja:

flowchart LR
    A[Aplikacioni servis] --> B[Transaction builder]
    B --> C[Policy engine]
    C --> D[Signer ili multisig]
    D --> E[Broadcaster]
    E --> F[Blockchain node]
    F --> G[Indexer]
    G --> H[Reconciliation worker]
    H --> A

Aplikacioni servis zna da korisniku treba isplatiti određeni iznos. Signer ne mora da zna ništa o korisničkoj sesiji. On dobija predlog transakcije i potpisuje ga samo ako su zadovoljena pravila.

Ovo razdvajanje smanjuje mogućnost da kompromitovani web server automatski postane i kompromitovani treasury.

Privatni ključ nije isto što i seed fraza

Privatni ključ je tajna kojom se potpisuje za jedan konkretan nalog.

Seed fraza je ljudski čitljiv zapis materijala iz kojeg deterministički mogu da se izvedu mnogi ključevi. BIP-39 definiše postupak kojim se entropija predstavlja nizom reči i pretvara u binarni seed. Taj seed zatim može da se koristi u hijerarhijskim determinističkim walletima.

To donosi praktičnu prednost: jedan backup može obnoviti veliki skup adresa.

Istovremeno povećava blast radius. Ako neko dođe do seed fraze, često nije kompromitovan samo jedan nalog već čitavo stablo naloga izvedenih iz tog seeda.

Seed zato nije:

• lozinka za aplikaciju

• vrednost za .env na web serveru

• recovery code koji može biti promenjen

• podatak koji treba poslati telemetry sistemu

• string koji treba odštampati u CI logu

Ako korisnik izgubi lozinku menjačnice, postoji procedura oporavka identiteta. Ako izgubi jedinu kopiju self-custody seeda i nema drugi recovery mehanizam, ne postoji centralni sistem koji može da izda novi pristup postojećim sredstvima.

Potpis je stvarna granica kontrole

Kod self-custody sistema aplikacija ne bi trebalo da traži privatni ključ korisnika. Ona priprema zahtev, a wallet prikazuje šta se potpisuje.

Na EVM mrežama browser walleti često izlažu provider interfejs zasnovan na EIP-1193 standardu. Aplikacija šalje RPC zahtev provideru, a wallet odlučuje da li će tražiti potvrdu korisnika i izvršiti operaciju.

Minimalna integracija može da izgleda ovako:

interface Eip1193Provider {
    request(args: {
        method: string;
        params?: readonly unknown[] | object;
    }): Promise<unknown>;

    on(event: string, listener: (...args: unknown[]) => void): void;
}

async function connectWallet(provider: Eip1193Provider) {
    const accounts = await provider.request({
        method: "eth_requestAccounts",
    }) as string[];

    const chainId = await provider.request({
        method: "eth_chainId",
    }) as string;

    if (!accounts[0]) {
        throw new Error("Wallet nije vratio aktivan nalog");
    }

    return {
        address: accounts[0],
        chainId,
    };
}

Aplikacija ovde dobija javnu adresu i identifikator mreže. Ne dobija privatni ključ.

Produkcijska integracija mora da reaguje i na događaje kao što su promena naloga i promena mreže. Nije bezbedno pretpostaviti da će adresa sa početka sesije ostati aktivna do kraja checkout ili signing procesa.

Wallet takođe nije automatski izvor istine za poslovne podatke. To što je korisnik povezao adresu dokazuje samo da je wallet izložio tu adresu aplikaciji. Za dokaz kontrole obično je potreban challenge koji korisnik potpisuje, uz nonce i ograničen rok važenja.

Bezbedan lokalni eksperiment sa potpisom

Potpisivanje može da se isproba lokalno, bez slanja transakcije i bez korišćenja stvarnih sredstava. Sledeći primer koristi ethers v6 i efemerni wallet:

import { randomUUID } from "node:crypto";
import { Wallet, verifyMessage } from "ethers";

const wallet = Wallet.createRandom();
const challenge = `wallet-demo:${randomUUID()}`;

const signature = await wallet.signMessage(challenge);
const recoveredAddress = verifyMessage(challenge, signature);

console.log({
    expected: wallet.address,
    recovered: recoveredAddress,
    valid: recoveredAddress === wallet.address,
});

Primer demonstrira osnovnu ideju: backend može iz potpisa i originalne poruke da rekonstruiše adresu potpisnika.

U stvarnoj autentikaciji challenge treba da sadrži najmanje:

• domen aplikacije

• jednokratni nonce

• vreme izdavanja

• rok važenja

• očekivani chain ili drugi kontekst, kada je relevantan

• opis namene potpisa

Potpis poruke ne sme automatski da se tretira kao odobrenje za proizvoljnu transakciju. UI mora jasno razlikovati prijavljivanje, davanje dozvole token ugovoru i slanje sredstava.

EOA, multisig, MPC i smart account nisu ista stvar

Rečenica „koristimo wallet” ne govori dovoljno o sigurnosnom modelu.

EOA sa jednim ključem

Jedan privatni ključ može samostalno da potpiše transakciju.

Prednosti:

• jednostavan model

• široka kompatibilnost

• nizak integracioni overhead

• lako lokalno testiranje

Mane:

• jedan ključ predstavlja single point of failure

• kompromitovanje ključa znači direktnu mogućnost trošenja

• nema ugrađenog approval workflowa

• rotacija ključa uglavnom znači prelazak na novi nalog

EOA sa ključem u environment promenljivoj možda jeste tehnički self-custody, ali nije nužno dobra custody arhitektura.

Hardverski wallet

Ključ se nalazi u specijalizovanom uređaju i potpis se obavlja bez izlaganja ključa aplikacionom računaru.

To smanjuje rizik ekstrakcije ključa, ali ne rešava sve probleme. Korisnik i dalje može potpisati zlonamernu ili pogrešno prikazanu transakciju. Bezbednost zavisi i od toga šta uređaj može jasno da prikaže pre potpisa.

Multisig

Za izvršenje je potreban prag potpisa, na primer dva od tri vlasnika.

Na EVM mrežama multisig je često implementiran kao smart account. Account čuva listu vlasnika i threshold, proverava potpise i tek zatim izvršava poziv.

Prednosti:

• nema jednog obaveznog potpisnika

• moguće je odvojiti tehničku i poslovnu kontrolu

• uređaj jednog potpisnika može biti izgubljen bez gubitka treasuryja

• approval proces može odgovarati organizacionim pravilima

Mane:

• više operativnih koraka

• skuplje onchain izvršenje od jednostavnog EOA transfera

• potrebno je upravljati vlasnicima i pragom

• pogrešna promena konfiguracije može zaključati sredstva

MPC

Multi-party computation deli proces potpisivanja između više strana tako da kompletan privatni ključ ne mora postojati na jednom mestu.

MPC nije sinonim za multisig.

Kod multisiga mreža ili smart contract vidi i proverava više potpisa. Kod threshold MPC sistema rezultat prema mreži može izgledati kao jedan standardni potpis, iako je interno nastao saradnjom više učesnika.

Ta razlika utiče na:

• kompatibilnost sa protokolima

• onchain trošak

• audit trag

• recovery model

• zavisnost od MPC infrastrukture

Smart account

Smart account je nalog čija pravila autorizacije izvršava kod.

Pored više potpisnika, može podržavati:

• limite po periodu

• session keys

• allowlist odredišta

• recovery module

• batching

• sponzorisanje mrežnih provizija

• različite uloge za predlaganje i izvršenje

Programabilnost donosi fleksibilnost, ali i novu površinu napada. Greška u modulu, policyju ili upgrade mehanizmu može biti jednako ozbiljna kao kompromitovan privatni ključ.

Realan use-case: stablecoin isplate saradnicima

Zamislimo SaaS platformu koja jednom nedeljno isplaćuje nekoliko stotina saradnika u stablecoinu.

Sistem prima fiat prihod, konvertuje deo sredstava, obračunava obaveze i šalje stablecoin na adrese saradnika.

Naizgled jednostavan zahtev otvara veliki broj pitanja:

• Ko bira mrežu?

• Ko proverava da adresa pripada očekivanoj mreži?

• Šta ako je token simbol isti na više mreža?

• Ko finansira native token potreban za gas?

• Šta ako transakcija ostane pending?

• Kada isplatu smatramo konačnom?

• Kako sprečavamo duplu isplatu posle timeouta?

• Kako dokazujemo šta je korisnik uneo?

• Kako se radi refund?

• Ko odobrava veliku isplatu?

• Šta ako je exchange API dostupan, ali su povlačenja privremeno zaustavljena?

Postoje tri razumna modela.

Model 1: isplate preko menjačnice

Aplikacija drži operativna sredstva na poslovnom nalogu menjačnice i preko API-ja zahteva povlačenja.

flowchart LR
    A[Payroll servis] --> B[Interni ledger]
    B --> C[Approval i risk]
    C --> D[Exchange API]
    D --> E[Menjačnica]
    E --> F[Blockchain]
    F --> G[Adresa saradnika]

Prednosti

Menjačnica preuzima:

• upravljanje privatnim ključevima

• održavanje node infrastrukture

• izbor i dopunjavanje hot walleta

• emitovanje transakcije

• deo fee managementa

• praćenje podržanih mreža

Tim može relativno brzo da dođe do produkcionog workflowa.

Nedostaci

Aplikacija zavisi od:

• dostupnosti API-ja

• statusa poslovnog naloga

• limita povlačenja

• risk i compliance odluka operatora

• dostupnosti konkretne mreže

• interne obrade povlačenja

• promena API-ja i pravila autentikacije

API odgovor da je zahtev prihvaćen nije isto što i onchain potvrda. Menjačnica može prvo kreirati interni transfer objekat, zatim obraditi proveru i tek kasnije emitovati blockchain transakciju.

Zato status accepted ili pending ne sme automatski značiti paid.

Model 2: self-custody hot wallet

Backend kontroliše operativni wallet i sam šalje transakcije.

flowchart LR
    A[Payroll servis] --> B[Queue]
    B --> C[Policy engine]
    C --> D[Signer]
    D --> E[RPC node]
    E --> F[Blockchain]
    F --> G[Indexer]
    G --> H[Reconciliation]

Prednosti

Tim kontroliše:

• trenutak slanja

• fee strategiju

• batching

• nonce management

• zamenu pending transakcije

• izbor RPC i indexing provajdera

• način potvrđivanja settlementa

Nedostaci

Tim je odgovoran za:

• zaštitu ključeva

• dostupnost signera

• dopunjavanje native gas tokena

• nonce konkurentnost

• monitoring mempoola

• recovery proceduru

• incident response

• proveru token ugovora i mreže

Najopasnija greška je povezati javni API server direktno sa neograničenim ključem treasury walleta.

Ako napadač dobije remote code execution na aplikacionom serveru, cilj arhitekture mora biti da i dalje ne može proizvoljno da prebaci sva sredstva.

To zahteva policy granicu između aplikacije i signera.

Model 3: hibridni treasury

Hibridna arhitektura koristi više nivoa:

• menjačnicu za konverziju i fiat tokove

• mali hot wallet za automatizovane isplate

• multisig ili drugi zaštićeni account za rezervu

• periodično dopunjavanje operativnog walleta

• limite po transakciji i periodu

flowchart TD
    A[Fiat prihod] --> B[Menjačnica]
    B --> C[Operativni hot wallet]
    D[Multisig rezerva] --> C
    C --> E[Automatske isplate]
    E --> F[Korisničke adrese]
    C --> G[Alarm za nizak saldo]
    G --> H[Predlog dopune]
    H --> D

Ovaj model ograničava štetu.

Ako je hot wallet kompromitovan, izložen je njegov trenutni operativni saldo, a ne cela rezerva. Ako menjačnica blokira povlačenje, postojeća sredstva u hot walletu i dalje mogu da pokriju deo obaveza.

Cena je složeniji reconciliation između najmanje tri sistema:

• internog poslovnog ledgera

• stanja na menjačnici

• onchain walleta

Za većinu ozbiljnih payment i treasury sistema ovo je realniji model od čistog „sve na menjačnici” ili „jedan private key na serveru”.

Workflow za integraciju sa menjačnicom

API konkretne menjačnice se razlikuje, ali pouzdan workflow ima slične faze.

1. Modeluj asset i network odvojeno

Nemoj koristiti samo ticker kao identitet sredstva.

type AssetRoute = {
    asset: "USDC";
    network: "ethereum" | "base";
    contractAddress?: string;
    decimals: number;
};

U ozbiljnijem sistemu ove vrednosti ne treba nekritički hardkodovati. Konfiguracija mora biti verzionisana i proverena prema dokumentaciji provajdera i podacima mreže.

2. Razdvoji API dozvole

Ključ za čitanje stanja ne treba automatski da ima pravo povlačenja.

Ako platforma podržava granularne dozvole, napravi odvojene identitete za:

• read-only reporting

• trading

• kreiranje povlačenja

• administraciju adresa

• reconciliation worker

IP allowlist nije zamena za zaštitu tajne, ali može smanjiti površinu napada.

3. Koristi interni idempotency ključ

Mrežni timeout ne govori da li je zahtev izvršen.

Sledeći scenario je čest:

1. Aplikacija pošalje zahtev za povlačenje.

2. Menjačnica prihvati zahtev.

3. HTTP odgovor ne stigne zbog prekida veze.

4. Worker ponovi zahtev.

5. Nastanu dva povlačenja.

Ako API podržava idempotency ili client reference, koristi ga. Ako ne podržava, potreban je interni state machine i provera udaljenog stanja pre retryja.

4. Ne mapiraj HTTP status direktno na finansijski status

200 OK znači da je API poziv obrađen. Ne znači nužno da je primalac dobio sredstva.

Minimalni model statusa može izgledati ovako:

type PayoutStatus =
    | "created"
    | "awaiting_approval"
    | "submitting"
    | "provider_accepted"
    | "broadcast"
    | "confirming"
    | "settled"
    | "rejected"
    | "failed"
    | "manual_review";

failed takođe nije uvek konačan. Ako ne znaš da li je provajder prihvatio zahtev, realan status je manual_review ili druga eksplicitna kategorija neizvesnosti.

5. Usaglasi provider transfer i onchain transakciju

Čuvaj odvojeno:

• sopstveni payout ID

• provider transfer ID

• transaction hash

• asset

• network

• destination address

• memo ili tag

• bruto iznos

• provider fee

• network fee, kada je dostupan

• vreme kreiranja

• vreme emitovanja

• vreme settlementa

Jedna provider operacija ne mora uvek da odgovara tačno jednoj onchain transakciji. Menjačnica može batchovati više povlačenja u jednu transakciju.

Zbog toga provider_transfer_id i transaction_hash nisu isti tip identifikatora.

Workflow za self-custody integraciju

Kod self-custody sistema aplikacija preuzima više odgovornosti, ali dobija bolju kontrolu nad procesom.

1. Kreiraj intent, ne transakciju

Poslovni servis prvo treba da kreira nameru:

Isplati 250 USDC korisniku 1842 na Base mreži.

Tek posebna komponenta prevodi intent u konkretnu blockchain transakciju.

To omogućava proveru:

• poslovne obaveze

• korisničke adrese

• mreže

• token ugovora

• limita

• duplih zahteva

• compliance pravila

• trenutnog stanja walleta

2. Rezerviši sredstva u internom ledgeru

Nemoj čekati blockchain da bi sprečio dvostruko trošenje na nivou aplikacije.

Kada payout uđe u obradu, iznos treba prebaciti iz available u reserved. Posle settlementa prelazi u paid. Ako se operacija bezbedno otkaže, rezervacija se vraća.

Blockchain stanje samo po sebi ne zna koji deo salda si već obećao drugim korisnicima.

3. Napravi transakciju deterministički

Transaction builder dobija odobren intent i formira:

• odredišnu adresu

• količinu u atomic units

• calldata za token transfer

• chain ID

• nonce

• fee parametre

• rok važenja, kada format to podržava

Finansijske iznose ne treba čuvati u JavaScript number tipu. Koristi integer vrednosti u najmanjoj jedinici ili proverenu decimalnu biblioteku.

4. Proveri policy pre potpisa

Signer ili servis ispred njega treba da proveri:

• da li je chain dozvoljen

• da li je token contract dozvoljen

• maksimalni iznos

• dnevni limit

• odredišnu adresu

• broj isplata u batchu

• očekivani calldata selector

• vezu sa odobrenim payout intentom

Signer koji slepo potpisuje bilo koji payload nije sigurnosna granica. On je samo udaljeni privatni ključ.

5. Broadcast nije settlement

Posle emitovanja transakcija može biti:

• u mempoolu

• privremeno nevidljiva nekim nodeovima

• zamenjena drugom transakcijom sa istim nonceom

• uključena u blok

• privremeno uključena pa uklonjena reorganizacijom

• uspešno uključena, ali sa neuspešnim izvršenjem smart contract poziva

Zato treba razlikovati:

signed -> broadcast -> included -> confirmed -> settled

Na EVM mreži receipt sa statusom neuspeha znači da je transakcija uključena, ali operacija nije uspela. Mrežna provizija je ipak potrošena.

6. Reconciliation mora biti nezavisan od request procesa

HTTP handler koji inicira isplatu ne treba da čeka konačnost mreže.

Pozadinski worker treba periodično da:

• preuzima receipt

• proverava broj potvrda

• dekodira relevantne evente

• upoređuje očekivani i stvarni token transfer

• detektuje zamenjene ili nestale transakcije

• ažurira interni ledger

• podiže alarm kada stanje nije moguće automatski objasniti

Nonce i UTXO menjaju način rada

EVM i Bitcoin walleti ne rešavaju konkurentnost na isti način.

EVM account model

EOA transakcije koriste sekvencijalni nonce. Dve paralelne transakcije sa istog naloga ne smeju nekontrolisano da izaberu isti nonce.

Ako deset workera istovremeno pita node za trenutni nonce, svi mogu dobiti isti rezultat. Potreban je centralizovan nonce manager, serijalizacija ili drugi koordinacioni mehanizam.

Jedna zaglavljena transakcija sa nižim nonceom može zadržati kasnije transakcije tog naloga.

Bitcoin UTXO model

Bitcoin transakcija bira konkretne nepotrošene izlaze kao inpute. Konkurentnost znači sprečiti da dva workera pokušaju da potroše isti UTXO.

Wallet mora da rešava:

• coin selection

• rezervaciju inputa

• change output

• procenu veličine transakcije

• fee rate

• praćenje nepotvrđenog changea

Zbog toga „pošalji iznos” nije ista backend operacija na svim blockchainima. Apstrakcija koja potpuno skriva model mreže često počne da curi čim dođu batching, fee bumping i paralelne isplate.

Koliko košta menjačnica, a koliko novčanik

Ne postoji jedan broj koji daje pošten odgovor. Trošak ima više slojeva.

Trošak menjačnice

Ukupan trošak može uključivati:

• trading fee

• spread

• fee za povlačenje

• network-specific fee

• minimalni iznos povlačenja

• trošak neuspelih ili ručno obrađenih zahteva

• vreme čekanja i zaključan kapital

• razvoj i održavanje integracije

• compliance i operativne troškove

Fee za povlačenje ne mora odgovarati stvarnom network feeju konkretne transakcije. Menjačnica može koristiti fiksnu tarifu, dinamičku tarifu ili batching.

Zbog toga cenu treba meriti kao:

ukupan trošak provajdera / broj uspešno završenih isplata

U obračun treba uključiti i operativni rad, ne samo stavku koju API vrati kao fee.

Trošak self-custody sistema

Onchain trošak zavisi od mreže.

Na EVM mrežama osnovni odnos je:

transaction fee = gas used * effective gas price

Token transfer je smart contract poziv i obično zahteva više gasa od jednostavnog transfera native tokena. Smart account, multisig i batch poziv imaju drugačiji profil potrošnje.

Na Bitcoinu se fee tipično određuje veličinom transakcije i fee rateom:

transaction fee = virtual size * fee rate

Broj inputa i outputa zato direktno utiče na cenu. Wallet sa velikim brojem sitnih UTXO izlaza može imati skupu konsolidaciju čak i kada je ukupan saldo visok.

Pored network feeja, self-custody sistem ima trošak:

• RPC i indexing infrastrukture

• HSM, MPC ili signer servisa

• hardverskih uređaja

• audita

• monitoringa

• incident response procesa

• bezbednog backup i recovery sistema

• razvoja reconciliation logike

Self-custody uklanja deo zavisnosti od menjačnice, ali ne pretvara infrastrukturu u besplatnu.

Najveće greške u implementaciji

Jedan status completed

Finansijska operacija ima više faza. Jedan boolean completed gubi informaciju potrebnu za retry i istragu incidenta.

Ticker kao jedini identitet sredstva

USDC bez mreže i contract adrese nije dovoljno precizan identitet.

Privatni ključ na istom serveru kao javni API

Kompromitovanje aplikacije tada automatski postaje kompromitovanje sredstava.

Retry bez idempotency zaštite

Timeout nije dokaz neuspeha. Slepo ponavljanje može napraviti duplu isplatu.

Oslanjanje samo na webhook

Webhook može kasniti, biti dupliran ili ne stići. Potreban je periodični polling i reconciliation.

Oslanjanje samo na polling

Polling bez događaja povećava kašnjenje i opterećenje. Dobar sistem koristi događaje za brzinu, a periodično usaglašavanje za tačnost.

Knjiženje depozita posle prve pojave transakcije

Transakcija koja je viđena nije isto što i potvrđena transakcija. Politika potvrda treba da zavisi od mreže, vrednosti i prihvatljivog rizika.

Logovanje potpunog request payloadа

Payload može sadržati API potpise, adrese, memo vrednosti ili druge osetljive podatke. Signer logovi su posebno osetljivi.

Nema procedure za kompromitovanje

„Ključ je u HSM-u” nije kompletan incident plan. Potrebno je unapred znati:

• kako se zaustavljaju isplate

• kako se povlače dozvole

• kako se rotiraju operativni walleti

• ko donosi odluku

• kako se obaveštavaju zavisni servisi

• kako se proverava šta je potpisano

Menjačnica i wallet imaju različite izvore istine

Pouzdana arhitektura eksplicitno definiše autoritet za svaku vrstu podatka.

Greška nastaje kada se jedan sistem koristi za pitanje na koje nije dizajniran da odgovori.

Blockchain ne zna za neisplaćenu fakturu. Interni ledger ne može dokazati da je transakcija uključena u blok. Exchange API ne dokazuje da korisnik kontroliše odredišnu adresu.

Kako izabrati model

Menjačnica ima smisla kada su dominantni zahtevi:

• česta konverzija fiat i kripto sredstava

• mali tim i kratko vreme integracije

• ograničeno iskustvo sa key managementom

• potreba za poslovnim izveštajima provajdera

• prihvatljiva zavisnost od operatora

Self-custody ima smisla kada su dominantni zahtevi:

• direktna kontrola vremena i pravila isplate

• interakcija sa smart contractima

• potreba za batchingom ili programabilnim treasuryjem

• smanjenje zavisnosti od jednog provajdera

• mogućnost ulaganja u signer, monitoring i recovery infrastrukturu

Multisig ili smart account ima smisla kada:

• sredstva pripadaju organizaciji

• jedna osoba ne treba samostalno da ih kontroliše

• postoje poslovna pravila odobravanja

• potreban je audit trag odluka

• operativni zastoj jednog potpisnika ne sme biti fatalan

Hibridni model je često najbolji kada sistem istovremeno ima fiat tokove, automatizovane isplate i veću rezervu.

Praktična matrica odluke

Minimalan eksperiment koji zaista nešto pokazuje

Za razumevanje razlike nisu potrebna stvarna sredstva.

Dovoljno je napraviti mali testni workflow:

1. Lokalno generisati efemerni wallet.

2. Potpisati challenge i verifikovati adresu.

3. Povezati browser wallet preko EIP-1193 providera.

4. Prebaciti wallet na test mrežu.

5. Napraviti transfer bez emitovanja i pregledati njegova polja.

6. Potpisati test transakciju u walletu.

7. Emitovati je samo na test mreži.

8. Pratiti prelaze broadcast, included i confirmed.

9. U bazi sačuvati intent odvojeno od transaction hasha.

10. Simulirati timeout posle emitovanja i proveriti da retry ne pravi novu isplatu.

Najvažniji deo nije uspešna transakcija. Najviše se nauči kada se namerno testiraju neizvesna stanja:

• RPC timeout posle broadcasta

• promena aktivnog wallet naloga

• pogrešan chain ID

• nedovoljno native tokena za gas

• transakcija sa preniskim fee parametrima

• dupliran webhook

• provider transfer bez transaction hasha

• neuspešan contract poziv uključen u blok

To su situacije u kojima razlika između demo aplikacije i finansijskog sistema postaje očigledna.

Konačna razlika nije UI, već autoritet

Menjačnica i novčanik mogu prikazivati isti broj i isto dugme Send, ali iza tog dugmeta ne postoji ista operacija.

Na menjačnici šalješ instrukciju operatoru. Operator proverava nalog, interne limite i sopstvena pravila, pa zatim eventualno potpisuje onchain transakciju svojim ključevima.

Kod self-custody walleta potpis nastaje pod kontrolom korisnika ili organizacionog policyja. Mreža proverava potpis ili pravila smart accounta bez potrebe da poznaje identitet korisnika iz poslovne baze.

Zato pitanje „gde ti je kripto” zapravo znači:

Ko trenutno može da proizvede validnu autorizaciju za trošenje, pod kojim pravilima i bez čije dozvole?

Ako je odgovor „menjačnica”, imaš jednostavniju integraciju i operativnu zavisnost.

Ako je odgovor „jedan privatni ključ na serveru”, imaš tehničku kontrolu i vrlo koncentrisan rizik.

Ako je odgovor „izolovan signer sa limitima” ili „multisig sa jasno definisanim recoveryjem”, već gradiš custody arhitekturu, a ne samo wallet integraciju.

Dobar sistem ne bira između menjačnice i novčanika ideološki. Bira granicu poverenja, automatizacije i odgovornosti koju tim može realno da održava.

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti i prodati USDT i USDC. Više informacija nalazi se na stranici Volet za korisnike iz Srbije. Za otvaranje naloga koristi Volet referral link. Link je referral link autora članka.

Izvori

1. Ethereum.org, „Ethereum accounts”, pregled EOA i contract naloga, privatnih ključeva i odnosa između naloga i walleta. Dokumentacija

2. Ethereum.org, „Transactions”, struktura, potpisivanje i emitovanje Ethereum transakcija. Dokumentacija

3. Ethereum.org, „Gas and fees”, model obračuna mrežnih provizija. Dokumentacija

4. Ethereum Improvement Proposals, EIP-1193, standardni JavaScript Provider API. Specifikacija

5. Ethers.js v6, dokumentacija za Wallet, signere i rad sa ključevima. Dokumentacija

6. Bitcoin Developer Guide, struktura transakcija i UTXO model. Dokumentacija

7. Bitcoin Developer Guide, wallet programi, signing i razdvajanje mrežnih i potpisnih komponenti. Dokumentacija

8. Bitcoin Improvement Proposals, BIP-39, mnemonic kod za determinističko generisanje ključeva. Specifikacija

9. Safe dokumentacija, vlasnici, threshold i verifikacija potpisa u Safe Smart Account modelu. Dokumentacija

10. Safe dokumentacija, kreiranje, potpisivanje i izvršavanje transakcija sa offchain prikupljanjem potpisa. Dokumentacija

11. Coinbase Exchange API, evidencija depozita i povlačenja na nivou exchange naloga. Dokumentacija

12. Volet Srbija

English version: Read on Dev.to: Wallets, Exchanges, and Blockchains: Three Layers of One System

Kada developer prvi put integriše kripto novčanik, problem obično izgleda jednostavno:

1. poveži wallet

2. pročitaj adresu

3. pripremi transakciju

4. zatraži potpis

5. sačekaj potvrdu

Taj workflow je tehnički tačan, ali skriva najteži deo sistema. Kripto novčanik nije samo interfejs za potpisivanje transakcija. On je kombinacija identiteta, autorizacije, čuvanja ključeva, recovery politike, mrežne konfiguracije i korisničkog interfejsa za nepovratne operacije.

Kod klasične web aplikacije korisnik može da izgubi lozinku, promeni uređaj i kontaktira podršku. Kod standardnog self-custody novčanika isti događaji mogu značiti trajan gubitak pristupa imovini.

Seed fraza je nastala kao elegantno rešenje za backup determinističkog novčanika. Problem je što smo backup format pretvorili u onboarding mehanizam i od korisnika očekujemo da razume njegove posledice pre nego što je uopšte video vrednost proizvoda.

Tu počinje većina UX problema.

Novi korisnik ne odustaje zato što ne razume kriptografiju. Odustaje zato što mu proizvod, nekoliko sekundi nakon instalacije, saopštava da će jedna greška možda zauvek uništiti njegov nalog. Zatim mu pokazuje dvanaest reči, upozorava ga da ih nikome ne pokaže i nastavlja kao da je upravo rešio problem identiteta.

Nije ga rešio. Samo ga je prebacio na korisnika.

Šta je zapravo seed fraza

Seed fraza nije lozinka i ne predstavlja listu privatnih ključeva. Ona je prenosiva reprezentacija entropije iz koje wallet može deterministički da izvede seed, a zatim čitavo stablo ključeva.

Kod BIP-39 procesa početna entropija ima od 128 do 256 bitova. Na nju se dodaje checksum, rezultat se deli na grupe od po 11 bitova, a svaka grupa postaje indeks u listi od 2.048 reči. Dvanaest reči tipično predstavlja 128 bitova entropije i 4 bita checksuma. Dvadeset četiri reči predstavljaju 256 bitova entropije i 8 bitova checksuma.

Mnemonic se zatim pomoću PBKDF2-HMAC-SHA512 funkcije, sa 2.048 iteracija, pretvara u seed od 512 bitova. BIP-39 podržava i dodatnu passphrase vrednost, ali svaka passphrase proizvodi validan seed. Pogrešna passphrase zato često ne daje jasnu grešku, već potpuno drugi, obično prazan novčanik.

Dobijeni seed može da se koristi kao ulaz za BIP-32 hijerarhijski deterministički wallet. Umesto da aplikacija nezavisno generiše i čuva svaki privatni ključ, iz jednog root materijala izvodi se stablo naloga i adresa.

Pojednostavljeno:

entropija
    -> mnemonic i checksum
    -> BIP-39 seed
    -> BIP-32 master key
    -> derivation path
    -> account
    -> adrese i privatni ključevi

Zbog toga kompromitovanje seed fraze nije isto što i kompromitovanje jedne lozinke. Napadač ne dobija pristup jednoj aplikaciji. Dobija materijal iz kog može ponovo da izvede ključeve, često na drugom uređaju, bez dodatnog odobrenja legitimnog korisnika.

PIN, biometrija i lokalna wallet lozinka najčešće štite aplikaciju ili lokalno šifrovani keystore. Ne menjaju činjenicu da seed može da rekonstruiše wallet izvan tog uređaja.

To je detalj koji korisnički interfejsi često ne objašnjavaju dovoljno jasno.

Zašto je seed fraza istovremeno dobra i loša

Seed fraza ima osobine koje su veoma vredne:

• ne zahteva centralni recovery server

• može da se čuva potpuno offline

• omogućava determinističko izvođenje velikog broja ključeva

• može da posluži za migraciju između kompatibilnih wallet implementacija

• recovery ne zavisi od dostupnosti originalnog proizvođača aplikacije

Za iskusnog korisnika koji razume key management, to je moćan i relativno jednostavan mehanizam.

Problem nastaje kada se ista arhitektura predstavi kao podrazumevano rešenje za svaku vrstu korisnika i svaki iznos.

Seed fraza od korisnika istovremeno zahteva dve suprotne stvari:

• mora da bude dostupna kada dođe do gubitka uređaja

• ne sme da bude dostupna nikome osim vlasniku

Ako je korisnik drži samo na telefonu, nema pravi backup. Ako je sinhronizuje u cloud kao običnu belešku, povećava udaljenu površinu napada. Ako postoji samo na jednom papiru, fizičko oštećenje ili gubitak postaju recovery problem. Ako napravi više kopija, raste broj lokacija koje napadač može da pronađe.

To je bezbednosni problem bez prirodnog odgovora za prosečnog korisnika. Dobro rešenje zavisi od vrednosti imovine, threat modela, uređaja, domaćinstva, nasleđivanja i tolerancije na komplikovan recovery.

Wallet onboarding, međutim, sve to pokušava da završi jednim checkboxom: „Sačuvao sam frazu”.

Mentalni model korisnika je drugačiji od modela protokola

Korisnik u wallet ulazi sa iskustvom drugih aplikacija. Očekuje nalog, lozinku, biometriju i mogućnost resetovanja pristupa.

Self-custody sistem ima drugačiju semantiku:

Istraživanje predstavljeno na konferenciji CHI 2025, koje je uključilo intervjue i anketu sa 643 ispitanika, pokazalo je ozbiljna nerazumevanja seed fraza. Deo učesnika smatrao je da su username i password dovoljni za migraciju walleta na novi uređaj, a mnogi su seed frazu tretirali kao lozinku koju mogu sami da izaberu ili kasnije resetuju.

To nije problem koji se može rešiti dužim tekstom ispod input polja. Ako arhitektura zahteva da korisnik razume key derivation kako bi bezbedno završio onboarding, proizvod je postavio pogrešan nivo apstrakcije.

UX zamka broj jedan: odgovornost dolazi pre vrednosti

Tipičan non-custodial onboarding traži od korisnika da uradi najodgovorniju stvar u celom životnom ciklusu naloga pre nego što je video šta proizvod radi.

Korisnik još nema sredstva. Nije izvršio transakciju. Ne zna da li će se vratiti u aplikaciju. Ipak mora da:

• razume da seed nije lozinka

• napravi backup

• proceni bezbednost mesta na kom ga čuva

• potvrdi redosled reči

• prihvati posledice trajnog gubitka

To je obrnuto od dobrog product flowa.

U dobrom onboardingu korisnik prvo dobija minimalnu vrednost, zatim postepeno ulaže više poverenja i truda. Kod seed-first walleta najveći kognitivni i bezbednosni trošak dolazi na samom početku.

Preskakanje backupa nije dobro rešenje. Forsiranje backupa pre prve korisne akcije takođe nije dobro rešenje. Problem se ne rešava izborom boljeg modalnog prozora, već drugačijom arhitekturom naloga i progresivnim povećavanjem bezbednosti.

UX zamka broj dva: wallet lozinka stvara lažan osećaj recoveryja

Mnogi walleti traže lokalnu lozinku odmah nakon kreiranja seed fraze. Korisnik zato prirodno zaključuje da ta lozinka pripada njegovom nalogu.

U praksi ona često samo šifruje lokalni vault ili kontroliše pristup wallet aplikaciji na tom uređaju.

Posledice postaju vidljive tek nakon problema:

• korisnik instalira wallet na novom uređaju i otkriva da lozinka nije dovoljna

• briše browser profil i gubi lokalno sačuvane podatke

• menja telefon i očekuje standardni login

• kontaktira podršku verujući da postoji serverski reset

• nalazi seed backup, ali ne zna derivation path ili dodatnu passphrase

Dobro dizajniran wallet mora eksplicitno da razdvoji najmanje tri pojma:

1. otključavanje aplikacije

2. autorizaciju transakcije

3. rekonstrukciju naloga na novom uređaju

Ako iste vizuelne obrasce koristimo za sva tri događaja, korisnik će ih smatrati istim bezbednosnim slojem.

UX zamka broj tri: „Connect wallet” nije login

Za developera je wallet konekcija često zamena za OAuth dugme. Korisnik poveže adresu, backend dobije potpis i aplikacija kreira sesiju.

Ali wallet konekcija nije stabilan identitet bez dodatnih pravila.

Korisnik može da:

• promeni aktivni account

• promeni mrežu

• isključi wallet sa sajta

• poveže istu adresu preko drugog providera

• koristi smart account čija se autorizaciona politika kasnije promeni

• koristi različite adrese na različitim mrežama

EIP-1193 zato standardizuje događaje kao što su accountsChanged, chainChanged, connect i disconnect. Aplikacija koja pročita adresu samo prilikom mountovanja komponente i zatim je tretira kao trajni identitet implementirala je happy path, ne wallet integraciju.

Minimalna reakcija na promene može da izgleda ovako:

type RequestArguments = {
    method: string;
    params?: unknown[] | Record<string, unknown>;
};

type Eip1193Provider = {
    request(args: RequestArguments): Promise<unknown>;
    on(event: string, listener: (...args: unknown[]) => void): void;
    removeListener(
        event: string,
        listener: (...args: unknown[]) => void
    ): void;
};

export function observeWallet(
    provider: Eip1193Provider,
    onInvalidate: () => void
) {
    const handleAccountsChanged = () => onInvalidate();
    const handleChainChanged = () => onInvalidate();
    const handleDisconnect = () => onInvalidate();

    provider.on("accountsChanged", handleAccountsChanged);
    provider.on("chainChanged", handleChainChanged);
    provider.on("disconnect", handleDisconnect);

    return () => {
        provider.removeListener(
            "accountsChanged",
            handleAccountsChanged
        );
        provider.removeListener("chainChanged", handleChainChanged);
        provider.removeListener("disconnect", handleDisconnect);
    };
}

Važna ideja nije konkretan framework. Važno je da svaka promena accounta ili chaina poništava pretpostavke prethodne sesije.

Ako aplikacija koristi potpis kao login, challenge treba da bude jednokratan, vremenski ograničen i vezan za očekivani domen, adresu i mrežni kontekst. Potpisivanje proizvoljnog stringa nije zamena za pažljivo dizajniran authentication protokol.

UX zamka broj četiri: korisnik ne potpisuje ono što vidi

Korisnik obično vidi dugme „Kupi”, „Mintuj”, „Potvrdi” ili „Nastavi”. Wallet zatim može da prikaže:

• hex podatke

• adresu ugovora

• nepoznat method selector

• procenjeni gas

• token approval

• typed data poruku

• upozorenje da simulacija nije dostupna

Iz ugla protokola, korisnik autorizuje precizno definisanu operaciju. Iz ugla korisnika, potpisuje posledicu opisanu u aplikaciji.

Razlika između te dve reprezentacije je prostor u kom nastaju phishing, approval prevare i nenamerne transakcije.

Najopasniji UI nije nužno onaj koji prikazuje premalo podataka. Interfejs može da prikaže mnogo tehničkih detalja i da i dalje ne objasni posledicu.

Korisniku je važnije:

• koja sredstva mogu da napuste nalog

• ko ih dobija

• da li je approval ograničen ili neograničen

• da li operacija važi jednom ili ostaje aktivna

• na kojoj mreži se izvršava

• da li se akcija može opozvati

• šta će se dogoditi ako deo batcha ne uspe

Wallet confirmation treba tretirati kao bezbednosni proizvod, ne kao JSON viewer.

UX zamka broj pet: mreža i gas cure kroz apstrakciju

Za korisnika koji prvi put koristi onchain aplikaciju, mreža je uglavnom implementacioni detalj. Za aplikaciju je ona deo identiteta stanja, adresa, tokena i transakcije.

Otuda poznat onboarding scenario:

1. korisnik ima odgovarajući token

2. token je na pogrešnoj mreži

3. wallet nema native asset za gas

4. aplikacija traži promenu mreže

5. wallet prikazuje novo upozorenje

6. korisnik dolazi do bridgea

7. bridge uvodi novi potpis, novu naknadu i čekanje

Svaki korak može biti tehnički opravdan. Zajedno predstavljaju proizvod koji od korisnika zahteva da razume infrastrukturu pre nego što obavi osnovnu radnju.

Account abstraction ne uklanja cenu izvršavanja, ali omogućava da se promeni način na koji je korisnik doživljava. Paymaster može da plati gas za UserOperation, aplikacija može da sponzoriše prve akcije, a smart account može da grupiše više poziva.

„Gasless” ipak ne znači da transakcija nema cenu. Znači da trošak nije direktno naplaćen korisniku u native tokenu. Plaća ga aplikacija, paymaster ili neki drugi ekonomski učesnik.

To je važna razlika i za arhitekturu i za poslovni model.

Zašto početnici odustaju

Početnik retko odustaje zbog jedne katastrofalne UX greške. Češće odustaje zbog niza malih trenutaka u kojima aplikacija traži odluku bez dovoljno konteksta.

Tipičan niz izgleda ovako:

• ne zna koji wallet da izabere

• browser prijavljuje više instaliranih providera

• nije siguran da li „connect” daje aplikaciji pristup sredstvima

• dobija adresu koju ne može da proveri pogledom

• mora da izabere mrežu

• nema token za gas

• potpisuje poruku čiju svrhu ne razume

• transakcija ostaje u stanju „pending”

• explorer izgleda kao interna developerska alatka

• podrška ne može da poništi operaciju

U klasičnoj aplikaciji neizvesnost se često rešava pokušajem. Korisnik klikne, vrati se nazad ili resetuje stanje.

Kod kripto novčanika UI istovremeno poručuje dve stvari:

• „Ne brini, jednostavno je.”

• „Ako pogrešiš, sredstva možda neće moći da se vrate.”

Ta kontradikcija proizvodi paralizu, ne poverenje.

Seedless ne znači trustless, niti automatski bezbednije

Industrija često koristi termin „seedless wallet”, ali on više opisuje korisničko iskustvo nego precizan trust model.

Seed može biti zamenjen različitim sistemima:

• passkey credentialom

• smart account validatorom

• MPC ili threshold signing protokolom

• višestrukim uređajima

• guardian recoveryjem

• cloud backupom šifrovanog key sharea

• custodial servisom

• kombinacijom navedenih mehanizama

Svaka opcija premešta poverenje. Nijedna ga magično ne uklanja.

Pravo pitanje zato nije: „Da li wallet ima seed frazu?”

Bolja pitanja su:

• ko može da autorizuje transakciju

• šta se događa kada korisnik izgubi telefon

• može li jedna kompromitovana strana da preuzme nalog

• može li recovery servis da odbije oporavak

• može li korisnik da promeni recovery politiku

• postoji li izlaz iz sistema bez dozvole provajdera

• može li se ključ ili account migrirati

• koje komponente moraju biti dostupne da bi korisnik trošio sredstva

To je threat model koji developer treba da razume pre nego što izabere wallet SDK.

Passkeys: bolji UX, drugačiji rizici

Passkey koristi WebAuthn public-key credential. Privatni ključ generiše i čuva authenticator, dok relying party dobija javni ključ i potpisane authentication assertion podatke. Credential je vezan za relying party kontekst, a korisnik ga najčešće aktivira biometrijom, PIN-om uređaja ili security keyem.

Za korisnika to može da izgleda kao poznata sistemska potvrda:

Potvrdi pomoću Face ID-a

Iza tog ekrana nalazi se asimetrična kriptografija, ali korisnik ne mora da prepisuje root secret na papir.

To rešava nekoliko seed problema:

• nema reči koje korisnik može da pošalje phishing sajtu

• privatni ključ ne mora da bude dostupan JavaScript aplikaciji

• autorizacija može da koristi secure hardware uređaja

• onboarding koristi poznat sistemski interfejs

• credential može da zahteva user verification

Ali uvodi nove probleme:

• WebAuthn credential je vezan za relying party i origin pravila

• sinhronizacija passkeya zavisi od platforme i korisničkog naloga

• cross-device recovery zavisi od izabranog authenticator modela

• promena domena ili infrastrukture mora biti pažljivo planirana

• browser i mobilne aplikacije mogu zahtevati različite integracione tokove

• passkey sam po sebi ne definiše onchain recovery politiku

Passkeys obično koriste P-256, odnosno secp256r1, dok tradicionalni Ethereum EOA potpisi koriste secp256k1. Smart account može da implementira P-256 ili WebAuthn verifikaciju, a mreže koje podržavaju odgovarajući precompile mogu to raditi efikasnije. Podrška nije identična na svakoj mreži, pa je treba proveravati, ne pretpostavljati.

Passkey zato nije drop-in zamena za EOA privatni ključ. On postaje naročito koristan kada account ima programabilnu verifikacionu logiku.

Smart accounts: recovery kao deo aplikacione logike

Externally owned account, EOA, tradicionalno je kontrolisan jednim privatnim ključem. Ko ima ključ, može da potpisuje. Ko ga izgubi, gubi kontrolu.

Smart account menja tu pretpostavku. Autorizacija više ne mora da bude fiksirana na jednu ECDSA proveru. Account može da definiše:

• više signera

• threshold pravila

• passkey verifikaciju

• dnevne ili pojedinačne limite

• vremenski zaključan recovery

• guardians

• session ključeve ograničenog opsega

• batch izvršavanje

• pravila za sponzorisanje gasa

ERC-4337 uvodi UserOperation, bundlere, EntryPoint i opcione paymastere bez potrebe da osnovni Ethereum konsenzus bude izmenjen za svaki wallet feature.

Pojednostavljen tok izgleda ovako:

flowchart LR
    A[Korisnik potvrđuje akciju] --> B[Wallet kreira UserOperation]
    B --> C[Signer ili passkey potpisuje]
    C --> D[Bundler proverava i grupiše operacije]
    D --> E[EntryPoint poziva smart account]
    E --> F[Account validira potpis i politiku]
    F --> G[Izvršava se poziv]
    P[Paymaster] --> D

Ovo ne uklanja potrebu za ključevima. Uklanja pretpostavku da jedan nepromenljivi ključ mora zauvek biti kompletan identitet naloga.

EIP-7702 rešava srodan, ali drugačiji problem. Omogućava EOA nalogu da delegira izvršavanje kodu i time dobije deo ponašanja programabilnog naloga. Međutim, delegacija sama po sebi ne uklanja rizik originalnog EOA ključa. Ako seed ostaje root autoritet za novu delegaciju, njegov kompromis i dalje može imati ozbiljne posledice.

MPC i threshold signing: nema jednog kompletnog ključa

Kod MPC ili threshold signing arhitekture, potpisivanje je raspodeljeno između više učesnika ili uređaja. Ideja je da jedna komponenta ne mora sama da poseduje kompletan privatni ključ dovoljan za autorizaciju.

Praktičan sistem može, na primer, koristiti:

• jedan share na korisnikovom uređaju

• jedan recovery share u zaštićenom servisu

• jedan dodatni share na drugom uređaju ili kod organizacije

Određeni prag učesnika zajednički proizvodi validan potpis.

To može da smanji rizik od jednog ukradenog fajla ili jednog kompromitovanog uređaja. Ipak, „MPC” ne govori dovoljno o modelu kontrole.

Dva proizvoda mogu koristiti sličnu kriptografiju, a imati potpuno različite osobine:

• u jednom korisnik kontroliše dovoljan broj shareova

• u drugom je servis neophodan za svaku transakciju

• treći dozvoljava export ili rekonstrukciju

• četvrti vezuje recovery za proveru identiteta

• peti može da zamrzne ili odbije potpisivanje

Zato MPC ne treba automatski izjednačavati sa self-custodyjem. Važno je ko kontroliše shareove, kako izgleda recovery, postoji li vendor-independent izlaz i šta se događa kada provajder nestane.

Realan use-case: loyalty aplikacija bez kripto rituala

Zamislimo loyalty aplikaciju u kojoj korisnik dobija digitalni membership asset nakon prve kupovine.

Blockchain može imati smisla ako je potrebno da asset bude prenosiv, proverljiv izvan originalne aplikacije ili upotrebljiv kod više partnera. Korisnik, međutim, ne dolazi zbog blockchaina. Dolazi zbog popusta, pristupa događaju ili statusa članstva.

Klasičan flow bi mogao da izgleda ovako:

1. instaliraj ekstenziju

2. napravi wallet

3. zapiši seed frazu

4. vrati se na aplikaciju

5. poveži wallet

6. promeni mrežu

7. nabavi native token

8. potvrdi mint

9. sačekaj finalizaciju

Svaki korak je tehnički razumljiv. Ceo workflow je proizvodno neprihvatljiv za korisnika koji želi membership karticu.

Alternativna arhitektura:

1. korisnik otvara aplikaciju

2. kreira passkey sistemskim dijalogom

3. backend registruje javni credential i povezuje ga sa profilom

4. aplikacija izračunava ili kreira smart account

5. korisnik potvrđuje izdavanje membership asseta

6. paymaster sponzoriše inicijalnu operaciju

7. bundler šalje UserOperation

8. aplikacija prikazuje rezultat u jeziku proizvoda

9. dodatni recovery metod podešava se pre povećanja vrednosti naloga

Korisnik je i dalje vlasnik onchain accounta ako je sistem tako dizajniran. Razlika je u tome što nije morao da nauči infrastrukturu pre prve korisne radnje.

Gde recovery ulazi u workflow

Recovery ne bi trebalo potpuno odlagati. Treba ga proporcionalno uvoditi.

Moguća politika:

Ovo je isti princip koji koriste ozbiljni finansijski sistemi: rizik operacije određuje potrebnu jačinu autentikacije.

Kripto aplikacije često rade suprotno. Zahtevaju maksimalnu ceremoniju za prazan nalog, a zatim dozvole veoma rizičan potpis kroz isti confirmation ekran.

Kako bi developer trebalo da bira wallet model

Ne postoji univerzalno najbolja wallet arhitektura. Izbor zavisi od proizvoda i vrednosti koja će se nalaziti na nalogu.

Najveća greška je izabrati model prema najlakšem SDK quickstartu.

Wallet infrastruktura ostaje deo proizvoda mnogo duže od inicijalne integracije. Menjanje account modela nakon što korisnici već imaju sredstva zahteva migraciju, novu autorizaciju, kompatibilnost sa postojećim protokolima i pažljivu komunikaciju.

Kako integracija izgleda u praksi

Kod passkey smart account sistema potrebno je posmatrati najmanje pet slojeva.

1. Credential sloj

Ovaj sloj kreira i koristi passkey. Browser ili mobilna platforma komunicira sa authenticatorom, dok aplikacija čuva credential ID, javni ključ i potrebne metapodatke.

Privatni ključ ne bi trebalo da napušta authenticator.

2. Account sloj

Smart contract definiše ko može da potpisuje i koja pravila važe. To može biti jedan P-256 signer, kombinacija signera ili modularni sistem validatora i recovery pravila.

Ovde nastaje najveći deo bezbednosnog rizika specifičnog za proizvod. Greška u account kodu ne pogađa samo jednu transakciju, već autorizacioni model svih korisnika te implementacije.

3. Transport i bundler sloj

Kod ERC-4337 arhitekture UserOperation se šalje bundleru. Bundler simulira validaciju, grupiše operacije i poziva EntryPoint.

Aplikacija mora pravilno da razlikuje najmanje:

• lokalnu grešku pri pripremi

• neuspešnu simulaciju

• odbijanje potpisa

• odbijanje paymastera

• bundler grešku

• onchain revert

• operaciju koja je poslata, ali još nije uključena

• operaciju uključenu u reorganizovan blok

Jedna generička poruka „Transaction failed” nije dovoljna za podršku niti za debugging.

4. Sponsorship sloj

Paymaster odlučuje koje operacije želi da finansira. U realnom sistemu to obično zahteva pravila kao što su:

• maksimalan broj sponzorisanih akcija

• dozvoljeni target ugovori

• dozvoljeni function selectori

• maksimalna vrednost operacije

• zaštita od replaya i automatizovane zloupotrebe

• budžet po korisniku ili vremenskom periodu

Paymaster koji potpisuje proizvoljan calldata nije onboarding alat. On je javno dostupan budžet bez dobre kontrole trošenja.

5. Recovery sloj

Recovery je odvojena funkcionalnost, ne sekundarni login ekran.

Potrebno je definisati:

• uslove za pokretanje recoveryja

• učesnike koji ga odobravaju

• vremensko kašnjenje

• način otkazivanja zlonamernog zahteva

• obaveštenja na postojećim uređajima

• rotaciju starog signera

• ponašanje aktivnih session ključeva

• audit trag promene autorizacije

Ako je recovery lakši od obične prijave, postaje najlakši put za napadača. Ako je previše težak, ne rešava problem gubitka uređaja.

Session ključevi menjaju UX, ali povećavaju odgovornost

Aplikacija koja traži biometrijsku potvrdu za svaki mali potez u igri ili svaku loyalty akciju brzo postaje neupotrebljiva.

Smart account može da dozvoli privremeni session ključ sa ograničenim pravima, na primer:

• važi 30 minuta

• može da poziva samo jedan ugovor

• može da koristi samo određene funkcije

• ne može da prenosi tokene

• ima maksimalni ukupni limit

• može biti opozvan glavnim signerom

To omogućava UX bliži normalnoj aplikaciji bez davanja neograničenog pristupa session ključu.

Ali implementacija mora da proverava ograničenja onchain ili kroz pouzdanu account politiku. Frontend provera nije bezbednosna granica. Ako privatni session ključ može da kreira proizvoljan calldata, UI ograničenje nema značaj nakon kompromitovanja klijenta.

Koliko ovakav sistem košta

Ne postoji jedna cena kripto novčanika. Trošak se sastoji od više kategorija, a deo koji korisnik ne vidi i dalje neko plaća.

Onchain trošak

Smart account operacije mogu uključiti:

• deployment accounta

• validaciju potpisa

• EntryPoint izvršavanje

• paymaster validaciju

• dodatni calldata

• batch izvršavanje

• recovery i rotaciju signera

Trošak zavisi od mreže, account implementacije, vrste potpisa i sadržaja operacije.

L2 mreže uglavnom smanjuju cenu u odnosu na Ethereum L1, ali trošak nije nula i može zavisiti od cene objavljivanja podataka na osnovni sloj.

Sponsorship budžet

Ako proizvod nudi gasless onboarding, potrebno je pratiti:

• prosečan trošak aktiviranog korisnika

• odnos sponzorisanih i uspešnih operacija

• bot i Sybil aktivnost

• broj ponovljenih neuspešnih pokušaja

• trošak po zadržanom korisniku

• maksimalnu dnevnu obavezu paymastera

Sponzorisanje prve vredne akcije često ima više smisla od sponzorisanja svakog klika bez ograničenja.

Infrastruktura

Managed rešenja mogu naplaćivati:

• kreiranje ili broj aktivnih walleta

• potpisivanje

• bundler zahteve

• paymaster servis

• RPC saobraćaj

• MPC ili HSM operacije

• analitiku i monitoring

• enterprise podršku

Cene se menjaju i razlikuju među provajderima, pa ih treba proveriti neposredno pre arhitektonske odluke. Važnije od početne cene je pitanje šta se događa sa postojećim accountima ako se provajder promeni.

Audit i operativna bezbednost

Custom smart account, recovery modul i paymaster uvode kod koji kontroliše sredstva ili budžet. Trošak zato uključuje:

• eksterni audit

• interne review procese

• monitoring

• incident response

• upravljanje upgrade ključevima

• testiranje migracije

• testiranje recoveryja

• održavanje nakon promene mrežnih standarda

Najjeftiniji wallet SDK može biti veoma skup ako korisnički account ne može bezbedno da napusti njegov ekosistem.

Trade-off koji account abstraction ne uklanja

Programabilni nalozi rešavaju deo UX problema, ali dodaju nove failure modove.

Kod EOA modela glavni problem je ključ. Kod smart accounta problem može biti bilo koja od sledećih komponenti:

• signer

• validator modul

• recovery modul

• proxy ili upgrade mehanizam

• factory

• bundler dostupnost

• paymaster politika

• frontend koji konstruiše operaciju

• servis koji čuva credential metapodatke

To ne znači da je EOA bezbedniji. Znači da je smart account složeniji sistem koji zahteva ozbiljnije inženjerstvo.

Account abstraction je alat za izražavanje boljih bezbednosnih pravila. Ne garantuje da će ta pravila biti dobra.

Šta treba meriti tokom razvoja

Wallet funnel ne treba meriti samo kroz broj konekcija.

Korisnije metrike su:

• procenat korisnika koji razumeju šta se upravo kreira

• uspešnost prve onchain akcije

• vreme do prve korisne akcije

• broj promene mreže pre uspeha

• procenat odbijenih potpisa

• broj neuspešnih simulacija

• procenat korisnika bez sredstava za gas

• uspešnost dodavanja drugog recovery faktora

• uspešnost recovery testa

• procenat korisnika koji umeju da razlikuju lokalni PIN od recovery metoda

• broj support zahteva po aktiviranom walletu

Važno je testirati i neuspešne tokove.

Pitajte test korisnika da:

• promeni uređaj

• izgubi pristup glavnom passkeyu

• poveže pogrešan account

• ostane bez gasa

• odbije potpis

• promeni mrežu tokom procesa

• pokrene recovery

• otkaže zlonameran recovery

• objasni šta će se dogoditi pre nego što potvrdi operaciju

Happy path pokazuje da integracija radi. Failure path pokazuje da li proizvod može bezbedno da se koristi.

Praktična pravila za bolji wallet UX

Ne prikazuj seed bez stvarne potrebe

Ako proizvod zahteva seed, objasni njegovu funkciju pre prikazivanja, ne samo zabranu deljenja. Nemoj ga prikazivati u analytics događajima, logovima, crash reportovima, screenshot previewju ili clipboard flowu bez jasnog razloga.

Ne nazivaj lokalnu lozinku „wallet recovery” mehanizmom

Korisnik mora jasno da zna šta lozinka štiti i šta ne može da oporavi.

Prikaži posledicu potpisa

Umesto „Sign message”, prikaži nameru:

• prijavljuješ se na ovaj domen

• odobravaš trošenje do određenog iznosa

• prenosiš konkretan asset

• aktiviraš session do određenog vremena

• dodaješ novi recovery uređaj

Wallet i aplikacija treba da se slažu oko iste semantike.

Smanji broj odluka, ne količinu bezbednosti

Sakrivanje mreže ima smisla ako je aplikacija može bezbedno odabrati. Skrivanje recipienta ili iznosa nema.

Dobra apstrakcija uklanja odluke koje korisnik ne mora da donese, ali zadržava vidljivost posledica.

Recovery testiraj pre nego što postane potreban

Recovery koji nikada nije testiran samo je teorija. Korisniku se može ponuditi simulacija ili kontrolisani test dodavanja novog uređaja bez izlaganja stvarnih sredstava.

Dizajniraj izlaz pre ulaza

Pre integracije proveri:

• može li korisnik da izveze ili migrira kontrolu

• može li promeniti wallet provajdera

• šta ostaje funkcionalno bez originalnog frontenda

• postoji li dokumentovan recovery bez vendor podrške

• može li account promeniti signer

• ko kontroliše upgrade

Ako izlaz ne postoji, proizvod možda ne nudi self-custody, već nalog vezan za određenu infrastrukturu.

Seed fraza nije zastarela, ali više nije dovoljan odgovor

Seed fraza rešava konkretan kriptografski i operativni problem: kako preneti dovoljno materijala da se deterministički wallet ponovo izvede bez centralnog servera.

Ona ne rešava sama po sebi:

• bezbedno čuvanje

• krađu kroz phishing

• gubitak uređaja

• nasleđivanje

• promenu autorizacione politike

• ograničenje sesije

• potpisivanje razumljivo ljudima

• gas onboarding

• zaštitu od greške korisnika

Najvažnija promena u modernom wallet dizajnu nije nestanak ključeva. Ključevi su i dalje tu. Promena je u tome što jedan root secret više ne mora da bude jedina nepromenljiva granica između korisnika i trajnog gubitka.

Passkeys donose poznatu i hardverski podržanu autorizaciju. Smart accounts omogućavaju programabilna pravila i rotaciju signera. MPC raspodeljuje kontrolu između više komponenti. Paymasteri menjaju način plaćanja transakcija. Session ključevi smanjuju broj prekida tokom upotrebe.

Svaki od tih mehanizama ima cenu i novi trust model. Ipak, daju developeru nešto što klasičan seed-only wallet nema: prostor da bezbednost prilagodi riziku konkretne operacije.

Najbolji wallet UX zato nije onaj koji korisniku objašnjava blockchain sa najviše strpljenja. Najbolji wallet UX je onaj koji od korisnika ne zahteva da postane stručnjak za key management kako bi bezbedno uradio jednostavnu stvar.

Za developera, koristan početni eksperiment nije još jedan „Connect wallet” ekran. Korisnije je napraviti mali prototip sa passkey signerom, smart accountom, jednom sponzorisanom akcijom i stvarnim recovery scenarijem. Tek kada recovery radi na izgubljenom uređaju, može se reći da je napravljen novčanik, a ne samo interfejs za happy path.

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti i prodati USDT i USDC. Više informacija nalazi se na stranici Volet za korisnike iz Srbije. Za otvaranje naloga koristi Volet referral link. Link je referral link autora članka.

Izvori

1. BIP-39: Mnemonic code for generating deterministic keys

2. BIP-32: Hierarchical Deterministic Wallets

3. Of Secrets and Seedphrases: Conceptual Misunderstandings and Security Challenges for Seed Phrase Management among Cryptocurrency Users

4. EIP-1193: Ethereum Provider JavaScript API

5. ERC-4337: Account Abstraction Using Alt Mempool

6. Web Authentication: An API for accessing Public Key Credentials, Level 3

7. EIP-7951: Precompile for secp256r1 Curve Support

8. EIP-7702: Set Code for EOAs

9. Ethereum.org: Account abstraction

10. OpenZeppelin Contracts: WebAuthn Smart Accounts

11. EIP-5792: Wallet Call API

12. EIP-6963: Multi Injected Provider Discovery

13. Volet Srbija

English version: Read on Dev.to: Crypto Wallets: Seed Phrases and UX Traps for Developers

To je dobar početak, ali loš završetak objašnjenja.

Iz perspektive jednostavnog Solidity ugovora, ove mreže zaista izgledaju slično. Koriste ETH za gas, podržavaju Ethereum JSON-RPC, rade sa Foundryjem, Hardhatom, viem i ethers bibliotekama, a korisnik ih obično dodaje u isti wallet.

Ispod tog interfejsa nalaze se različiti sistemi.

Arbitrum One koristi Nitro arhitekturu i sopstveni rollup protokol. OP Mainnet koristi OP Stack, skup modularnih komponenti za pokretanje optimistic rollupa. Base je takođe napravljen na OP Stacku, ali je zasebna mreža sa svojim stanjem, sekvencerom, ekonomijom, korisnicima i dodatnim infrastrukturnim slojevima.

Zbog toga ovo nije poređenje tri RPC endpointa.

Praktična pitanja su:

• kako svaka mreža formira i potvrđuje blokove

• ko određuje redosled transakcija

• kako se stanje može proveriti preko Ethereuma

• od čega se sastoji transakciona naknada

• koliko traje povlačenje sredstava na Ethereum

• koje mrežne specifičnosti ulaze u aplikacioni kod

• za kakav proizvod svaka mreža ima smisla

Dokumentacija i tehnički detalji navedeni u članku provereni su 21. septembra 2026.

Šta Ethereum Layer 2 zapravo radi

Ethereum L1 obezbeđuje izvršavanje, konsenzus i dostupnost podataka, ali je prostor u bloku ograničen. Kada mnogo korisnika želi da pošalje transakciju, oni se kroz gas cenu nadmeću za isti resurs.

Optimistic rollup razdvaja izvršavanje od konačnog poravnanja.

U pojednostavljenom obliku tok izgleda ovako:

1. Korisnik potpisuje L2 transakciju.

2. Sekvencer prihvata transakciju i određuje njeno mesto u redosledu.

3. Transakcija se izvršava u L2 okruženju.

4. Korisnik brzo dobija L2 potvrdu.

5. Podaci potrebni za rekonstrukciju L2 lanca objavljuju se na Ethereumu.

6. Rollup protokol objavljuje tvrdnje o L2 stanju.

7. Neispravno stanje može biti osporeno prema pravilima protokola.

Aplikacija dobija brzo izvršavanje, dok Ethereum služi kao sloj za dostupnost podataka, proveru i konačno poravnanje.

Iz toga sledi da L2 transakcija nema samo jedan status.

Transakcija može biti:

• prihvaćena od sekvencera

• uključena u L2 blok

• objavljena kao deo podataka na Ethereumu

• izvedena iz potvrđenih L1 podataka

• povezana sa finalizovanim Ethereum blokom

Za društvenu aplikaciju može biti dovoljno da transakcija bude uključena na L2. Za veliki withdrawal, kreditiranje kolaterala ili treasury operaciju potreban je stroži kriterijum.

To je zajednička osnova Arbitrum, Optimism i Base mreže. Implementacija te osnove nije ista.

Arbitrum: Nitro kao poseban rollup sistem

Arbitrum nije naziv jednog blockchaina.

Arbitrum ekosistem obuhvata više mreža i tehnologija, ali za standardni dApp deployment najvažniji je Arbitrum One, optimistic rollup koji koristi Nitro arhitekturu.

Arbitrum One mainnet koristi chain ID 42161, Arbitrum Sepolia koristi 421614, a gas se plaća u ETH. ARB je governance token i ne koristi se kao nativni gas asset.

Za EVM developera početno iskustvo izgleda poznato:

• Solidity ugovori

• Ethereum ABI

• standardni događaji i logovi

• eth_call

• eth_estimateGas

• eth_sendRawTransaction

• ERC-20, ERC-721 i ERC-1155

• Foundry i Hardhat

• standardni wallet adapteri

Ipak, Arbitrum One nije samo Geth instanca sa kraćim blokovima.

Kako radi Arbitrum Nitro

Nitro je druga generacija Arbitrum rollup arhitekture. Njegov izvršni sloj zasnovan je na Ethereum kompatibilnom execution engineu, dok ArbOS dodaje funkcije potrebne za rad L2 sistema.

Arhitektura se može posmatrati kroz nekoliko delova:

• sekvencer prima i uređuje korisničke transakcije

• execution engine izvršava EVM operacije

• ArbOS obrađuje L2 specifične funkcije

• batch poster objavljuje podatke na Ethereum

• validator proverava izvedeno stanje

• rollup protokol rešava eventualne sporove

Sekvencer omogućava brzo korisničko iskustvo. Kada prihvati transakciju, aplikacija može skoro odmah dobiti receipt i prikazati rezultat.

Međutim, sekvencerova potvrda nije isto što i Ethereum finalnost.

Podaci o transakciji moraju postati dostupni preko L1, a stanje mora proći kroz rollup protokol. Zbog toga backend ne bi trebalo da koristi samo boolean vrednost confirmed.

Korisniji model je:

sequenced -> posted_to_l1 -> confirmed -> finalized

Aplikacija ne mora svako od ovih stanja da prikazuje korisniku. Interno ipak treba da zna šta smatra dovoljnim nivoom sigurnosti.

Zašto ArbOS postoji

Na Ethereumu execution client izvršava transakcije prema pravilima Ethereum protokola. Arbitrumu su potrebna dodatna pravila za L1 i L2 komunikaciju, obračun troškova podataka, sistemske poruke i upravljanje rollup okruženjem.

Ta pravila obezbeđuje ArbOS.

Za većinu Solidity ugovora ArbOS ostaje nevidljiv. Ugovor i dalje vidi msg.sender, msg.value, storage, calldata i standardne EVM operacije.

ArbOS postaje važan kada aplikacija:

• procenjuje L1 komponentu naknade

• šalje poruke između Arbitrum mreže i Ethereuma

• proverava L1 podatke iz L2 ugovora

• koristi Arbitrum sistemske precompile ugovore

• radi sa retryable ticket mehanizmom

• zavisi od posebnih svojstava Arbitrum lanca

Čim ugovor direktno koristi Arbitrum sistemski interfejs, više nije potpuno prenosiv na drugu EVM mrežu.

To nije nužno problem. Problem je kada tim tu zavisnost ne tretira kao arhitektonsku odluku.

Retryable tickets i L1 prema L2 poruke

Slanje obične transakcije direktno na Arbitrum One nije isto što i slanje poruke sa Ethereum L1 mreže ka Arbitrumu.

Za L1 prema L2 komunikaciju Arbitrum koristi retryable tickets. Oni predstavljaju poruke koje treba izvršiti na L2, uz parametre kao što su:

• ciljna L2 adresa

• calldata

• vrednost koja se šalje

• sredstva za L2 gas

• refund adrese

• ograničenje gasa

Korisnik ili aplikacija najčešće ne treba ručno da implementira ceo protokol. Zvanični bridge alati i SDK apstrakcije postoje upravo zato što pogrešna procena gasa ili pogrešna refund adresa mogu ostaviti poruku neizvršenom.

Važna posledica je da L1 prema L2 operacija ima najmanje dva relevantna događaja:

1. transakcija je prihvaćena na Ethereumu

2. odgovarajuća poruka je izvršena na Arbitrumu

Backend koji prati samo L1 receipt može prerano zaključiti da je čitava operacija završena.

Koliko košta transakcija na Arbitrumu

Arbitrum transakciona naknada ima dve osnovne komponente:

• trošak izvršavanja na Arbitrumu

• trošak objavljivanja podataka na Ethereumu

L2 deo zavisi od količine gasa koju EVM izvršavanje potroši i trenutne Arbitrum gas cene.

L1 deo zavisi od količine podataka koje transakcija dodaje rollup batchu i trenutnog troška objavljivanja tih podataka. ArbOS u procenu uključuje očekivani trošak L1 data komponente.

Zbog kompresije batcha dve transakcije sa sličnom količinom calldata podataka ne moraju proizvesti potpuno isti efektivni trošak.

Zato nije dovoljno računati:

gasUsed * gasPrice

i pretpostaviti da je to kompletno objašnjenje ekonomije transakcije.

Za slanje standardne transakcije wallet i biblioteka uglavnom će dobiti odgovarajuću procenu preko RPC-a. Poseban obračun postaje važan kada aplikacija:

• sponzoriše korisnički gas

• prikazuje fee breakdown

• poredi cenu operacija između mreža

• planira veliki broj automatizovanih transakcija

• koristi sopstveni relayer

Cena nije fiksna i ne treba je hardkodovati u korisničkom interfejsu.

Povlačenje sredstava sa Arbitrum One mreže

Deposit sa Ethereuma na Arbitrum i withdrawal sa Arbitrum mreže na Ethereum nisu simetrične operacije.

L1 prema L2 deposit može se završiti relativno brzo nakon Ethereum transakcije i izvršavanja odgovarajuće L2 poruke.

Standardni L2 prema L1 withdrawal prolazi kroz duži proces:

1. korisnik inicira withdrawal na Arbitrumu

2. L2 poruka se registruje u stanju mreže

3. odgovarajuća tvrdnja o stanju objavljuje se na Ethereumu

4. prolazi period u kojem stanje može biti osporeno

5. poruka postaje izvršiva na L1

6. korisnik ili relayer izvršava završnu L1 transakciju

U standardnom optimistic toku treba računati na približno sedam dana pre završnog izvršenja na Ethereumu.

Fast bridge može korisniku isplatiti sredstva ranije, ali tada korisnik ne preskače protokolsko čekanje. Dobavljač likvidnosti preuzima čekanje i naplaćuje uslugu.

Stylus menja programski sloj, ne samo sintaksu

Arbitrum Stylus omogućava pisanje smart contracta u jezicima kao što su Rust, C i C++, uz kompajliranje u WebAssembly i interoperabilnost sa EVM ugovorima.

To otvara nekoliko mogućnosti:

• korišćenje Rust tipova i ekosistema

• ponovna upotreba dela postojećeg koda

• efikasnije izvršavanje pojedinih računskih operacija

• kombinovanje Solidity i Stylus ugovora

Solidity ugovor može pozvati Stylus ugovor, a Stylus ugovor može komunicirati sa EVM contractima.

Ipak, Stylus nije automatski razlog za prepisivanje postojeće aplikacije.

Tim uvodi:

• novi build pipeline

• novi programski model

• dodatnu audit površinu

• manji broj auditora sa specifičnim iskustvom

• nove pretpostavke o alatima i bibliotekama

Stylus ima smisla kada postoji konkretna korist, na primer složenija računarska logika ili postojeći Rust kod koji se može bezbedno prilagoditi smart contract okruženju.

Realan Arbitrum use-case

Arbitrum je prirodan izbor za aplikaciju koja treba da komunicira sa postojećim DeFi protokolima i likvidnošću na Arbitrum One mreži.

Zamislimo automatizovani treasury sistem koji:

1. prima stablecoin uplate

2. deo sredstava menja za drugi asset

3. koristi lending protokol za kratkoročnu likvidnost

4. periodično povlači višak sredstava na Ethereum

5. vodi interni ledger svih operacija

Solidity deo može biti relativno mali. Teži deo je infrastruktura:

• provera tačnih token adresa

• zaštita od slippagea

• praćenje oracle podataka

• indeksiranje događaja

• monitoring pozicija

• razlikovanje L2 potvrde od L1 finalnosti

• upravljanje withdrawal periodom

• održavanje ETH balansa za gas

Prednost Arbitrum mreže u takvom slučaju nije apstraktna tvrdnja da je „brža”. Prednost je postojanje protokola i likvidnosti koje aplikacija zaista koristi.

Arbitrum trade-off

Arbitrum One pruža poznato EVM iskustvo, relativno niske transakcione troškove i pristup razvijenom L2 ekosistemu.

Cena toga je dodatni sistemski sloj.

Developer mora razumeti:

• sekvencer i njegovu dostupnost

• Nitro i ArbOS specifičnosti

• retryable tickets

• L1 i L2 fee komponente

• optimistic withdrawal period

• Arbitrum specifične precompile ugovore

• razliku između sekvencerske potvrde i Ethereum finalnosti

Ako aplikacija koristi samo obične EVM funkcije, većina složenosti može ostati u infrastrukturi. Ako koristi cross-chain poruke i sistemske ugovore, Arbitrum postaje deo poslovne logike.

Optimism: OP Mainnet kao referentni OP Stack chain

Naziv Optimism često se koristi za nekoliko različitih stvari.

• OP Mainnet je konkretna Ethereum L2 mreža.

• OP Stack je skup softverskih komponenti za izgradnju L2 mreža.

• Optimism Collective je širi governance i finansijski sistem.

• Superchain je ekosistem OP Stack mreža koje usvajaju zajedničke standarde.

Kada aplikacija izvršava transakciju na „Optimismu”, ona u praksi najčešće koristi OP Mainnet.

OP Mainnet ima chain ID 10, OP Sepolia koristi 11155420, a gas se plaća u ETH. OP token nije gas token.

OP Stack je modularan sistem

OP Stack ne predstavlja jedan monolitni program. Sistem je podeljen na komponente sa različitim odgovornostima.

Najvažnije su:

• execution client koji izvršava EVM transakcije

• rollup node koji izvodi L2 lanac iz L1 podataka

• sequencer koji određuje redosled novih L2 transakcija

• batcher koji objavljuje podatke na Ethereum

• proposer koji objavljuje tvrdnje o izlaznom stanju

• fault proof komponente koje omogućavaju osporavanje neispravnog stanja

Uobičajena OP Stack implementacija koristi op-geth kao execution client i op-node kao consensus odnosno rollup komponentu.

op-geth održava EVM stanje i izvršava transakcije. op-node prati Ethereum, obrađuje podatke koje je batcher objavio i iz njih izvodi kanonski L2 lanac.

Ovo razdvajanje je važno.

OP Mainnet blok nije kanonski samo zato što ga je određeni RPC endpoint vratio. Nezavisni rollup node može da uzme podatke sa Ethereuma, primeni protokolska pravila i proveri da li je L2 lanac pravilno izveden.

Derivation je centralni OP Stack koncept

OP Stack koristi derivation pipeline za rekonstrukciju L2 lanca iz Ethereum podataka.

Na visokom nivou rollup node:

1. čita Ethereum blokove

2. pronalazi relevantne deposit transakcije i batch podatke

3. dekodira kanale i batcheve

4. grupiše podatke prema L1 origin blokovima

5. proizvodi payload atribute

6. prosleđuje ih execution engineu

7. proverava da li se dobijeno stanje slaže sa pravilima lanca

To znači da je Ethereum više od mesta na kojem se povremeno čuva hash.

Podaci objavljeni na L1 omogućavaju nezavisnom nodeu da rekonstruiše L2 istoriju. Sekvencer pruža brzu putanju do novih blokova, ali L1 derivation određuje proverljivi lanac.

Unsafe, safe i finalized blokovi

Jedna od najvažnijih OP Stack razlika za backend developera jeste eksplicitno razlikovanje statusa L2 headova.

Unsafe head predstavlja najnoviji lanac koji je sekvencer proizveo. Transakcija može biti vidljiva i izvršena, ali podaci još ne moraju biti objavljeni na Ethereumu.

Safe head predstavlja L2 lanac koji je moguće izvesti iz podataka objavljenih na L1.

Finalized head predstavlja deo L2 lanca izveden iz finalizovanih Ethereum blokova.

Ovi statusi nisu samo terminologija za node operatore.

Zamislimo backend koji prihvata stablecoin depozit i odmah omogućava korisniku povlačenje drugog asseta.

Ako backend prihvati unsafe stanje bez limita, preuzima rizik da sekvencerov pogled na lanac neće postati safe. Ako uvek čeka finalized stanje, korisničko iskustvo može postati nepotrebno sporo.

Praktično rešenje je politika zasnovana na riziku:

• mali iznos može biti knjižen nakon rane L2 potvrde

• srednji iznos može čekati safe status

• veliki iznos može čekati finalized status ili ručnu proveru

Status transakcije nije poslovna odluka. To je signal koji poslovna logika treba da protumači.

Kako se obračunava OP Mainnet naknada

OP Mainnet transakcija može uključivati više komponenti:

• L2 execution fee

• L1 data fee

• eventualne dodatne fee parametre definisane aktuelnom konfiguracijom mreže

L2 execution fee zavisi od potrošenog gasa i L2 base fee vrednosti.

L1 data fee pokriva trošak objavljivanja podataka na Ethereumu. Posle EIP-4844 nadogradnje, OP Stack može koristiti blob prostor za objavljivanje podataka, pa cena zavisi i od aktuelnog blob fee tržišta.

Trošak zato nije konstanta.

Dve funkcije koje troše približno isti EVM gas mogu imati različitu ukupnu cenu ako jedna šalje znatno više calldata podataka.

Ovo postaje važno kod:

• batch operacija

• multisend ugovora

• velikih dokaza i potpisa

• calldata intenzivnih oracle ažuriranja

• account abstraction operacija

• contract deploymenta

Optimizovanje samo Solidity izvršavanja nije uvek dovoljno. Na rollupu su format i veličina podataka deo ekonomije aplikacije.

Fault proofs

Optimistic rollup pretpostavlja da je objavljeno stanje validno dok se uspešno ne dokaže suprotno.

OP Stack fault proof sistem razdvaja tvrdnju o rezultatu izvršavanja od procesa kojim se ta tvrdnja osporava. Challenger može pokrenuti spor ako smatra da je predloženo stanje izvedeno protivno pravilima protokola.

Za aplikacionog developera fault proof nije API koji poziva pri svakoj transakciji.

Njegov značaj je sistemski:

• omogućava proveru predloženog stanja

• smanjuje potrebu za poverenjem u jednog operatora

• definiše sigurnosni model L2 prema L1 izlaza

• utiče na withdrawal period

Ipak, sama činjenica da fault proofs postoje ne znači da je svaki deo mreže potpuno decentralizovan. Treba odvojeno proveriti:

• ko upravlja sekvencerom

• ko može nadograditi sistemske ugovore

• postoje li security council ovlašćenja

• koliko traje upgrade delay

• pod kojim uslovima korisnik može prisilno poslati transakciju

• ko može učestvovati u challenge procesu

OP Standard Bridge

Standard Bridge služi za prenos ETH-a i podržanih ERC-20 tokena između Ethereuma i OP Mainneta.

Kod ERC-20 tokena važno je razumeti odnos između lokalnog i udaljenog tokena.

Token na jednoj mreži može biti:

• zaključan u bridge ugovoru

• predstavljen odgovarajućim tokenom na drugoj mreži

• spaljen prilikom povratka

• otključan na originalnoj mreži

Simbol tokena nije dovoljan za identifikaciju. Backend mora znati:

chain ID + contract address + remote token address

Standardni withdrawal sa OP Mainneta prema Ethereumu takođe prolazi kroz višefazni optimistic proces.

U aplikacionom interfejsu nije dovoljno prikazati da je withdrawal „poslat”. Korisnije je prikazati konkretno stanje:

initiated -> ready to prove -> proven -> ready to finalize -> finalized

Korisnik možda mora da izvrši više od jedne transakcije. Ako aplikacija koristi relayer koji to radi umesto njega, trošak i odgovornost samo su premešteni na backend.

Zašto je OP Mainnet zanimljiv developeru

OP Mainnet ima smisla kada aplikacija želi da radi direktno na mreži koja predstavlja centralni produkcioni primer OP Stack arhitekture.

To je posebno korisno za tim koji planira:

• deployment na više OP Stack chainova

• rad sa Superchain standardima

• sopstveni OP Stack chain

• standardizovanu cross-chain infrastrukturu

• korišćenje zajedničkih OP Stack sistemskih ugovora

Međutim, prenosivost ne dolazi automatski.

Isti bytecode može biti deployovan na više OP Stack mreža, ali se razlikuju:

• chain ID

• contract adrese

• stanje

• tokeni

• likvidnost

• bridge konfiguracija

• fee parametri

• governance

• upgrade raspored

OP Stack smanjuje tehničke razlike između mreža. Ne pretvara ih u jedan chain.

Realan Optimism use-case

Zamislimo protokol za escrow plaćanja koji prvo radi na OP Mainnetu, ali kasnije želi da podrži druge OP Stack mreže.

Smart contract može ostati relativno neutralan:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.24;

contract Escrow {
    enum Status {
        None,
        Funded,
        Released,
        Refunded
    }

    struct Payment {
        address payer;
        address recipient;
        uint256 amount;
        Status status;
    }

    mapping(bytes32 => Payment) public payments;

    function fund(
        bytes32 paymentId,
        address recipient
    ) external payable {
        require(msg.value > 0, "zero value");
        require(
            payments[paymentId].status == Status.None,
            "payment exists"
        );

        payments[paymentId] = Payment({
            payer: msg.sender,
            recipient: recipient,
            amount: msg.value,
            status: Status.Funded
        });
    }
}

Ugovor ne zavisi direktno od OP Stack sistemskih contracta. Zbog toga se može deployovati na više EVM mreža.

Backend ipak mora odvojeno čuvati svaki deployment:

type Deployment = {
    chainId: number;
    contractAddress: `0x${string}`;
    deploymentBlock: bigint;
};

const deployments: Deployment[] = [
    {
        chainId: 10,
        contractAddress: "0x...",
        deploymentBlock: 0n,
    },
    {
        chainId: 11155420,
        contractAddress: "0x...",
        deploymentBlock: 0n,
    },
];

U stvarnoj konfiguraciji deploymentBlock treba da bude stvarni blok deploymenta. Indeksator nema razlog da čita istoriju od genesis bloka.

Ako protokol kasnije uvede direktne cross-chain poruke, neutralnost nestaje. Tada mora da izabere:

• OP Stack interoperability mehanizam

• canonical bridge messaging

• nezavisni messaging protokol

• sopstveni relayer

• off-chain koordinaciju

To je granica između multi-deployment i stvarne multi-chain aplikacije.

Optimism trade-off

OP Mainnet pruža standardno EVM iskustvo i direktan pristup OP Stack arhitekturi.

Najveća prednost nije samo jeftinija transakcija, već relativno jasan put od jedne L2 aplikacije ka većem OP Stack sistemu.

Cena je složenost koja dolazi sa modularnim rollupom:

• derivation pipeline

• unsafe, safe i finalized statusi

• L1 i L2 fee komponente

• višefazni withdrawal

• bridge token modeli

• sistemski predeploy ugovori

• razlika između OP Mainneta i OP Stacka kao tehnologije

Ako aplikacija ostane na jednom chainu i koristi samo standardni EVM, veliki deo ove složenosti može biti sakriven. Ako želi cross-chain funkcionalnost, ona postaje centralni deo dizajna.

Base: OP Stack chain sa drugačijim proizvodnim fokusom

Base je zaseban Ethereum L2 koji je inkubirao Coinbase. Izgrađen je na OP Stacku, ali nije deo OP Mainnet stanja i nije privatna Coinbase baza podataka.

Base mainnet koristi chain ID 8453, Base Sepolia koristi 84532, a gas se plaća u ETH.

Base nema poseban nativni token potreban za slanje transakcija. ETH na Base mreži je nativni gas asset.

Pošto Base koristi OP Stack, veliki deo protokolske arhitekture sličan je OP Mainnetu:

• execution client izvršava EVM transakcije

• rollup node prati L1 i izvodi L2 stanje

• sequencer formira nove L2 blokove

• batcher objavljuje podatke na Ethereum

• L2 stanje može se rekonstruisati iz L1 podataka

• postoje unsafe, safe i finalized pogledi na lanac

To ne znači da je Base samo OP Mainnet sa drugim chain ID-em.

Base ima sopstveno stanje

Ako isti ugovor deployujete na OP Mainnet i Base, dobijate dve odvojene instance.

One imaju odvojene:

• storage vrednosti

• balanse

• nonce vrednosti

• događaje

• administrativne uloge

• upgrade putanje

• likvidnost

• korisnike

Poziv ugovora na Base mreži ne može sinhrono da čita storage ugovora na OP Mainnetu.

Čak i kada ugovori imaju istu adresu, to ne znači da predstavljaju isti objekat. Identitet contracta mora da sadrži mrežu:

chain_id + contract_address

Isto važi za tokene. Adresa bez chain ID-a nije potpuni identifikator asseta.

Kako Base izvodi L2 lanac

Kao OP Stack mreža, Base koristi derivation proces u kojem rollup node čita Ethereum podatke i iz njih rekonstruiše L2 blokove.

Sekvencer pruža brzu putanju do najnovijeg stanja. Validator ne mora bezuslovno da prihvati ono što sekvencer tvrdi. Može samostalno pratiti Ethereum i iz objavljenih podataka izvesti proverljivi L2 lanac.

To stvara dva relevantna pogleda na najnovije stanje:

• stanje koje je sekvencer upravo proizveo

• stanje koje je moguće izvesti iz objavljenih L1 podataka

Za frontend je prvi pogled važan zbog brzine. Za settlement backend važan je drugi.

Base aplikacija zato ne treba da tretira svaki receipt kao jednak signal.

Flashblocks kao dodatni preconfirmation sloj

Base podržava Flashblocks, mehanizam koji izlaže preconfirmation podatke češće od standardnog L2 bloka. Aktuelna dokumentacija opisuje ažuriranja približno svakih 200 milisekundi preko posebnih preconfirmation endpointa.

To može biti korisno za aplikacije kojima je važan brz odziv:

• trading interfejse

• igre

• aukcije

• payment UI

• aplikacije sa čestim promenama stanja

• agente koji šalju više uzastopnih transakcija

Međutim, preconfirmation nije finalnost.

Korisno je razlikovati:

submitted
preconfirmed
included
safe
finalized

Frontend može preconfirmation koristiti za optimistički prikaz rezultata. Backend koji menja finansijski ledger mora da zna kada je transakcija uključena u standardni L2 lanac i kada je stanje dobilo jaču potvrdu.

Postoji i praktičan problem sa nonce vrednostima.

Ako aplikacija brzo šalje više transakcija, standardni RPC pogled na pending stanje možda neće uključivati sve Flashblocks preconfirmation transakcije. Za takav workflow treba koristiti dokumentovani preconfirmation endpoint i odgovarajući pending nonce.

To nije potrebno običnoj aplikaciji koja šalje jednu transakciju i čeka receipt. Važno je za relayer, market maker ili automatizovani sistem sa većom frekvencijom.

Koliko košta Base transakcija

Base transakciona naknada takođe se sastoji od više delova.

Osnovni model uključuje:

• L2 execution trošak

• L1 data trošak

• mrežne fee parametre aktuelne Base konfiguracije

L2 execution deo zavisi od potrošenog gasa i trenutne Base gas cene.

L1 data deo zavisi od podataka koji se objavljuju na Ethereumu i stanja relevantnog L1 odnosno blob fee tržišta.

Base sistemska konfiguracija može uključivati dodatne parametre, uključujući operator fee parametre. Zbog toga aplikacija ne treba ručno da pretpostavi da je ukupna cena jednaka samo proizvodu gasUsed i L2 baseFeePerGas vrednosti.

Za korisnika je najvažnija procena koju wallet prikaže neposredno pre potpisivanja.

Za developera koji sponzoriše gas važniji su stvarni istorijski podaci:

• medijana po tipu operacije

• viši percentili troška

• odnos L1 i L2 komponente

• trošak neuspelih transakcija

• trošak contract deploymenta

• trošak u periodima povećane aktivnosti

Ako proizvod plaća gas za korisnike, rečenica „Base je jeftin” nije budžetski model.

Base bridge i povlačenje na Ethereum

Base koristi OP Stack bridge arhitekturu za komunikaciju sa Ethereumom.

Deposit sa Ethereuma na Base i withdrawal sa Base mreže na Ethereum ponovo nisu isti tok.

Kod deposita korisnik inicira L1 transakciju, posle koje odgovarajuća poruka postaje izvršiva na Base mreži.

Kod standardnog withdrawala proces uključuje:

1. iniciranje na Base mreži

2. objavljivanje relevantnog L2 stanja

3. dokazivanje withdrawala

4. challenge period

5. finalizaciju na Ethereumu

Standardni optimistic withdrawal može trajati približno sedam dana.

Ako korisniku treba brži izlaz, može koristiti bridge zasnovan na likvidnosti. Tada treba jasno prikazati:

• ko obezbeđuje likvidnost

• koju naknadu naplaćuje

• koji token korisnik prima

• na kojoj mreži ga prima

• šta se dešava ako relayer ili bridge nije dostupan

Bridge nije samo dugme između dva wallet balansa. To je dodatni finansijski i sigurnosni sistem.

Gde Base ima praktičan smisao

Base je posebno zanimljiv za consumer aplikacije i plaćanja jer kombinuje EVM okruženje sa ekosistemom usmerenim na distribuciju krajnjim korisnicima.

To ipak nije razlog da se aplikacija automatski deployuje na Base.

Pravo pitanje je da li korisnik već ima:

• wallet koji podržava Base

• ETH za gas ili podršku sponzorisanog gasa

• potrebne tokene na Base mreži

• pristup odgovarajućem on-rampu

• razlog da ostane u Base ekosistemu posle prve transakcije

Ako korisnik mora da kupi asset na drugoj mreži, premosti ga na Base, nabavi ETH za gas i tek onda izvrši osnovnu funkciju proizvoda, nominalno jeftina transakcija nije rešila korisnički problem.

Realan Base use-case: stablecoin checkout

Zamislimo SaaS aplikaciju koja korisniku izdaje fakturu i prihvata stablecoin na Base mreži.

Checkout prikazuje:

Iznos: 50 USDC
Mreža: Base
Primalac: 0x...
Rok plaćanja: 15 minuta

Backend ne treba da traži bilo koji događaj čiji simbol glasi USDC.

Treba da proveri:

• chain ID je 8453

• emitter je tačno dozvoljena token adresa

• događaj je ERC-20 Transfer

• primalac je očekivana adresa

• sirovi iznos odgovara fakturi

• transakcija je uspešna

• log pripada kanonskom bloku

• uplata ranije nije obrađena

• dostignut je potreban nivo potvrde

Model događaja može izgledati ovako:

type TokenPayment = {
    chainId: number;
    transactionHash: `0x${string}`;
    logIndex: number;
    blockNumber: bigint;
    blockHash: `0x${string}`;
    tokenAddress: `0x${string}`;
    sender: `0x${string}`;
    recipient: `0x${string}`;
    rawAmount: bigint;
};

Jedinstveni ključ događaja treba da uključi najmanje:

chain_id + transaction_hash + log_index

Transaction hash sam po sebi nije dobar globalni identifikator u sistemu koji podržava više mreža.

Knjiženje treba da bude idempotentno. Ako worker primi isti događaj dva puta, korisnički saldo ne sme biti kreditiran dva puta.

Tipičan workflow izgleda ovako:

1. WebSocket brzo prijavi novi događaj.

2. Worker čita receipt preko RPC-a.

3. Proverava chain, token, primaoca i iznos.

4. Čuva događaj sa jedinstvenim identifikatorom.

5. Čeka nivo potvrde definisan poslovnom politikom.

6. U istoj database transakciji menja status fakture i interni ledger.

7. Periodični reconciliation job ponovo proverava blockchain podatke.

WebSocket ubrzava sistem. Ne predstavlja izvor konačne istine za računovodstvo.

Base trade-off

Base pruža poznat EVM model, OP Stack sigurnosnu arhitekturu i infrastrukturu prilagođenu aplikacijama koje ciljaju veliki broj krajnjih korisnika.

Flashblocks mogu dodatno poboljšati osećaj odziva kod aplikacija kojima je latencija važna.

Sa druge strane, developer mora razlikovati:

• Flashblocks preconfirmation

• standardno L2 uključenje

• safe stanje izvedeno iz L1 podataka

• finalizovano stanje

• Base od OP Mainneta

• nativni od bridged asseta

• canonical od liquidity bridge toka

Base nije centralizovana baza podataka samo zato što je povezan sa Coinbaseom. Istovremeno, nije ni potpuno nezavisan od operativnih i governance odluka svojih ključnih operatora.

Threat model mora da uzme u obzir obe strane.

Poređenje Arbitrum, Optimism i Base mreže

Sve tri mreže omogućavaju izvršavanje Ethereum kompatibilnih smart contracta uz niže troškove od direktnog L1 izvršavanja u mnogim tržišnim uslovima.

To je njihova zajednička polazna tačka, ne cela arhitektura.

Ako pravite DeFi aplikaciju

Prvo proverite gde postoje protokoli i likvidnost od kojih zavisite.

Jeftiniji deployment nema veliku vrednost ako korisnik mora da premosti svaki asset ili ako na ciljnoj mreži ne postoji dovoljno duboko tržište.

Arbitrum može biti logičan izbor ako aplikacija koristi postojeći Arbitrum DeFi sistem. OP Mainnet može biti bolji ako su zavisnosti već tamo ili ako je važna OP Stack strategija. Base može biti bolji ako se korisnici i potrebni asseti već nalaze na Base mreži.

Ako pravite consumer aplikaciju

Najvažniji kriterijum možda neće biti rollup protokol.

Važniji mogu biti:

• wallet onboarding

• sponzorisanje gasa

• dostupnost stablecoina

• fiat on-ramp

• distribucija aplikacije

• brz odziv interfejsa

• jednostavan recovery naloga

Base može biti zanimljiv zbog consumer fokusa i Flashblocks podrške. To ne uklanja potrebu za pravilnim modelovanjem finalnosti.

Ako pravite payment backend

Ne birajte mrežu samo prema prosečnoj naknadi.

Proverite:

• koji token korisnici zaista poseduju

• da li prihvatate nativnu ili bridged varijantu

• koliko košta treasury consolidation

• kako sredstva izlaze na Ethereum ili berzu

• koliko je pouzdan RPC

• kako se obrađuju reorganizacije

• koji nivo potvrde pokreće isporuku proizvoda

• ko plaća gas

• kako se rešava uplata na pogrešnoj mreži

Najjeftiniji transfer nije nužno najjeftiniji poslovni tok.

Ako planirate deployment na sve tri mreže

Multi-chain deployment povećava broj korisnika koje aplikacija može da podrži, ali uvodi dodatnu operativnu površinu.

Za svaki chain treba održavati:

• deployment adresu

• deployment blok

• admin i upgrade konfiguraciju

• token allowlistu

• oracle adrese

• RPC providere

• rezervne RPC providere

• block explorer

• bridge konfiguraciju

• indeksator

• treasury balans

• alerte

• incident proceduru

Jedan Solidity repository ne znači jednu produkcionu aplikaciju.

Tri deploymenta su tri skupa stanja koja mogu da se raziđu.

Ako postoji poslovna logika koja mora ostati konzistentna između njih, timu je potreban eksplicitan cross-chain ili off-chain koordinacioni model.

Zaključak

Arbitrum, Optimism i Base rešavaju sličan problem, ali nisu isti sistem.

Arbitrum One koristi Nitro, ArbOS, retryable tickets i sopstveni rollup model. Uz standardni Solidity pruža i Stylus kao dodatno Wasm izvršno okruženje.

OP Mainnet je konkretna L2 mreža zasnovana na OP Stacku. Njegov najvažniji developer koncept nije samo EVM kompatibilnost, već derivation proces kojim nezavisni node rekonstruiše L2 lanac iz Ethereum podataka.

Base koristi OP Stack, ali predstavlja zaseban chain sa sopstvenim stanjem, parametrima, sekvencerom i ekosistemom. Flashblocks dodaje brži preconfirmation sloj, ali ne menja potrebu da aplikacija razlikuje rani signal od finalizovanog stanja.

Za običan smart contract razlike mogu biti male. Promeni se chain konfiguracija, RPC URL i deployment adresa.

Za produkcionu aplikaciju razlike su velike.

Pojavljuju se u:

• obračunu naknada

• statusima blokova

• cross-chain porukama

• bridge workflowu

• withdrawal periodu

• sistemskim ugovorima

• indeksiranju događaja

• načinu na koji backend procenjuje rizik

Najrazumniji izbor zato ne počinje pitanjem koja mreža ima najniži gas.

Počinje pitanjima:

• gde se nalaze korisnici

• gde se nalaze potrebni asseti

• od kojih protokola aplikacija zavisi

• koliko brzo rezultat mora postati upotrebljiv

• koji nivo finalnosti poslovni model zahteva

• koliko L2 specifične infrastrukture tim želi da održava

Ako su ti odgovori jasni, izbor između Arbitrum, Optimism i Base mreže obično postaje mnogo jednostavniji.

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti i prodati USDT i USDC. Više informacija nalazi se na stranici Volet za korisnike iz Srbije. Za otvaranje naloga koristi Volet referral link. Link je referral link autora članka.

Izvori

1. Arbitrum Docs: Chain information

2. Arbitrum Docs: Inside Arbitrum Nitro

3. Arbitrum Docs: Gas and fees

4. Arbitrum Docs

5. Arbitrum Docs: Stylus introduction

6. Optimism Docs

7. OP Stack Specification: Derivation

8. Optimism Docs: Fault proofs

9. Optimism Docs: Standard Bridge

10. Base Docs: Chain ID

11. Base Docs: Derivation

12. Base Docs: Flashblocks transaction state

13. Volet Srbija

English version: Read on Dev.to: Arbitrum, Optimism, and Base for Developers: Three Different Approaches to Ethereum Layer 2 Architecture

Za developera, međutim, sličnost se uglavnom završava na simbolu i ciljanoj ceni.

Iza tokena stoje različiti izdavaoci, različite rezerve, različiti modeli distribucije i različita cross-chain infrastruktura. Čak ni isti token na dve mreže nije jedan globalni balans. To su odvojeni ugovori, odvojeni ledger-i i odvojeni operativni rizici.

Ako aplikacija prihvata samo jedan stablecoin na jednoj mreži, integracija može da izgleda kao običan ERC-20 transfer. Ako treba da prima uplate, vodi interne balanse, šalje isplate, prebacuje likvidnost između mreža i na kraju konvertuje tokene u fiat, problem brzo postaje distribuirani platni sistem.

Ovaj tekst posmatra USDT i USDC upravo iz tog ugla.

Kratak odgovor: šta su USDT i USDC

USDT je stablecoin koji izdaje Tether. Namenjen je održavanju vrednosti bliske jednom USD i pokriven je rezervama kojima upravlja izdavalac. Najjača strana mu je rasprostranjenost: prisutan je na velikim berzama, u P2P trgovini, OTC kanalima, remittance aplikacijama i na više blockchain mreža.

USDC je stablecoin koji izdaju regulisani Circle entiteti. Takođe cilja vrednost od jednog USD, ali je operativno više usmeren ka institucionalnim on-ramp i off-ramp tokovima, transparentnosti rezervi i nativnoj interoperabilnosti između podržanih mreža.

Oba su fiat-backed stablecoini. To znači da stabilnost ne pokušavaju da postignu algoritmom ili kripto-kolateralom zaključanim u DeFi protokolu. Umesto toga, oslanjaju se na centralnog izdavaoca koji:

• prima fiat od kvalifikovanih klijenata

• upravlja rezervnom imovinom

• izdaje nove tokene

• obrađuje otkup tokena za fiat

• upravlja administratorskim pravima token ugovora

• sprovodi pravne i compliance odluke

Blockchain rešava prenos i evidenciju vlasništva nad tokenima. Ne čuva dolare koji ih pokrivaju i ne donosi odluku ko može da izvrši direktan otkup.

To je najvažnija mentalna granica za razumevanje oba sistema.

Stablecoin nije dolar u smart ugovoru

Kada wallet prikazuje 1,000 USDC ili 1,000 USDT, on ne prikazuje stanje bankovnog računa. Prikazuje količinu tokena u određenom ugovoru na određenoj mreži.

Vrednost tog tokena zavisi od nekoliko slojeva:

1. Izdavalac mora da upravlja rezervama.

2. Kvalifikovani korisnici moraju da mogu da izvrše mint i redemption.

3. Berze i market makeri moraju da održavaju dovoljno likvidna tržišta.

4. Blockchain mora da nastavi da obrađuje transakcije.

5. Smart ugovor mora da radi očekivano.

6. Off-ramp partner mora da prihvata baš tu verziju tokena na baš toj mreži.

Zbog toga oznaka USDC ili USDT nije dovoljna za identifikaciju imovine.

Praktični identitet tokena je kombinacija:

chainId + token contract address

Za ne-EVM mreže to može biti kombinacija mreže i mint adrese, asset ID-ja ili drugog nativnog identifikatora.

Ako baza čuva samo currency = "USDC", model je nedovoljan. Potrebno je čuvati najmanje:

asset
network
chain_id
contract_or_asset_id
decimals
amount_in_base_units
transaction_hash
block_number
confirmation_status

To nije samo pitanje uredne šeme. Pogrešan model podataka pre ili kasnije završava pogrešno knjiženim depozitom ili slanjem tokena na nepodržanu mrežu.

Kako USDT radi

USDT je centralno izdat token sa promenljivom ponudom. Nema unapred definisan maksimalni supply kao Bitcoin. Ponuda raste i smanjuje se kroz procese izdavanja i otkupa kojima upravlja Tether.

Primarno tržište

Na primarnom tržištu kvalifikovani i verifikovani klijent radi direktno sa Tether-om.

Pojednostavljen mint tok izgleda ovako:

1. Klijent prolazi KYC i AML proveru.

2. Klijent šalje fiat Tether-u.

3. Tether potvrđuje sredstva i zahtev za izdavanje.

4. Tether izdaje odgovarajuću količinu USDT-a na podržanoj mreži.

5. Tokeni se šalju klijentu ili ostaju u treasury inventaru do izdavanja.

Redemption ide u suprotnom smeru:

1. Verifikovani klijent šalje USDT Tether-u.

2. Tokeni se uklanjaju iz opticaja ili vraćaju u treasury.

3. Tether isplaćuje fiat na verifikovani bankovni račun, u skladu sa uslovima i naknadama.

Direktan otkup nije zamišljen kao retail tok. Tether u dokumentaciji navodi minimalni iznos od 100.000 USD ekvivalenta. Za većinu korisnika realan izlaz nije direktan redemption, već prodaja USDT-a na berzi ili kod lokalnog OTC partnera.

Sekundarno tržište

Kada korisnik kupi 500 USDT na berzi, Tether najčešće ne mintuje novih 500 tokena. Korisnik kupuje postojeće tokene od druge strane ili iz inventara berze.

Isto važi za većinu aktivnosti koje aplikacija vidi:

• slanje USDT-a između wallet-a

• zamena USDT-a za drugi token

• prebacivanje između korisničkog i treasury wallet-a

• trgovanje na centralizovanoj berzi

• deponovanje u DeFi protokol

Ove operacije menjaju vlasništvo nad postojećim tokenima, ali same po sebi ne menjaju ukupnu ponudu.

Peg se održava ekonomskim odnosom između primarnog i sekundarnog tržišta. Ako USDT padne ispod jednog USD, kvalifikovani akteri mogu da ga kupe sa diskontom i pokušaju da ga otkupe kod izdavaoca. Ako je cena iznad jednog USD, mogu da nabave nove tokene kroz primarni kanal i prodaju ih na tržištu.

Mehanizam nije automatski smart contract arbitrage. Zavisi od bankarskih šina, likvidnosti, prava na redemption i poverenja da će izdavalac obraditi zahtev.

Rezerve USDT-a

Tether navodi da su tokeni u opticaju pokriveni rezervama čija ukupna vrednost premašuje obaveze prema holderima.

Struktura rezervi nije ograničena samo na gotovinu. Objavljeni izveštaji obuhvataju kategorije kao što su:

• američki trezorski zapisi

• gotovina i bankarski depoziti

• money market fondovi

• reverse repo aranžmani

• obezbeđeni zajmovi

• plemeniti metali

• bitcoin

• druge investicije

Ovo ne znači automatski da je rezerva nekvalitetna. Znači da developer ili treasury tim ne sme izraz „backed by reserves” da prevede u „svaki token ima jedan fizički dolar na odvojenom računu”.

Važna je i razlika između atestacije i revizije. Atestacija daje nezavisno uveravanje o određenim izjavama i stanju na određeni datum. Potpuna finansijska revizija ima širi obim, proverava interne kontrole i finansijske izveštaje kroz duži period. Ta dva termina ne treba koristiti kao sinonime.

USDT kao multichain token

USDT nije sopstveni blockchain. Tether ga izdaje na više postojećih mreža, među kojima su Ethereum, Tron, Solana, Avalanche, TON, Near, Aptos, Celo, Kaia, Tezos, Liquid i Polkadot AssetHub.

Svaka implementacija koristi standard te mreže:

• ERC-20 na EVM mrežama

• TRC-20 na Tronu

• SPL token na Solani

• Jetton na TON-u

• Fungible Asset na Aptosu

• Asset ID na Polkadot AssetHub-u

Iz perspektive izdavaoca, jedan USDT na podržanoj mreži treba da predstavlja istu ekonomsku obavezu kao jedan USDT na drugoj podržanoj mreži. Iz perspektive aplikacije, to su potpuno odvojena sredstva.

USDT na Ethereumu ne može direktno da se pošalje u Tron transakciji. Potrebna je berza, bridge, issuer swap ili drugi posrednički mehanizam koji uklanja ili zaključava token na jednoj strani i izdaje odgovarajući oblik na drugoj.

Tether je tokom vremena ukidao podršku za pojedine mreže. Omni, EOS, Algorand, Kusama i Bitcoin Cash SLP nalaze se među legacy implementacijama za koje Tether više ne izdaje nove tokene niti ima istu obavezu direktnog otkupa. Token ugovor može i dalje postojati i transferi mogu tehnički raditi, ali to nije isto što i aktivna podrška izdavaoca.

Za produkcioni sistem lista mreža zato nije statička konfiguracija koju jednom upišeš i zaboraviš.

Posebnost Ethereum USDT ugovora

USDT na Ethereumu koristi stariju ERC-20 implementaciju. Njegova transfer funkcija ne ponaša se potpuno kao moderni ERC-20 ugovori koji eksplicitno vraćaju bool.

Ako Solidity ugovor očekuje standardni boolean povratni rezultat, direktan poziv može da dovede do neuspeha integracije. Tether u zvaničnim smernicama preporučuje korišćenje biblioteke koja ume da obradi i stare i nove ERC-20 implementacije.

U praksi, to znači SafeERC20 iz OpenZeppelin-a:

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

import {IERC20} from
    "@openzeppelin/contracts/token/ERC20/IERC20.sol";
import {SafeERC20} from
    "@openzeppelin/contracts/token/ERC20/utils/SafeERC20.sol";

contract StablecoinPayout {
    using SafeERC20 for IERC20;

    function send(
        IERC20 token,
        address recipient,
        uint256 amount
    ) external {
        token.safeTransfer(recipient, amount);
    }
}

Primer nije kompletan treasury ugovor. Nema autentikaciju, limite, pause kontrolu ni zaštitu administratorskih ključeva. Pokazuje samo ispravan način da ugovor komunicira sa tokenima koji ne vraćaju vrednost dosledno modernom ERC-20 standardu.

Kako USDC radi

USDC koristi isti osnovni mint-and-burn princip, ali sa drugačijom rezervnom politikom, institucionalnim pristupom i znatno razvijenijom zvaničnom developer infrastrukturom.

Circle je jedini izdavalac USDC-a preko svojih regulisanih entiteta. Direktno izdavanje i otkup obavljaju se kroz Circle Mint.

Mint i redemption

Kvalifikovana institucija povezuje bankovni račun sa Circle Mint nalogom. Kada uplati fiat i zatraži USDC, Circle izdaje isti nominalni iznos tokena na izabranoj podržanoj mreži.

Kod redemption-a:

1. Institucija šalje USDC na Circle Mint.

2. Circle uklanja odgovarajući USDC iz opticaja.

3. Fiat se šalje na povezani bankovni račun.

Circle Mint nije dostupan fizičkim licima i malim kompanijama. Retail korisnici i manji startupi obično koriste:

• centralizovane berze

• regulisane on-ramp i off-ramp provajdere

• neobanke

• wallet aplikacije

• lokalne platne partnere

To je bitna produktna razlika. „USDC je redeemable 1:1” ne znači da svaki holder može neposredno da pozove Circle API i dobije bankovni transfer. Direktan pristup zavisi od pravnog lica, jurisdikcije, onboardinga i dostupnosti Circle Mint proizvoda.

Rezerve USDC-a

Circle navodi da je USDC pokriven visoko likvidnom gotovinom i gotovinskim ekvivalentima.

Većina rezervi nalazi se u Circle Reserve Fund-u, SEC registrovanom government money market fondu kojim upravlja BlackRock. Fond može da sadrži:

• gotovinu

• kratkoročne američke trezorske zapise

• overnight repo transakcije obezbeđene američkim trezorcima

Preostali deo drži se u gotovini kod regulisanih finansijskih institucija. Portfolio Circle Reserve Fund-a objavljuje se svakodnevno, Circle objavljuje nedeljne podatke o rezervama, mintovanju i redemption-u, a mesečni reserve report dobija nezavisno mišljenje Deloitte-a.

Ovo je konzervativniji i jednostavniji rezervni model od Tether-ovog. I dalje nije bez rizika. Postoje bankarski, kastodi, operativni, regulatorni i issuer rizik. USDC je tokom bankarske krize u martu 2023. privremeno odstupio od jednog USD, što je dobar podsetnik da kvalitet izveštavanja ne uklanja zavisnost od tradicionalnog finansijskog sistema.

Native USDC nije isto što i bridged USDC

Circle je do septembra 2026. nativno izdavao USDC na 38 blockchain mreža. Među njima su Ethereum, Solana, Base, Arbitrum, Optimism, Polygon PoS, Avalanche, Stellar, Aptos, Sui, Near, Celo, Linea, ZKsync i druge.

Reč „nativno” je ključna.

Native USDC je token koji Circle direktno izdaje i podržava na toj mreži. Bridged USDC je reprezentacija koja obično nastaje kada bridge zaključa USDC na izvornoj mreži i mintuje drugi token na odredišnoj.

Na nekim mrežama bridged verzija koristi oznaku USDC.e. Takav token može da prati cenu USDC-a, ali:

• Circle ga nije direktno izdao

• ne mora biti podržan u Circle Mint-u

• možda ne može da se pošalje na Circle deposit adresu

• nosi rizik bridge ugovora

• može imati odvojenu likvidnost

• može koristiti drugu adresu i drugačiji redemption put

Ticker u wallet-u zato nije dokaz autentičnosti.

Za svaku mrežu treba proveriti zvaničnu Circle tabelu ugovora. Na primer:

Ove adrese ne treba kopirati iz blogova, poruka ili rezultata pretrage. Produkciona konfiguracija treba da se proverava prema zvaničnoj dokumentaciji izdavaoca i odgovarajućem block exploreru.

Kako oba tokena održavaju cenu

USDT i USDC ne koriste oracle koji silom podešava cenu na jedan USD. Token ugovor ne može da naredi tržištu po kojoj ceni da trguje.

Peg nastaje iz kombinacije:

• prava kvalifikovanih klijenata na mint i redemption

• dubine likvidnosti na berzama

• arbitraže

• kvaliteta i likvidnosti rezervi

• poverenja u izdavaoca

• pristupa bankarskom sistemu

Ako USDC na berzi padne na 0,995 USD, institucionalni učesnik može da kupi token sa diskontom i otkupi ga za nominalni USD, pod uslovom da ima pristup Circle Mint-u i da redemption radi bez zastoja. Kupovina smanjuje diskont.

Ako token trguje iznad jednog USD, kvalifikovani učesnik može da mintuje novi USDC po nominalnoj vrednosti i proda ga skuplje na sekundarnom tržištu. Dodatna ponuda pritiska cenu nazad.

USDT koristi isti osnovni ekonomski princip, ali sa Tether-ovim pravilima pristupa, minimalnim iznosima, bankarskim kanalima i rezervnom politikom.

Zbog toga je „1 stablecoin = 1 USD” cilj i ekonomski mehanizam, ne nepromenljiva osobina protokola.

Centralizacija nije fusnota

USDT i USDC su tokeni na javnim blockchain mrežama, ali nisu decentralizovani u smislu izdavanja i upravljanja.

Izdavaoci kontrolišu administratorske funkcije koje mogu obuhvatiti:

• mintovanje novih tokena

• spaljivanje tokena

• pauziranje transfera

• blokiranje pojedinačnih adresa

• nadogradnju ugovora

• upravljanje privilegovanim minter adresama

Na Ethereum USDT ugovoru postoje funkcije kao što su addBlackList, removeBlackList i destroyBlackFunds. USDC FiatToken arhitektura takođe podržava blokiranje adresa i pauziranje ugovora.

To ima dve posledice koje developer mora eksplicitno da prihvati.

Prva je compliance prednost. Izdavalac može da reaguje na krađu, sankcije, sudski nalog ili zahtev organa za sprovođenje zakona.

Druga je counterparty kontrola. Balans u self-custody wallet-u nije van domašaja izdavaoca samo zato što korisnik drži privatni ključ. Privatni ključ kontroliše potpisivanje transakcije, ali token ugovor odlučuje da li je transfer dozvoljen.

Za platnu aplikaciju zato nije dovoljno pratiti samo stanje. Potrebno je imati proceduru za sredstva koja su:

• primljena sa sumnjive adrese

• zamrznuta nakon prijema

• povezana sa sankcionisanim entitetom

• tehnički vidljiva, ali neprenosiva

• vraćena ili spaljena kroz administratorsku akciju

Cross-chain problem: isti naziv, različita imovina

Najveća greška u multichain integracijama je pretpostavka da blockchain mreže dele stanje.

Ne dele ga.

Ako korisnik ima 100 USDC na Ethereumu i želi 100 USDC na Base-u, postojeći tokeni moraju biti uklonjeni, zaključani ili predati posredniku na jednoj mreži, a odgovarajući tokeni oslobođeni ili mintovani na drugoj.

Postoje tri uobičajena modela.

Lock and mint bridge

Bridge zaključava originalni token u smart ugovoru i izdaje wrapped reprezentaciju na drugoj mreži.

Rizici uključuju:

• ranjivost bridge ugovora

• kompromitovan validator ili signer set

• pogrešno računanje zaključanog kolaterala

• nelikvidnost wrapped tokena

• zavisnost od bridge operatora

Liquidity bridge

Korisnik uplaćuje token u pool na izvornoj mreži, a liquidity provider isplaćuje ekvivalent na odredišnoj.

Ovaj model uvodi:

• liquidity provider rizik

• slippage

• route availability

• dinamičke naknade

• rizik relayer infrastrukture

Burn and mint

Token se spaljuje na izvornoj mreži, a izdavalac autorizuje mint nativnog tokena na odredišnoj.

Circle CCTP koristi ovaj model za USDC. Prednost je što korisnik na odredištu dobija native USDC, bez trajnog wrapped sloja i bez poola koji mora da drži oba sredstva.

CCTP: kako USDC prelazi između mreža

Cross-Chain Transfer Protocol je Circle-ov permissionless protokol za prenos nativnog USDC-a između podržanih blockchain mreža.

Osnovni CCTP tok izgleda ovako:

1. Korisnik odobrava TokenMessengerV2 ugovoru da potroši USDC.

2. Aplikacija poziva burn operaciju na izvornoj mreži.

3. USDC se spaljuje i emituje se cross-chain poruka.

4. Circle Iris servis posmatra događaj i potpisuje atestaciju.

5. Aplikacija preuzima atestaciju.

6. Aplikacija prosleđuje poruku i atestaciju MessageTransmitter ugovoru na odredišnoj mreži.

7. Odredišni ugovor proverava potpis i mintuje native USDC primaocu.

Pojednostavljen tok može da se prikaže ovako:

sequenceDiagram
    participant U as Korisnik
    participant S as Source chain
    participant I as Circle Iris
    participant D as Destination chain

    U->>S: Approve i depositForBurn
    S->>S: Burn native USDC
    S-->>I: Burn event
    I-->>U: Potpisana atestacija
    U->>D: receiveMessage
    D->>D: Provera atestacije
    D-->>U: Mint native USDC

CCTP ne uklanja sva poverenja. Circle-ova atestaciona infrastruktura je i dalje deo sistema. Protokol ipak uklanja neke tipične bridge pretpostavke, pre svega trajno zaključavanje USDC likvidnosti u third-party bridge poolu.

Standard i Fast Transfer

CCTP nudi dva režima.

Standard Transfer čeka viši nivo finalnosti na izvornoj mreži. Sporiji je, ali optimizovan za niži trošak.

Fast Transfer koristi Circle-ov Fast Transfer allowance i izdaje atestaciju pre pune finalnosti. Brži je, ali može imati protokolsku naknadu koja zavisi od izvorne mreže.

Prema aktuelnoj dokumentaciji, Fast Transfer naknada kreće se od 0 do 13 baznih poena, u zavisnosti od mreže. Naknada se oduzima od iznosa koji se mintuje na odredištu. Vrednosti su promenljive i ne treba ih hardkodovati.

Aktuelna naknada preuzima se preko:

GET /v2/burn/USDC/fees

uz sourceDomainId i destDomainId.

Aplikacija zatim postavlja maxFee u burn pozivu. Ako je maksimalna dozvoljena naknada preniska, transakcija može biti odbijena ili prebačena na sporiji režim, zavisno od parametara transfera.

Fast Transfer allowance je globalni pool. Može privremeno biti iscrpljen dok prethodni transferi ne dostignu punu finalnost. Produkciona integracija zato mora imati fallback na Standard Transfer umesto da pretpostavi da je fast ruta uvek dostupna.

Ko plaća gas na odredišnoj mreži

Osnovni CCTP tok zahteva transakciju na izvornoj i odredišnoj mreži. To znači da neko mora imati native gas token na obe strane.

Za korisnika koji samo drži USDC ovo je loš UX. Može imati dovoljno USDC-a, ali ne i ETH, SOL ili drugi token potreban da završi mint.

Circle Forwarding Service može da preuzme destination-side mint i naplati gas i servisnu naknadu iz transfera. To pojednostavljuje UX, ali uvodi dodatnu uslugu, dinamičku naknadu i još jednu operativnu zavisnost.

U UI-ju zato treba prikazati najmanje:

• iznos koji se skida na izvoru

• CCTP protokolsku naknadu

• forwarding naknadu, ako postoji

• procenjeni destination iznos

• izabrani režim finalnosti

• očekivano vreme završetka

• fallback ponašanje

USDT i cross-chain fragmentacija

USDT nema jedan jedinstven cross-chain protokol koji pokriva sve njegove implementacije.

Postoje:

• direktno izdati USDT ugovori

• canonical bridge reprezentacije

• third-party wrapped tokeni

• exchange interne konverzije

• USDT0 implementacije zasnovane na LayerZero OFT modelu

USDT0 je cross-chain sloj koji zaključava USDT na Ethereumu i izdaje odgovarajući USDT0 na podržanim odredištima. To može da pruži konzistentniji cross-chain supply model, ali USDT0 nije isto što i Tether-ovo direktno izdavanje na svakoj mreži.

Za developera je najvažnije sledeće pitanje:

Ko je odgovoran za konverziju ovog konkretnog tokena nazad u issuer-supported USDT?

Odgovor može biti Tether, bridge, LayerZero infrastruktura, berza, kustodian ili treća strana. Rizik se menja sa odgovorom.

Zato token registry mora eksplicitno razlikovati:

USDT_NATIVE
USDT_CANONICAL_BRIDGED
USDT0
USDT_THIRD_PARTY_WRAPPED

Ista logika važi za USDC, USDC.e i druge bridged reprezentacije.

USDT vs USDC: ključne razlike

Ne postoji univerzalno bolji token. Postoji token sa prikladnijim skupom zavisnosti za konkretan sistem.

Prednosti i mane USDT-a

Prednosti

Najveća prednost USDT-a je distribucija. Korisnik u tržištu gde lokalna berza, P2P trgovac i OTC desk koriste USDT verovatno ne želi da prima USDC samo zato što je developeru urednija dokumentacija.

USDT ima smisla kada su najvažniji:

• duboka likvidnost na globalnim berzama

• veliki broj trgovačkih parova

• P2P tržišta

• postojeća podrška kod lokalnih partnera

• Tron kao jeftin transferni sloj

• široka prihvaćenost među retail korisnicima

USDT je često infrastrukturno dosadan na dobar način. Partneri ga već podržavaju, korisnici ga poznaju, a lokalni offramp ima gotovu likvidnost.

Mane

Operativna širina dolazi sa fragmentacijom.

Potrebno je razlikovati:

• mrežu

• nativni ili bridged oblik

• aktivno ili legacy izdavanje

• podršku berze za depozit

• podršku Tether-a za redemption

• ponašanje konkretnog token ugovora

Rezervna politika je šira od USDC modela, a direktan redemption nije praktičan za mali retail tok zbog minimalnog iznosa i onboardinga.

Ethereum ugovor zahteva pažljiviju smart contract integraciju, a centralne blacklist i pause funkcije znače da self-custody ne uklanja issuer rizik.

Prednosti i mane USDC-a

Prednosti

USDC je jednostavniji za timove kojima su važni:

• dokumentovan rezervni model

• institucionalni on-ramp i off-ramp

• javna lista zvaničnih ugovora

• native prisustvo na velikom broju mreža

• CCTP cross-chain transferi

• DeFi integracije na Ethereumu i L2 mrežama

• compliance i treasury dokumentacija

CCTP je posebno koristan ako aplikacija mora da rebalansira likvidnost između mreža bez držanja kapitala u bridge poolovima. Aplikacija može da spaljuje USDC na mreži sa viškom i mintuje native USDC na mreži gde je potreban za isplate.

To ne rešava FX, fiat settlement ni korisnički onboarding, ali rešava specifičan problem multichain likvidnosti na uredan način.

Mane

USDC nije jednako likvidan u svakom regionu i na svakoj berzi. Na tržištima gde USDT dominira, korisnik može platiti dodatni spread da bi konvertovao USDC.

Circle Mint nije API koji svaki startup može odmah da uključi. Potrebni su institucionalni onboarding, KYB, podržana jurisdikcija i odgovarajući bankarski račun.

CCTP je dobar cross-chain primitive, ali i dalje zahteva:

• podržanu source i destination mrežu

• ispravno upravljanje finalnošću

• atestacioni servis

• gas ili forwarding servis na odredištu

• fee quoting

• fallback kada fast allowance nije dostupan

• idempotentno izvršavanje destination mint-a

USDC takođe ima administratorske funkcije. Transparentnija rezerva ne znači decentralizovan token.

Koliko integracija zaista košta

Ne postoji jedna „USDT provizija” ili „USDC provizija”. Ukupan trošak ima više slojeva.

Mrežni gas

Svaki transfer plaća trošak mreže na kojoj se izvršava.

Na Ethereumu je to ETH gas. Na Base-u i Arbitrumu korisnik takođe plaća ETH, ali po drugačijem fee modelu. Na Solani plaća SOL. Na Tronu se koristi TRX i njegov energy odnosno bandwidth model.

Gas zavisi od:

• mreže

• zagušenja

• kompleksnosti poziva

• calldata veličine

• wallet infrastrukture

• batch ili pojedinačnog izvršavanja

Zato ne treba hardkodovati prosečnu cenu u proizvod. Fee estimator treba da koristi aktuelno stanje mreže.

Spread i trading fee

Ako aplikacija konvertuje USDT u USDC ili stablecoin u fiat, plaća:

• spread

• trading fee

• potencijalni market impact

• withdrawal fee

• bankarsku naknadu

Za velike iznose spread može biti važniji od blockchain gas-a. Quote treba računati za konkretnu količinu, ne iz poslednje tržišne cene.

On-ramp i off-ramp

Berza ili payment provider može naplatiti:

• fiat depozit

• konverziju

• povlačenje tokena

• povlačenje fiat valute

• lokalnu isplatu

• compliance obradu

Naknade se razlikuju po jurisdikciji, valuti, metodi uplate i nivou naloga.

Cross-chain trošak

CCTP može uključiti:

• gas na izvornoj mreži

• Fast Transfer fee

• gas na odredišnoj mreži

• Forwarding Service fee

• aplikativnu naknadu, ako je platforma dodaje

Kod bridge ili liquidity ruta mogu postojati:

• bridge fee

• relayer fee

• liquidity provider fee

• slippage

• destination gas drop

Trošak kapitala

Najčešće zanemaren trošak je prefunding.

Ako aplikacija podržava USDT na Tronu, USDC na Base-u i oba tokena na Ethereumu, možda mora unapred držati likvidnost u četiri odvojena balansa. Kapital na jednoj mreži ne pomaže automatski payout-u na drugoj.

Cross-chain protokol može smanjiti prefunding, ali uvodi vreme rebalansa, naknade i dodatne failure mode-ove.

Realan use-case: platforma za isplatu kontraktora

Zamislimo SaaS platformu koja firmama iz Evrope omogućava da plaćaju kontraktore u Latinskoj Americi i jugoistočnoj Aziji.

Kompanija uplaćuje EUR ili USD. Kontraktor bira:

• USDC na Base-u

• USDC na Solani

• USDT na Tronu

• bankovnu isplatu preko lokalnog partnera

Ovo nije jedna stablecoin integracija. To je orkestracija više ledger-a.

Korak 1: napraviti asset registry

Registry je jedini izvor istine za podržana sredstva.

type Stablecoin = 'USDC' | 'USDT';

type AssetConfig = {
  asset: Stablecoin;
  chainId: number;
  address: `0x${string}`;
  decimals: number;
  depositsEnabled: boolean;
  withdrawalsEnabled: boolean;
};

export const ethereumAssets: AssetConfig[] = [
  {
    asset: 'USDC',
    chainId: 1,
    address: '0xA0b86991c6218b36c1d19d4a2e9Eb0cE3606eB48',
    decimals: 6,
    depositsEnabled: true,
    withdrawalsEnabled: true,
  },
  {
    asset: 'USDT',
    chainId: 1,
    address: '0xdAC17F958D2ee523a2206206994597C13D831ec7',
    decimals: 6,
    depositsEnabled: true,
    withdrawalsEnabled: true,
  },
];

U produkciji registry treba da sadrži i:

• minimalni depozit

• minimalni payout

• broj potrebnih potvrda

• explorer URL šablon

• custody wallet

• sweep threshold

• status izdavaoca

• status bridge rute

• podršku offramp partnera

• datum poslednje verifikacije konfiguracije

Nemoj prihvatati token samo zato što mu symbol() vraća USDC. Bilo ko može da deployuje ERC-20 sa istim simbolom.

Korak 2: voditi interni double-entry ledger

Blockchain transakcija nije isto što i poslovno knjiženje.

Aplikacija treba da ima interni ledger koji razdvaja:

• pending depozit

• confirmed depozit

• raspoloživ balans

• rezervisan iznos

• poslatu isplatu

• neuspelu isplatu

• network fee

• platform fee

• konverziju

• korekciju

Korisnički saldo ne treba izračunavati svaki put čitanjem wallet-a. Jedan treasury wallet može sadržati sredstva hiljada korisnika, a blockchain ne zna kome pripada koji poslovni deo balansa.

Korak 3: obrađivati događaje idempotentno

Za EVM token depozit prati se Transfer događaj zvaničnog ugovora.

Event key može biti:

chain_id + transaction_hash + log_index

To omogućava idempotentnu obradu. Ako indexer pošalje isti događaj dva puta, sistem ne sme dva puta kreditirati korisnika.

Depozit najpre ulazi u observed, zatim u confirming, pa tek posle definisanog broja potvrda u confirmed.

Kod reorganizacije lanca potrebno je moći poništiti prethodno viđen događaj. Za male iznose aplikacija može prihvatiti niži prag potvrda, ali to je poslovna odluka, ne univerzalna blockchain konstanta.

Korak 4: nikada ne koristiti floating point

USDT i USDC na većini popularnih implementacija koriste 6 decimala, ali aplikacija ne treba da se oslanja na pretpostavku bez konfiguracije.

Iznosi se čuvaju kao celi brojevi u baznim jedinicama:

1 USDC = 1_000_000 base units
12.50 USDC = 12_500_000 base units

U TypeScript-u koristi bigint, parseUnits i formatUnits, ne JavaScript number.

import {formatUnits, parseUnits} from 'viem';

const decimals = 6;

const payout = parseUnits('125.50', decimals);
// 125500000n

const display = formatUnits(payout, decimals);
// "125.5"

Baza treba da koristi integer ili dovoljno precizan decimalni tip. Nikada float.

Korak 5: proceniti gas pre payout-a

Ako korisnik prima 5 USDC, a transfer i operativna obrada koštaju uporediv iznos, payout nije ekonomski održiv.

Platforma može:

• uvesti minimalni payout

• grupisati više isplata

• koristiti jeftiniju mrežu

• sponzorisati gas samo iznad određenog obima

• naplatiti transparentnu network fee stavku

• nuditi off-chain interni balans do povlačenja

Batch payout smanjuje operativni overhead, ali smart ugovor povećava blast radius. Greška u batch ugovoru može zaustaviti sve isplate, dok pojedinačni transferi imaju jednostavniji failure model.

Korak 6: upravljati treasury likvidnošću

Pretpostavimo da korisnici tog dana traže:

• 40.000 USDT na Tronu

• 25.000 USDC na Base-u

• 10.000 USDC na Solani

Aplikacija mora imati odgovarajuću likvidnost na svakoj mreži pre nego što payout počne.

USDC se između podržanih mreža može rebalansirati CCTP-om. Za USDT na Tronu možda je praktičnija berza ili OTC partner koji prima USDT na jednoj mreži i isplaćuje ga na drugoj.

Treasury engine treba da računa:

• trenutni raspoloživi balans

• rezervisane isplate

• očekivane depozite

• minimalni operativni bafer

• cenu rebalansa

• vreme rebalansa

• limite partnera

• maksimalnu izloženost jednom izdavaocu

Korak 7: omogućiti bezbedan izbor mreže

Korisnik ne treba da vidi jedno polje „Wallet address” i jedan izbor „USDT”.

UI mora jasno prikazati:

• token

• mrežu

• adresni format

• procenjenu naknadu

• očekivano vreme

• minimalni iznos

• upozorenje za nepodržane mreže

• da li primalac mora imati gas token

Za velike isplate korisno je uvesti:

• address book

• verifikaciju nove adrese

• vremensko odlaganje prve isplate

• testni transfer

• allowlist

• višestruko odobrenje

• dnevne limite

Produkcioni rizici koje tutoriali obično preskoče

Lažni tokeni

Napadač može napraviti token sa nazivom Tether USD, simbolom USDT i istim brojem decimala.

Aplikacija mora filtrirati događaje po zvaničnoj adresi ugovora, ne po simbolu. Wallet UI može prikazati lažni token kao da je pravi, ali backend ne sme.

Pogrešna mreža

EVM adresa izgleda isto na Ethereumu, Base-u, Arbitrumu i Polygonu. To ne znači da depozit sistem podržava sve te mreže.

Korisnik može poslati pravi USDC na ispravnu EVM adresu, ali na pogrešnoj mreži. Sredstva tehnički mogu biti dostupna istom privatnom ključu, ali recovery može zahtevati ručni proces, gas i sigurnosno odobrenje.

Native i bridged zabuna

Aplikacija koja podržava native USDC na Polygonu ne treba automatski da kreditira stari bridged USDC samo zato što ticker izgleda isto.

Svaki podržani ugovor mora biti zaseban asset u registry-ju. Ako se prihvataju oba oblika, moraju imati odvojenu likvidnost, cenu i offramp put.

Chain reorganizacija

Transakcija koja je viđena u mempool-u nije uplata. Transakcija u jednom bloku nije nužno konačna.

Prag potvrda treba prilagoditi mreži, vrednosti i poslovnom riziku. Veći depoziti mogu zahtevati više potvrda ili dodatnu proveru finalnosti.

RPC i indexer nedostupnost

Jedan RPC endpoint nije produkciona infrastruktura.

Potrebni su:

• primarni i rezervni RPC provider

• health check

• praćenje block height-a

• upozorenje kada indexer kasni

• periodični reconciliation sa on-chain stanjem

• mogućnost ponovnog skeniranja blokova

• deduplikacija događaja

Zamrznuta sredstva

USDT i USDC mogu biti blokirani na nivou ugovora. Ako treasury primi takva sredstva, saldo može biti vidljiv, ali neprenosiv.

Sistem mora razlikovati:

• confirmed balance

• spendable balance

• frozen balance

• compliance hold

On-chain stanje samo po sebi ne daje kompletnu poslovnu klasifikaciju.

Upravljanje ključevima

Najveći rizik često nije stablecoin ugovor, već sopstveni hot wallet.

Minimalni produkcioni model uključuje:

• odvojene hot i cold wallet-e

• dnevne limite

• multisig za velike transfere

• automatsko sweepovanje

• izolovane signer servise

• audit log svake autorizacije

• rotaciju ključeva

• incident plan

• mogućnost globalnog zaustavljanja isplata

Privatni ključ ne treba da bude obična environment promenljiva na istom serveru koji obrađuje javne API zahteve.

Kada izabrati USDT

USDT je često bolji operativni izbor kada:

• korisnici već drže USDT

• lokalni P2P i OTC partneri koriste USDT

• potreban je veliki broj berzanskih parova

• ciljno tržište koristi Tron

• najvažnija je izlazna likvidnost

• aplikacija radi sa globalnim traderima

• partneri ne podržavaju USDC na željenoj mreži

Tipičan primer je remittance koridor u kome primalac dobija USDT na Tronu i prodaje ga lokalnom OTC desk-u. U tom sistemu USDC može imati lepšu infrastrukturu, ali ne rešava poslednji kilometar ako ga lokalni partner ne kupuje.

Kada izabrati USDC

USDC je često prirodniji izbor kada:

• firma ima institucionalni on-ramp ili off-ramp

• potrebna je dokumentovana rezervna politika

• aplikacija radi na Ethereumu ili L2 mrežama

• potreban je native cross-chain transfer

• koristi se DeFi infrastruktura

• treasury mora redovno da rebalansira mreže

• partneri zahtevaju regulisaniji operativni okvir

• proizvod se gradi oko Circle infrastrukture

Tipičan primer je marketplace koji naplaćuje u USDC na Base-u, drži treasury na Ethereumu i isplaćuje deo korisnika na Solani. CCTP može da prebaci native likvidnost tamo gde je potrebna bez uvođenja sopstvenog wrapped tokena.

Kada podržati oba

Za ozbiljnu međunarodnu platnu aplikaciju odgovor često nije USDT ili USDC, već oba uz strogo ograničen skup mreža.

Dobar početni model može biti:

• USDT na Tronu za P2P i remittance korisnike

• USDC na Base-u za jeftine EVM isplate

• USDC na Solani za brze i jeftine transfere

• Ethereum samo za velike iznose i treasury operacije

Nije potrebno podržati svaki token na svakoj mreži. Svaka nova kombinacija povećava:

• broj wallet-a

• broj RPC integracija

• količinu prefundinga

• monitoring površinu

• recovery procedure

• compliance posao

• rizik pogrešnog depozita

• broj offramp ruta

Dve dobro podržane mreže vrednije su od deset delimično podržanih.

Konačni trade-off

USDT optimizuje za distribuciju, tržišnu likvidnost i globalnu dostupnost. Njegova snaga nije najlepši smart contract niti najjednostavniji rezervni model, već činjenica da veliki broj berzi, trgovaca, wallet-a i lokalnih partnera već govori njegovim jezikom.

USDC optimizuje za institucionalnu infrastrukturu, transparentniju rezervnu politiku i programabilnu multichain upotrebu. Njegova najveća tehnička prednost je CCTP, koji pruža standardizovan burn-and-mint put između podržanih mreža.

Oba tokena su centralno izdata. Oba zavise od rezervi koje nisu na blockchainu. Oba mogu da zamrznu adrese. Oba mogu privremeno odstupiti od jednog USD. I kod oba najveće produkcione greške obično nastaju oko njih, a ne unutar njih: pogrešna mreža, pogrešan ugovor, loš custody, floating-point računanje, neobrađena reorganizacija ili nepodržan offramp.

Zato pravi izbor nije „koji stablecoin je sigurniji” u apstraktnom smislu. Pravo pitanje je:

Koji skup izdavaoca, mreže, ugovora, likvidnosti, partnera i pravnih zavisnosti odgovara konkretnom toku novca?

Kada se problem tako postavi, USDT i USDC prestaju da budu dva gotovo ista tickera. Postaju dve različite komponente platne arhitekture, svaka korisna kada se koristi tamo gde joj operativni model odgovara.

Ovaj članak je sponzorisan od strane Volet.com. Na Volet.com možete kupiti i prodati USDT i USDC. Više informacija nalazi se na stranici Volet za korisnike iz Srbije. Za otvaranje naloga koristi Volet referral link. Link je referral link autora članka.

Izvori

1. Circle: USDC pregled, izdavanje, redemption i podržane mreže

2. Circle: transparentnost i struktura USDC rezervi

3. Circle Docs: zvanične USDC contract adrese

4. Circle Docs: Cross-Chain Transfer Protocol

5. Circle Docs: CCTP naknade

6. Circle Docs: CCTP tehnički vodič

7. Circle Docs: CCTP Forwarding Service

8. Circle Docs: Fast Transfer allowance

9. Tether: podržani protokoli i smernice za integraciju

10. Tether: transparentnost i rezerve

11. Tether: direktan redemption u fiat valutu

12. OpenZeppelin Docs: SafeERC20

13. Volet Srbija

English version:_ Read on Dev.to: USDT and USDC in Practice: Choosing a Stablecoin for Developers