# Balanced Exchange Framework (BEF) Framework Version 1.0 - 2026-08-22. FINAL FRAMEWORK BASELINE Complete framework text, transferred verbatim from the source document. Canonical location: https://balancedexchangeframe.work --- **BEF** **BALANCED EXCHANGE FRAMEWORK** **Uravnotežena ekonomija obilja** **BalancedExchangeFrame.work** FRAMEWORK VERSION 1.0 22 August 2026 > _FINAL CLEAN COPY · FRAMEWORK VERSION 1.0 · core architecture closed at framework-design level · product, entity, jurisdiction and asset activation remains subject to published legal, technical, accounting and evidence gates · graphics reserved for separate visual development · framework identity anchored at BalancedExchangeFrame.work_ > Quality. Creation. Exchange. Common Good. Alignment. Responsibility. Change. Transparency. Balance. Life. > _Operativni in transparentnostni framework. Ta dokument ni poimenovan ali predstavljen kot MiCA crypto-asset white paper in ne predstavlja pravnega mnenja, licence ali regulatorne odobritve._ --- ## DOCUMENT STATUS & VERSION CONTROL | Polje | Vrednost | | --- | --- | | Dokument | Balanced Exchange Framework (BEF) - LANA Reference Implementation & Multi-Asset Architecture \| BalancedExchangeFrame.work | | Tip | Core Framework + BEF Protocols P01-P24 + Activation, Regulatory & Evidence Annexes A-S | | Verzija | Framework Version 1.0 | | Datum | **22 August 2026** | | Framework home / Javna objava | BalancedExchangeFrame.work | | Transparency & Consumption | TheLana.life | | Registrar | LanaWatch.us (LANA reference Registrar) + coin-specific P24 Registrar namespaces | | Alignment Governance | LanaAligns.world | | Self-Responsibility | SelfResponsible.life | | Status | FINAL FRAMEWORK BASELINE. Version 1.0 closes the core BEF architecture at framework-design level. The master triad, Split trigger, adaptive supply logic, Balanced Wallet personal sufficiency model, Zero-Level coordinate architecture, dynamic Flow Capacity, Economic Gravity, deregistration/re-expansion logic and system-maturity principle are defined. Version 1.0 intentionally does not convert entity-, product-, jurisdiction-, asset- or deployment-specific legal/technical evidence into universal rules. Those requirements continue in Annex C as ACTIVATION & IMPLEMENTATION CONDITIONS. A function marked CONDITIONAL or HOLD may not be launched or marketed as active until its applicable activation conditions are satisfied. Framework Version 1.0 is not a MiCA white paper, legal opinion, licence or regulatory approval. | ## BEF ARCHITECTURE AT A GLANCE > **FIRST COMPLETE FRAMEWORK BASELINE** Ta stran je orientacijski zemljevid celotnega BEF. Ne ustvarja novih pravil, ampak pokaže, kako se Core Framework in protokoli berejo kot ena povezana struktura. #### MASTER TRIAD > **EXCHANGE + ALIGNMENT + SELF-RESPONSIBILITY / OWN** EXCHANGE premika vrednost in omogoča realno ekonomsko življenje. ALIGNMENT določa skupno smer. SELF-RESPONSIBILITY / OWN vrača odgovornost posamezniku. Noben steber ne nadomesti drugega; ravnovesje nastaja iz njihovega hkratnega delovanja. #### EXCHANGE > **LANA8WONDER / PERSONAL BALANCE + LANAPAYS.US / CIRCULATION + COMMON GOOD FUNDING / CREATION & GIVING** LANAPAYS.US se nadalje bere kot CONSUMPTION + CAPITAL INPUT / DIRECT.LANA.FUND + TREASURY / RECIRCULATION / LANA DISCOUNT. COMMON GOOD FUNDING se nadalje bere kot CROWDFUNDING + UNCONDITIONAL FUNDING + UNCONDITIONAL PAYMENTS. #### ALIGNMENT > **PROPOSAL -> RESISTANCE / DIALOGUE -> ALIGNMENT** Materialna smer postane vidna, resistance se obravnava kot informacija in ne kot napaka, skupna odločitev pa se izvede šele po pravilih veljavnega Alignment procesa. #### SELF-RESPONSIBILITY / OWN > **REFLECTION -> ALIGNMENT -> CHANGE** V Reflection izkušnja postane vidna; v Alignment posameznik prevzame svoj del brezpogojne samoodgovornosti; v Change nastane konkretna zaveza prihodnjemu ravnanju. #### HOW TO READ THE REST OF THE DOCUMENT Core Framework razloži celoto. P01-P24 nato posamezne funkcije razprejo operativno, tehnično, pravno in regulatorno. Activation & Implementation Conditions ne pomenijo, da arhitektura manjka; pomenijo, da mora biti pred določenim produkcijskim korakom dokončan konkreten pravni, tehnični, finančni ali dokazni paket. ## FOUNDATIONAL BALANCE NOTE ### Balance, Coexistence & Preservation > **BEF = BALANCED EXCHANGE FRAMEWORK · BalancedExchangeFrame.work** BEF je framework med finančnimi sistemi in asseti. Ni coin, token, fiat valuta, borza, investicijski produkt ali nadomestni monetarni sistem. Njegova vloga je ustvariti skupno, preverljivo in postopno uravnoteženo arhitekturo, v kateri lahko različne oblike vrednosti obstajajo hkrati ter ohranijo svojo lastno identiteto, mrežo, pravno kvalifikacijo in ekonomsko funkcijo. ### 1. Soobstoj namesto zamenjave Vključitev asseta v BEF ne pomeni, da mora ta asset izginiti, se pretvoriti v LANO ali prepustiti svoje mesto enemu novemu univerzalnemu sredstvu. LANA je prva in referenčna implementacija BEF, ne končni monopolni asset. Enako načelo velja za Bitcoin, druge vključene native blockchain coine, fiat valute in druge oblike vrednosti, ki bodo pozneje dobile ustrezno BEF klasifikacijo. BEF zato ne temelji na logiki zamenjave, ampak na logiki SOOBSTOJ -> URAVNOTEŽENJE -> OHRANJANJE. Različni asseti lahko ostanejo različni. Framework med njimi vzpostavlja skupne discipline transparentnosti, registracije, odgovornosti, kroženja, regulativnega mapiranja in življenjskega cikla, ne da bi izbrisal njihove lastne značilnosti. ### 2. Ohranjanje kot sistemski namen Zrela uravnotežena ekonomija ni zamišljena kot prostor, v katerem ena valuta ali en asset zmaga, drugi pa propadejo. Temeljni design cilj je ohranjanje funkcionalne raznolikosti in stabilnega soobstoja. BEF naj bi zmanjšal potrebo po destruktivnem tekmovanju za izključni položaj tako, da omogoči različnim assetom, da imajo jasno vlogo, lastno evidenco, lasten ekonomski cikel in preverljive povezave z drugimi deli sistema. To načelo ne pomeni fiksiranja tržnih cen ali zagotavljanja, da bo katerikoli asset vedno obstajal ali ohranil vrednost. BEF ne more odpraviti ekonomskega, tehnološkega ali pravnega tveganja. Pomeni pa, da njegova arhitektura ni zasnovana na predpostavki, da mora za razvoj enega asseta drugi asset nujno izginiti. ### 3. Ravnovesje med različnimi asseti Vsak vključeni native coin ohrani svoj blockchain, native asset, key model in coin-specific Registrar. Vsak ACTIVE coin razvije svoj Registered status, Active Supply, Split zgodovino in Coin Split Profile. Fiat valute ohranijo svojo pravno in monetarno naravo. BEF je povezovalni sloj, ki omogoča, da se različni sistemi srečajo v skupnih pravilih, ne pa ena nova enota, v katero bi se morali vsi sistemi zliti. Pri tem je regulatorna ločenost bistvena: vključitev v skupni konceptualni framework ne prenese pravne klasifikacije enega asseta na drugega. Še naprej velja COIN x PRODUCT x JURISDICTION in FUNCTION BEFORE LABEL. Ravnovesje je design cilj; pravna kvalifikacija vedno sledi dejanski funkciji in veljavnemu pravu. ### 4. Naravni razvojni vzorec: rast -> zrelost -> vzdrževanje BEF uporablja razvojno analogijo živega organizma. Človeški organizem začne iz ene oplojene celice in skozi razvoj hitro povečuje število celic, gradi organe ter povečuje telesno velikost. Rast ni enakomerno neskončna: v otroštvu in adolescenci se postopoma upočasnjuje, vzdolžna rast okostja pa se zaključi z dozorevanjem rastnih plošč. V odraslosti se delitev in obnova celic ne ustavita; različna tkiva se obnavljajo z zelo različnimi hitrostmi, vendar je glavna funkcija tega procesa vzdrževanje, popravilo in obnova organizma, ne neskončno povečevanje njegove telesne velikosti. BEF iz te analogije prevzame samo razvojno načelo, ne biološke enačbe: zgodnja faza sistema lahko uporablja hitrejše cikle in Splite za rast kapacitete in dosega; dolgoročni namen pa ni neskončna eksponentna rast. Zrel sistem mora imeti možnost preiti v stanje, kjer prevladujejo stabilnost, kroženje, obnova, recirkulacija, ohranjanje in ravnovesje. ### 5. Split je razvojni mehanizem, ne neskončni cilj Spliti so v BEF način prehoda med razvojnimi cikli. V Growth Phase lahko omogočajo širjenje registrirane ekonomije, razvoj novih kapacitet in vključevanje dodatnih assetov ter uporabnikov. Vendar BEF izrecno ne predpostavlja, da mora enaka hitrost Splitov ali enaka value-transition formula veljati v nedogled. Če bi bil končni cilj samo neomejena rast, bi bil sistem v nasprotju z lastnim načelom Balance. Prehod CELOTNE EKONOMIJE iz Growth Phase v Mature / Balanced State ni en sam numerični trigger. Ekonomija je kolektivni odraz posameznikov: ko dovolj udeležencev prostovoljno prehaja v Balanced Wallet in trajni podatki kažejo, da realna potrošnja, notranja cirkulacija, recirkulacija in dinamična kapaciteta lahko nosijo običajen tok brez stalne strukturne potrebe po vedno večji Growth-Phase ekspanziji, se lahko tudi coin-specific ekonomija premakne v Mature / Balanced režim. Presoja se dela na vztrajnih, praviloma večmesečnih podatkih, ne na dnevnem šumu. BEF 1.0 namenoma ne določa univerzalnega deleža ljudi, datuma ali matematičnega praga; veljavni operational policy objavi indikatorje in način presoje. Mature State je stanje, v katerem lahko sistem po potrebi diha - raste, miruje ali se krči - brez predpostavke, da je neskončna rast nujna. > **FOUNDATIONAL PRINCIPLE: BEF DOES NOT SEEK TO REPLACE THE FINANCIAL WORLD. IT SEEKS TO HELP DIFFERENT FORMS OF VALUE COEXIST, MATURE AND REMAIN IN BALANCE.** > _Scientific analogy note: the biological comparison is illustrative, not a claim that an economy is biologically equivalent to a human body. Scientific grounding used for the analogy includes work on mammalian growth deceleration and growth-plate maturation (Lui et al., Mechanisms Limiting Body Growth in Mammals; Jee et al., The Biology of Stature) and adult human cellular turnover (Sender et al., The distribution of cellular turnover in the human body, Nature Medicine)._ ### 6. Balanced Wallet kot gladina morja Balanced Wallet uporablja gladino morja kot razlagalni model dinamičnega ravnovesja. ZERO LEVEL ni »nič denarja« in tudi pozicija pod Zero Levelom ni ekonomski minus. Tako kot morska gladina obstaja šele, ko je prisotna dejanska masa vode, je Zero Level referenčna ravnina znotraj dejansko obstoječe in evidentirane kapacitete balancing skupine. Matematični znak +/− lahko interno pokaže samo smer odstopanja od reference. Primer: pri display baselineu 1.000 lahko user-facing kapaciteti 2.000 in 0 ustrezata koordinatama +1.000 in −1.000 okoli Zero Levela. Oznaka −1.000 ne pomeni, da oseba dolguje 1.000 ali da sistem ustvarja 1.000 iz nič. V definirani balancing skupini je cilj, da se koordinatna odstopanja agregatno izravnajo proti ničli, medtem ko native asseti, fiat, lastništvo in dejanska sredstva ostanejo ločeno in v celoti evidentirani. ### 7. Balance ni enakost BEF ne predpostavlja, da morajo imeti vsi ljudje enako premoženje, enake denarnice ali enako gospodarsko aktivnost. Nekdo lahko ustvarja majhne valove, nekdo zelo velike: podjetnik, investitor, ustvarjalec ali trgovec lahko upravlja bistveno večji tok kot drug udeleženec. Ravnovesje pomeni, da sistem ne zahteva neskončne akumulacije in da se odstopanja lahko vračajo v tok; ne pomeni prisilne materialne izenačitve. ### 8. Flow before accumulation V Mature / Balanced State se glavni kazalnik premakne od vprašanja koliko je nekdo nakopičil k vprašanju ali ima dovolj kapacitete za življenje, ustvarjanje, izmenjavo in nadaljnji tok. BEF uporablja načelo FLOW BEFORE ACCUMULATION: vrednost, ki kroži in podpira realno življenje ekonomije, ima večjo sistemsko funkcijo kot vrednost, ki mora neskončno rasti samo zato, da ostane relevantna. > _Vizija obilja je, da sredstvo menjave postopoma postane infrastruktura, o kateri človeku ni treba neprestano razmišljati, ker ima dovolj dostopa in kapacitete za legitimne potrebe. To je razvojni cilj in vrednostna usmeritev, ne jamstvo, da bo vsak posameznik dosegel določen znesek premoženja ali da ekonomska tveganja prenehajo obstajati._ ### 9. Economic Gravity Morski val ima naravno tendenco vrnitve proti gladini. BEF to uporablja kot analogijo ECONOMIC GRAVITY: če del Registered kapacitete dalj časa očitno ni potreben za realni flow, ga sistem začne vračati proti aktivnemu območju. Gravity se praviloma presoja v mesečnih oziroma večmesečnih oknih, ne na dnevnem nivoju; konkreten policy lahko glede na fazo, asset in dejanski tok uporabi približno mesec, več mesecev, leto ali daljše obdobje. Pred spremembo Registered statusa mora udeleženec dobiti Gravity Notice in možnost uporabe, prenosa, donacije, Common Good usmeritve ali prostovoljne deregistracije. Če relevantni neuporabljeni presežek ostane, lahko objavljeni policy deregistrira samo tisti del Registered statusa, ki presega trenutno upravičeno/aktivno flow območje. Deregistracija ne poseže v private key ali native asset ownership. > _Economic Gravity ni fizična sila in ne dovoljuje samovoljnega odvzema sredstev. Vsaka dejanska provizija, expiry, cap, release, reallocation ali druga posledica mora biti vnaprej objavljena, pravno dovoljena, tehnično preverljiva in jasno ločena od lastništva native blockchain asseta._ ### 10. Release, giving & reallocation Udeleženec, ki presežne Registered vrednosti ne potrebuje, jo lahko uporablja, podari, usmeri v Common Good, prenese, proda v dovoljeni ločeni transakciji ali prostovoljno deregistrira. Če po Gravity procesu del Registered statusa ostane očitno neuporabljen, se lahko deregistrira v enem ali več korakih toliko, kolikor je potrebno, da se aktivna Registered kapaciteta vrne proti dejansko uporabljenemu flow območju. Posledica je lahko čisto krčenje sistema. Če se pozneje pojavi nova realna potreba, se kapaciteta znova razširi z ločenim Registration Eventom. Sprostitev kapacitete pri enem udeležencu ne pomeni prenosa njegovih coinov drugemu; omogoča samo, da se sistemska Registered kapaciteta po potrebi na novo vzpostavi tam, kjer obstaja dejanski flow. ### 11. Saturation: ko rast ni več potrebna Growth Phase obstaja zato, ker ekonomija še gradi doseg, merchant mrežo, uporabniško kapaciteto, registrirani supply in povezave med asseti. Ko vedno več ekonomskega prostora že sodeluje in notranja cirkulacija lahko sama podpira večji del izmenjave, se marginalna potreba po novem zunanjem kapitalu zmanjšuje. BEF zato predvideva NATURAL DECELERATION: manjša potreba po rasti -> manj intenzivni Split cikli -> več recirkulacije in vzdrževanja -> Mature / Balanced State. > _Noben dokument ne določa vnaprej, koliko Splitov je potrebnih ali kdaj mora biti sistemska zrelost dosežena. Framework 1.0 uporablja trajno evidence-based presojo: delež in dinamiko Balanced Wallet prehodov, realno potrošnjo, internal circulation, fiat-out demand, merchant/consumer reuse, recirculation, potrebo po novih registracijah, treasury/settlement capacity ter širjenje ali krčenje Flow Capacity. Ko ti signali skupaj pokažejo, da je večina nove kapacitete namenjena obnovi in dejanskim potrebam namesto strukturnemu povečevanju ekonomije, se sistem lahko vodi kot Mature / Balanced. To je adaptivna razvojna presoja, ne marketinška obljuba ali koledarski dogodek._ ### 12. Incentive transition V zgodnji Growth Phase lahko BEF uporablja pozitivne potrošniške spodbude, ker želi graditi realno uporabo. Ko pa notranja cirkulacija dozori, se lahko potreba po takih spodbudah zmanjšuje. Zrela ekonomija lahko zato postopoma preide iz modela ENTER / CONSUME -> POSITIVE INCENTIVE v model, kjer je notranja uporaba sama po sebi najugodnejša, zunanja pretvorba v izbrani fiat pa lahko vsebuje transparentno tržno ceno, spread, discount ali drugo friction, če je takšna postavitev pravno dovoljena in vnaprej jasno prikazana. > _Takšna sprememba ne sme biti prikrita kazen za izstop, guaranteed tokenomics ali način za onemogočanje zakonskih pravic. Vsaka fiat-conversion politika se presoja po dejanski funkciji, pogodbi, consumer/payment/crypto perimetru in jurisdikciji._ ### 13. Fiat je del ravnovesja, ne nasprotnik BEF ne zahteva izginotja EUR, USD, GBP ali katerekoli druge fiat valute. Fiat ostaja legitimna oblika vrednosti in lahko še naprej opravlja pomembne funkcije. Cilj je zmanjševati odvisnost, pri kateri mora celoten ekonomski tok iskati samo eno obliko izhoda. Ko imajo ljudje in podjetja resnično možnost uporabljati več različnih oblik vrednosti, se povpraševanje razporedi med več kanalov in noben posamezen asset ni po designu prisiljen nositi celotnega bremena izmenjave. > _BEF to opisuje kot DIVERSITY BEFORE DOMINANCE. Raznolikost lahko zmanjša koncentracijski pritisk in dependency risk, vendar ni jamstvo stabilnosti katerekoli valute, trga ali ekonomije._ ### 14. Soobstoj brez izgube identitete Bitcoin lahko ostane Bitcoin, EUR ostane EUR, LANA ostane LANA, drugi native coini pa ohranijo svoje mreže in lastnosti. BEF med njimi gradi registrirane, transparentne in regulatorno ločene poti izmenjave ter po zrelosti ravnotežne povezave. Cilj ni winner-take-all, temveč sistem, v katerem obstoj enega asseta ne zahteva izginotja drugega. ### 15. Človeška dimenzija: dovolj, svoboda in ustvarjanje Balanced Economy of Abundance ne definira človekove vrednosti z velikostjo njegovega walleta. Posameznik lahko še vedno investira, gradi podjetja, kopiči premoženje, zbira avtomobile ali nepremičnine, če je to njegova svobodna izbira in passion. Drugi lahko izbere minimalno lastništvo in več dostopa oziroma izkušenj. BEF ne določa pravilnega življenjskega sloga; želi odstraniti sistemsko potrebo, da je neskončno kopičenje pogoj za občutek varnosti. Kakovost, kreacija, skrb, sodelovanje, ljubezen, harmonija in enost v raznolikosti so vrednostna smer tega frameworka. Te vrednote ne nadomeščajo pogodb, dovoljenj, pravic potrošnikov ali prisilnega prava; določajo pa, kakšno človeško okolje naj tehnična in finančna arhitektura podpira. ### 16. Stability objective, not a no-loss guarantee Balanced Wallet in cross-asset balance sta zasnovana kot mehanizma za zmanjševanje koncentracije, mrtve akumulacije in odvisnosti od neskončne rasti. BEF zato zasleduje stabilnost skozi flow, razpršitev in preverljivo ravnovesje. Vendar Framework ne trdi, da lahko odpravi vse tržne padce, tehnološke napake, pravne spremembe, insolventnost, izgubo ključev ali izgubo vrednosti posameznega asseta. Noben opis zero-level, gravity ali preservation ne predstavlja capital guarantee, deposit guarantee, guaranteed redemption ali no-loss promise. > **MATURE FLOW PRINCIPLE: WHEN SUFFICIENT CAPACITY EXISTS, THE SYSTEM SHOULD NEED LESS GROWTH - NOT MORE. BALANCE IS MAINTAINED BY FLOW, DIVERSITY, RELEASE AND CONTINUOUS RECIRCULATION, NOT BY FORCING ONE ASSET TO DOMINATE.** ### Namen te verzije Framework Version 1.0 directly consolidates the First Complete Framework Baseline and closes the remaining core design questions addressed in 0.32-0.33. The LANA Split trigger remains exhaustion-based and supply sizing remains adaptive. Balanced Wallet is now defined as a voluntary transition from automatic Growth-Phase accumulation toward personal sufficiency, Zero-Level balance and real flow. A below-Zero Wallet Position is only a coordinate relative to the selected Zero Level and is not debt, missing money or a source of newly created spending power. Dynamic Flow Capacity is assessed over meaningful multi-month operating windows and can expand or contract with real economic use. Economic Gravity acts on persistently unused excess Registered status through notice, participant choice and, where the published asset-specific policy allows, deregistration. System maturity emerges from the collective movement of participants and the economy from structural growth toward sufficient internal circulation, renewal and self-regulation; it is not tied to one date, one wealth threshold or one universal formula. > _Framework Version 1.0 distinguishes a closed CORE ARCHITECTURE from function-specific ACTIVATION. Exact parameters such as a Gravity review window, de-minimis amounts, per-asset deregistration mechanics, KYC assurance levels, legal entity mappings, licences, product contracts, accounting treatment and jurisdiction-specific regulatory conclusions remain operational or legal implementation decisions. They do not reopen the core architecture, but the relevant function remains CONDITIONAL or HOLD until its published activation pack is complete._ ### Regulatorna pozicija dokumenta BEF je operativni in transparentnostni framework. Njegov namen je omogočiti razumljiv in preverljiv opis dejanskega delovanja sistema. Dokument sam zase ne določa dokončne pravne kvalifikacije posamezne ponudbe, storitve ali subjekta. Vsak sodelujoči subjekt ostaja odgovoren za svojo dejavnost, pogodbe, dovoljenja in obveznosti po veljavnem pravu. Pri presoji evropskega regulatornega okvira je posebej relevantna Uredba (EU) 2023/1114 (MiCA). BEF zato namenoma ločuje opis sistema od formalnega crypto-asset white paperja ter vključuje podatke, ki so regulatorno relevantni za razumevanje ponudbe, pravic, omejitev, supply mehanizmov, tehnologije in tveganj. Za United Kingdom se uporablja ločen perimeter. Po koncu EEA passportinga se EU/EEA dovoljenja ne passportirajo avtomatično v UK. Framework 1.0 zato UK ne obravnava kot podaljšek MiCA, temveč ločeno preverja current MLR business/territorial scope, UK financial promotions, Payment Services Regulations 2017 ter prihodnji FSMA crypto regime. Za Lana Discount je posebej pomembno, da current MLR test ni identičen MiCA client-service testu, medtem ko draft future Article 9UA izrecno predlaga exclusion za proprietary dealing, ki ni opravljen z namenom zagotavljanja storitve klientu v zvezi z regulirano aktivnostjo, opravljeno v njegovem imenu. ### Regulatory Closure Principle Common Good, ravnovesje in odprta transparentnost so temeljne design vrednote BEF, vendar same po sebi ne ustvarjajo regulatorne izjeme. Pravna kvalifikacija vedno sledi dejanski ekonomski funkciji, toku sredstev, pogodbenim pravicam, custodyju, izvrševanju, namenu transakcije in komunikaciji. BEF zato uporablja načelo FUNCTION BEFORE LABEL. Za Lana Discount to pomeni dodatno pravilo OWN ACCOUNT BEFORE SERVICE: proprietary treasury klasifikacija velja samo, dokler dejanska substance kaže, da družba kupuje zase in ne zagotavlja storitve menjave, izvrševanja ali likvidnosti klientu. ### Activation status - READY - področje je operativno opisano in nima identificirane nerešene materialne predpostavke v tem Frameworku; še vedno veljajo pravila konkretnega subjekta in jurisdikcije. - CONDITIONAL - model je opisan, vendar je pred konkretnim launchom ali širitvijo potreben entity/product-specific legal, licensing, notification ali evidence check. - HOLD - funkcija se ne aktivira oziroma ne trži kot razpoložljiva, dokler ni zaprt izrecno naveden pravni, finančni ali tehnični pogoj. ### Transaction price and Nostr activation statuses - LOW PRICE - standard native transfer cost is below 0,01 EUR for the stated reference case. - MID PRICE - standard native transfer cost is from 0,01 EUR through 0,30 EUR inclusive for the stated reference case. - HIGH PRICE - standard native transfer cost is above 0,30 EUR for the stated reference case. HIGH PRICE is an economic-use signal, not an automatic BEF exclusion. - LIVE PRICE GATE - the cost is too dynamic or insufficiently evidenced; CP-58 requires live/rolling evidence before the network can be classified reliably for the intended BEF use case. - NOSTR COMPATIBLE - the native key model can technically produce or be transformed into the secp256k1/BIP-340 Schnorr signature model required by NIP-01 without custody or third-party signing. - NOSTR INCOMPATIBLE - the ordinary native key model is Ed25519, sr25519, BLS, principal-based or otherwise not directly aligned with NIP-01 secp256k1 Schnorr events. Such coin requires a separate Nostr-link proof or adapter and is not direct-key aligned. ## TABLE OF CONTENTS | Del | Naslov | | --- | --- | | FOUNDATION | Balance, Coexistence & Preservation - Foundational Balance Note | | CORE | BEF Core Framework - Triadic Architecture | | P01 | Registered LANA & Registrar Protocol | | P02 | Merchant & Consumption Protocol | | P03 | Split, Supply & Registration Protocol | | P04 | Common Good Funding Protocol | | P05 | Alignment Governance Protocol | | P06 | Unconditional Self-Responsibility / OWN Protocol | | P07 | BuyLana.com / Registered LANA Purchase & Delivery Protocol | | P08 | Lana Discount Proprietary Treasury Acquisition Protocol | | P09 | Transparency, Events & Evidence Protocol | | P10 | Risk, Complaints & Regulatory Interface Protocol | | P11 | Decentralized Technology & Nostr Infrastructure Protocol | | P12 | Digital Beings & Symbiotic Intelligence Protocol | | P13 | Financial Circulation & Abundance Architecture | | P14 | Lana8Wonder & Balanced Wallet Protocol | | P15 | Regulatory Perimeter, Legal Entities & Licensing Protocol | | P16 | Market Integrity, Inside Information & Conflicts Protocol | | P17 | AML/TFR, Sanctions & Tax Reporting Protocol | | P18 | Privacy, Data Governance & AI Decision Safeguards Protocol | | P21 | Identity Assurance, KYC & Biometric Verification Protocol | | P22 | UK Market Access & Regulatory Perimeter Protocol | | P19 | Payments, Consumer Protection & Settlement Protocol | | P20 | Liquidity, Solvency, Operational Resilience & Audit Protocol | | ANNEX A | Definitions | | ANNEX B | Protocol & Version Map | | ANNEX C | Activation & Implementation Conditions | | ANNEX D | Regulatory References | | ANNEX E | Lana Nostr KIND Index (Human-Readable Snapshot) | | ANNEX F | Regulatory Closure Matrix | | ANNEX G | Legal Entity & Regulatory Responsibility Matrix | | ANNEX H | Price, Value & Liquidity Taxonomy | | ANNEX I | Consumer Settlement Flow Matrix | | ANNEX J | KYC / Identity Assurance Control Matrix | | ANNEX K | UK Regulatory Perimeter & Transition Matrix | | **P23** | **United States Market Access & Regulatory Perimeter Protocol** | | **P24** | Native Coin Integration & Balanced Split Architecture Protocol | | **ANNEX L** | **U.S. Federal Product & Perimeter Matrix** | | **ANNEX M** | **U.S. State-by-State Activation Matrix** | | **ANNEX N** | **U.S. Activation Groups, Source Freeze & Deployment Checklist** | | **ANNEX O** | **Initial Native Coin Candidate Registry** | | **ANNEX P** | **Native Coin Market Snapshot & Technical Verification Notes** | | ANNEX Q | Atomic Unit & Transaction Fee Economics Matrix | | ANNEX R | 0.22 Revision Integrity Review | ## PART I - BEF CORE FRAMEWORK ``` Document ID: BEF-CORE | Version: 1.0 | Framework home: BalancedExchangeFrame.work ``` ### 1. Namen Frameworka Balanced Exchange Framework (BEF) predstavlja krovni operativni in transparentnostni okvir za razvoj Uravnotežene ekonomije obilja. LANA je prva in referenčna implementacija tega frameworka, ne pa meja njegovega prihodnjega obsega. Krovna javna in dokumentna identiteta frameworka je BalancedExchangeFrame.work; funkcijske domene posameznih plasti BEF ohranijo svoje ločene vloge. BEF povezuje ljudi, ustvarjalce, trgovce, potrošnjo, kapital, fiat tokove, Registered LANA in druge coin-specific Registered Native Coin ekonomije, registrirane denarnice oziroma accounte, Splite, Common Good, transparentnost, Alignment in brezpogojno samoodgovornost v enoten in preverljiv okvir, pri katerem posamezni asseti ohranijo svojo native identiteto in lastno pravno obravnavo. Njegov namen ni neskončna količinska rast. Namen je graditi okolje, ki daje prednost kakovosti pred količino, kreaciji pred reprodukcijo, uporabnosti pred prazno potrošnjo, sodelovanju pred preglasovanjem, samoodgovornosti pred obtoževanjem ter ravnovesju pred nenadzorovano rastjo. BEF ni zasnovan kot nadomestek za obstoječe valute ali finančne sisteme. Njegov temeljni cilj je Balanced Coexistence: različne oblike vrednosti lahko ostanejo različne, framework pa med njimi razvija transparentne in uravnotežene poti kroženja, razvoja, regulatornega mapiranja in dolgoročnega ohranjanja. ### 2. Uravnotežena ekonomija obilja Obilje v BEF ne pomeni neomejene količine denarja, izdelkov ali potrošnje. Pomeni okolje, v katerem imajo posamezniki dovolj prostora, časa, podpore in kapitala, da lahko ustvarjajo kakovostne izdelke, storitve, projekte in odnose. Človek v tej ekonomiji ni samo potrošnik, ampak ustvarjalec. Obilje ni nasprotje odgovornosti. Več prostora in več možnosti zahtevata več transparentnosti, več osebne odgovornosti in jasnejšo zavest o vplivu posameznika na skupni prostor. Zato je struktura BEF namenoma zgrajena tako, da finančni tok, skupna smer in osebna odgovornost stojijo skupaj. ### 3. Triadna arhitektura BEF > **BEF = EXCHANGE + ALIGNMENT + SELF-RESPONSIBILITY / OWN** To niso tri zaporedne funkcije in niso tri ločeni sistemi. So trije enakovredni nosilni stebri istega frameworka. EXCHANGE ureja tok vrednosti. ALIGNMENT ureja skupno smer. SELF-RESPONSIBILITY / OWN vrača odgovornost posamezniku, ko nastane trenje, konflikt ali odmik od lastnih zavez. BEF uporablja načelo TRIAD WITHIN TRIAD: kadar ima posamezen steber naravno notranjo strukturo treh medsebojno odvisnih funkcij, se tudi ta prikaže kot triada. Namen ni numerologija, ampak jasna arhitektura: vsak del ima funkcijo, povezavo z drugima deloma in preverljiv tok. ### 4. EXCHANGE - kako vrednost kroži EXCHANGE je finančni in gospodarski tok BEF. Ne predstavlja samo nakupa ali prodaje LANA, temveč celoten življenjski cikel vrednosti: osebna kapaciteta, realna potrošnja, financiranje toka, treasury recirkulacija, ustvarjanje in dajanje. #### 4.1 Exchange triada > **LANA8WONDER + LANAPAYS.US + COMMON GOOD FUNDING** Prvi nivo Exchangea sestavljajo tri funkcije. LANA8WONDER predstavlja PERSONAL BALANCE - osebno kapaciteto in prehod od rasti k uravnoteženi uporabi. LANAPAYS.US predstavlja CIRCULATION - realno uporabo med potrošniki in ponudniki ter podporne finančne tokove, ki to uporabo omogočajo. COMMON GOOD FUNDING predstavlja CREATION & GIVING - usmerjanje vrednosti v ustvarjanje, podporo in skupno dobro. #### 4.2 LANA8WONDER - Personal Balance Lana8Wonder je osebni steber Exchangea. Njegova funkcija ni neskončno kopičenje, ampak gradnja osebne ekonomske kapacitete skozi omejeno udeležbo, Splite, uporabo, sproščanje in dozorevanje. Dolgoročni cilj je Balanced Wallet logika: dovolj kapacitete za življenje, ustvarjanje, izmenjavo in tok, ne neskončna rast kot sama sebi namen. Podrobna pravila določa P14. #### 4.3 LANAPAYS.US - Circulation LanaPays.us je potrošniški in komercialni steber Exchangea. Tudi ta je organiziran kot triada: CONSUMPTION + CAPITAL INPUT + TREASURY / RECIRCULATION. Te tri funkcije se lahko izvajajo prek različnih pravnih oseb in pogodb; triada je funkcionalni zemljevid, ne ena pravna bilanca. #### 4.3.1 Consumption - consumers + merchants Osrednji dogodek je realna potrošnja. Potrošnik uporablja Registered LANA za realno blago ali storitev, trgovec oziroma ponudnik pa prejme dogovorjeno protivrednost v skladu z izbranim settlement modeom. Merchant infrastruktura, Business Units, ponudbe in transakcijska evidenca so del tega toka. Potrošnja zmanjšuje oziroma obrača Active Consumption Supply ter premika sistem skozi njegov Split lifecycle. #### 4.3.2 Capital Input - Direct.Lana.Fund Direct.Lana.Fund predstavlja Capital Input Layer: ločen tok kapitala, ki podpira nakupe oziroma obveznosti, potrebne za potrošniški flow. Posamezni financing agreements, krogi, limiti, feeji, morebitni returns in vrstni red financiranja ostanejo ločeno dokumentirani in regulatorno klasificirani glede na dejansko substance. Namen te funkcije je podpreti realno cirkulacijo, ne ustvariti samostojnega špekulativnega motorja. #### 4.3.3 Treasury & Recirculation - Lana Discount Lana Discount je proprietary treasury acquisition funkcija. Registered LANA pridobiva v svojem imenu, za svoj račun, z lastnim kapitalom in na lastno ekonomsko tveganje. Treasury nakup, zbiranje in poznejša recirkulacija lahko podpirajo nadaljnji potrošniški cikel, vendar ne predstavljajo avtomatične exchange, cash-out, market-making ali guaranteed-buyback storitve. Podrobna pravila določa P08. #### 4.4 COMMON GOOD FUNDING - Creation & Giving Tretji del Exchange triade usmerja vrednost iz samega kroženja v ustvarjanje in dajanje. Njegova notranja struktura je prav tako triada: CROWDFUNDING + UNCONDITIONAL FUNDING + UNCONDITIONAL PAYMENTS. Community Projects niso četrti enakovredni steber, ampak možna oblika uporabe enega ali več teh treh mehanizmov. #### 4.4.1 Crowdfunding Crowdfunding je predvsem donation/grant usmerjen tok za individualno kreacijo in manjše konkretne projekte. Če konkretna izvedba vsebuje pravico do vračila, yielda, securityja ali druge investicijske pravice, se pravna klasifikacija opravi po dejanski funkciji in ne po imenu Crowdfunding. #### 4.4.2 Unconditional Funding Unconditional Funding je brezpogojna podpora posamezniku ali projektu brez vnaprej določene obveznosti vračila, fiksnega roka, obrestne mere ali zagotovljenega donosa financerju. Prejemnik lahko kasneje prispeva nazaj, če in ko želi ter zmore, vendar mora takšno dejanje ostati ločeno od vnaprej dogovorjene pravne obveznosti, če naj ohrani brezpogojno naravo. #### 4.4.3 Unconditional Payments Unconditional Payments so tok prostovoljnih oziroma vnaprej ne-fiksiranih prispevkov za stroške, skupne potrebe ali druge dovoljene namene, kjer ekosistem ne zahteva, da mora biti nominalno predlagani znesek nujno plačan v celoti. Evidentira se dejanski prispevek in njegov namen. Kadar veljavno pravo ali konkretna pogodba določata obvezni znesek, rok ali plačilno obveznost, imata takšna pravila prednost in se tak tok ne sme prikazovati kot brezpogojen. #### 4.5 Exchange kot ekonomija, ki diha Osnovni življenjski tok je mogoče povzeti kot: RECEIVE / DISTRIBUTE -> USE / CONSUME -> CIRCULATE -> COLLECT / RECIRCULATE -> CREATE / GIVE -> NEXT CYCLE. V Growth Phase lahko kapital, registracija in treasury aktivnosti podpirajo širjenje realne uporabe. V Mature / Balanced State se cilj premakne proti več notranji recirkulaciji in manjši odvisnosti od stalnega zunanjega kapitala. BEF zato uporablja načeli CONSUMPTION BEFORE FINANCIAL EXPANSION in FLOW BEFORE ACCUMULATION. Kapital ima podporno funkcijo toliko časa, kolikor omogoča realno življenje ekonomije. #### 4.6 Registered status, Registrar, Spliti in Supply LANA obstaja na LanaCoin blockchainu. Registered LANA niso nov coin ali nov blockchain, temveč LANA z registriranim statusom znotraj BEF. Status je povezan z registrirano denarnico, identificiranim udeležencem, Registrarjem, registriranim obtokom, pravili uporabe, sistemsko/reference vrednostjo in posameznim Splitom. P24 enako konceptualno strukturo omogoča tudi drugim ACTIVE native coinom. Active Consumption Supply predstavlja celotno količino Registered LANA oziroma coin-specific Registered Native Coin supply, ki sodeluje v trenutnem ciklu. Za LANA trigger P03 dodatno loči Split Release Supply in Open Flow Supply: Open Flow Supply je tisti del current-cycle supplyja, ki je v tem trenutku dejansko še na voljo za nadaljnjo distribucijo, prodajo oziroma potrošniški flow. Potrošnja ga absorbira iz odprtega toka; nove odobrene registracije ali vrnitev količine v odprto recirkulacijo ga lahko med ciklom ponovno povečajo. LANA Split se ne sproži zaradi datuma, želje po višji System / Reference Value ali vnaprej napovedane velikosti. Sproži ga izčrpanje ekonomsko uporabnega Open Flow Supply po reconciliaciji in po potrditvi, da za trenutni cikel ni odobrenega replenishmenta v teku. Velikost naslednjega Splita je ločena odločitev in ostaja adaptivna; podrobno P03. LANA referenčno pravilo Price(n+1) = Price(n) x 2 ostaja LANA-specifična sistemska formula za naslednji cikel, ne napoved odprte tržne cene, likvidnosti ali zagotovljenega donosa. Drugi ACTIVE coini morajo imeti lasten Coin Split Profile. ### 5. ALIGNMENT - kako nastane skupna smer ALIGNMENT ni klasično večinsko glasovanje in ni proces, v katerem ena stran premaga drugo. Njegova funkcija je preveriti, ali lahko skupnost pri materialni odločitvi najde smer, ki jo lahko nosijo vsi upravičeni udeleženci konkretnega procesa. #### 5.1 Proposal Materialna smer mora biti dovolj jasno formulirana, da je mogoče razumeti, kaj se spreminja, kdo je prizadet, kdo ima pravico sodelovati in kateri zapisi ali dokazi so potrebni. #### 5.2 Resistance & Dialogue Veljaven PROTI oziroma resistance ni napaka sistema, ampak informacija. Če se pojavi, se predlog ne preglasuje avtomatično, temveč se razlogi naredijo vidni, predlog se lahko pojasni, spremeni, zoži ali umakne. #### 5.3 Alignment Kjer veljavna pravila zahtevajo 100-% Alignment, se predlog implementira šele, ko je dosežena zahtevana usklajenost upravičenih udeležencev. Če Alignment ni dosežen, predlog v tej obliki ne gre naprej. Prisila v soglasje ni Alignment. Podrobna pravila, zapisi, regulatory override in material-decision scope določa P05. ### 6. SELF-RESPONSIBILITY / OWN - kako se odgovornost vrne posamezniku OWN je proces brezpogojne samoodgovornosti. Ni sodišče in ne ugotavlja kazenske ali civilnopravne krivde. Njegov namen je, da ob konfliktu ali odstopanju od lastnih zavez vsak udeleženec najprej vidi in prevzame svoj del ter ga pretvori v konkretno spremembo. #### 6.1 Reflection Reflection naredi celotno izkušnjo vidno. Udeleženci povedo, kaj se je zgodilo, kako so situacijo doživeli, kaj so naredili in kakšen je bil njihov vpliv. Namen ni obramba pozicije, ampak dovolj celovit pogled, da se lahko prepozna lasten del. #### 6.2 Alignment v OWN V drugi fazi posameznik prepozna svoj del, se po potrebi opraviči, sprejme brezpogojno samoodgovornost in se uskladi glede tega, kaj v njegovem lastnem ravnanju potrebuje spremembo. OWN Alignment ni priznanje pravne krivde in ne zahteva, da se posameznik strinja z vsako razlago druge osebe. #### 6.3 Change Change pretvori uvid v konkretno prihodnjo zavezo. Zaveza mora biti dovolj jasna, da je pozneje mogoče preveriti, ali se isto oziroma vsebinsko bistveno enako ravnanje ponavlja. Reflection brez Change ostane samo razumevanje; Change brez Reflection pa lahko postane prazna skladnost. #### 6.4 Freeze, Silence in vrnitev Če udeleženec ne sodeluje v obveznem OWN procesu ali po zaključenem procesu ponovi isto oziroma bistveno enako ravnanje, zajeto v njegovi lastni Change zavezi, lahko nastopi Freeze skladno s P06. Freeze je sprememba registriranega statusa znotraj BEF in sam po sebi ne pomeni prenosa lastništva blockchain sredstev, zaplembe ali odvzema zasebnega ključa. Pot vrnitve mora ostati jasna in preverljiva. ### 7. Ravnovesje nastane med stebri EXCHANGE brez ALIGNMENTA lahko postane samo trg. ALIGNMENT brez SELF-RESPONSIBILITY lahko obstane v konfliktu ali postane pritisk k navidezni enotnosti. SELF-RESPONSIBILITY brez svobode nestrinjanja lahko postane prisila. BEF zato ravnovesja ne išče z enim dominantnim mehanizmom, ampak z medsebojnim delovanjem vseh treh. Enako velja znotraj Exchangea. LANA8WONDER brez realne cirkulacije bi lahko postal samo akumulacija. LANAPAYS.US brez Creation & Giving bi lahko postal samo komercialni sistem. Common Good brez zdrave osebne kapacitete in cirkulacije bi izgubil vir realnega toka. Triada je zato funkcionalno ravnovesje, ne hierarhija. ### 8. Skupne operativne, pravne in regulatorne plasti Triadna arhitektura ne združuje vseh funkcij v eno pravno osebo. Vsaka operativna družba, pogodba, treasury, financing funkcija, merchant flow, Common Good projekt, governance proces in KYC odločitev ostane pravno ločena ter se klasificira po dejanski substance. BEF uporablja načelo FUNCTION BEFORE LABEL. - LEGAL ENTITIES & ACTIVATION GATES - vsaka materialna funkcija ima identificiranega nosilca, jurisdikcijo, pogodbenega partnerja in regulatorni status; podrobno P15, P22 in P23. - PAYMENTS & CONSUMER PROTECTION - settlement mode, custody/client-funds meje, disclosures, refunds in complaints; podrobno P19. - MARKET INTEGRITY - Split, supply, velike registracije in druge price-sensitive informacije se presojajo ločeno; podrobno P16. - AML / KYC / PRIVACY - Being KYC je ločen od regulatorne Identity Assurance; podrobno P17, P18 in P21. - LIQUIDITY / SOLVENCY / RESILIENCE - notranja cirkulacija ne nadomesti dejanske solventnosti pravnih oseb; podrobno P20. ### 9. Tehnološka in dokazna triada BEF ima tudi podporno infrastrukturno triado: LANACOIN BLOCKCHAIN + LANA NOSTR + DIGITAL BEINGS. Blockchain zagotavlja native asset in transakcijsko plast; Nostr distribuira evente, identiteto, komunikacijo in preverljive podpise; Digital Beings predstavljajo inteligentni agentni sloj. Ta tehnična triada podpira vse tri krovne stebre, vendar jih ne nadomešča. Kritični podatki ne smejo brez izrecne določbe posameznega protokola obstajati samo v eni aplikacijski SQL bazi. Registrar, blockchain, Nostr dogodki, pogodbeni zapisi in drugi evidence layerji skupaj omogočajo regulatorno in operativno preverljivost. Podrobno P09, P11 in P12. ### 10. Multi-asset razvoj in zrela faza LANA ostaja izvorni in referenčni coin BEF. P24 omogoča vključitev izbranih zunanjih native coinov po načelu OWN NETWORK + NATIVE ASSET + DIRECT KEY CONTROL. ACTIVE zunanji coin mora dobiti coin-specific Registrar, Registered Coin status, Total Registered Supply, Active Coin Supply, Split history in Coin Split Profile. Vključitev coina ne pomeni pretvorbe v LANO. Skupna razvojna pot je NATIVE COIN -> REGISTRATION -> REGISTERED COIN -> USE / CIRCULATION -> ACTIVE SUPPLY CHANGE & RECIRCULATION -> SPLIT -> NEXT BALANCED CYCLE. V Growth Phase so Spliti in zunanji kapital lahko pomembnejši; v Mature / Balanced State naj bi prevladovali flow, recirkulacija, release, diversity in manjša potreba po novi količinski rasti. ### 11. Protocol Architecture Map Protokoli P01-P24 ostajajo stabilne normativne enote. Framework 1.0 jih ne preštevilči, ampak jim daje arhitekturno mesto, da se vsebina tudi v nadaljevanju bere skozi isto strukturo. | Pillar / layer | Primary function | Key protocols | | --- | --- | --- | | EXCHANGE > shared mechanics | Registration, merchant use, supply, Splits | P01, P02, P03, P19, P24 | | EXCHANGE > LanaPays.us | Consumption, capital input, purchase/delivery, treasury recirculation | P02, P07, P08, P13, P19, P20 | | EXCHANGE > Common Good | Crowdfunding, Unconditional Funding, Unconditional Payments | P04, P13 | | EXCHANGE > Lana8Wonder | Personal Balance, Balanced Wallet | P14 | | ALIGNMENT | Common direction and governance | P05, supported by P09 | | SELF-RESPONSIBILITY / OWN | Reflection, Alignment, Change, Freeze/return | P06, supported by P09 | | SHARED INFRASTRUCTURE | Evidence, Nostr, Digital Beings, risk, compliance, KYC, legal perimeter | P09-P12, P15-P18, P20-P23 | ### 12. Dokumentna hierarhija, Framework 1.0 in nadaljnji razvoj - Veljavno pravo in zavezujoče odločitve pristojnih organov imajo prednost. - Konkretna pogodba ureja konkretno transakcijo ob upoštevanju prisilnega prava. - BEF Core Framework določa skupna načela in arhitekturo. - BEF Protocols določajo operativna pravila posameznih funkcij in ne smejo biti v nasprotju s Core Frameworkom. - Tehnična dokumentacija in uporabniški vmesniki izvajajo ta pravila in jih ne morejo samostojno spremeniti. BEF je Living Framework. Framework Version 1.0 pomeni, da je krovna arhitektura dovolj določena, da dokument ni več označen kot draft. To ne pomeni, da so vsi možni produkti, pravne osebe, jurisdikcije, coini ali bodoče funkcije avtomatično aktivni. Annex C od 1.0 naprej vodi ACTIVATION & IMPLEMENTATION CONDITIONS: pravni memo, numeric evidence, licenca, DPIA, tehnični standard ali drug pack je obvezen pred aktivacijo funkcije, na katero se nanaša. HOLD je produkcijski gate, ne znak, da je celoten Framework nedokončan. Prihodnje materialne spremembe Core arhitekture morajo biti javno verzionirane in obrazložene; manjše operativne parametre lahko veljavni policy spreminja v dovoljenem okviru brez ponovnega izuma BEF. ## BEF-P01 - REGISTERED LANA & REGISTRAR PROTOCOL ``` Protocol ID: BEF-P01 | Framework Version: 1.0 | Architecture: EXCHANGE > SHARED MECHANICS > REGISTRATION ``` ### 1. Namen P01 določa registrski sloj BEF: kaj pomeni Registered status, kako se registrirajo denarnice in LANA ter kako se zagotavlja preverljivost registriranega obtoka. ### 2. Registered Wallet Vsaka Registered LANA Wallet je povezana z identificiranim udeležencem. V registriranem delu sistema niso namenoma predvidene anonimne denarnice, pri katerih Registrar ne bi imel podatka o pripadajočem udeležencu. Posamezen udeleženec lahko uporablja več registriranih denarnic. ### 3. Registered status Registered status ni nov blockchain asset, ampak operativni status LANA znotraj BEF. Status se vodi v registrskem sloju in mora biti mogoče povezati z registrirano denarnico in ustreznim registrskim dogodkom. ### 4. Registracija novih LANA Non-Registered LANA lahko pridobijo Registered status le skozi definiran Registration Event. Sam blockchain prenos Non-Registered LANA na registrirano denarnico ne pomeni avtomatične registracije. ### 5. Ingress Event Prihod Non-Registered LANA na Registered Wallet se evidentira kot dogodek, ki zahteva obravnavo po veljavnih pravilih Registrarja. Namen je preprečiti nenadzorovano povečanje registriranega obtoka. ### 6. Minimalni Registration Event podatki - Event ID, datum in čas. - Količina LANA. - Registered Wallet. - Vrsta registracijskega dogodka in razlog. - Povezani projekt / Common Good namen, kadar obstaja. - Split. - Vpliv na Total Registered Supply in Active Consumption Supply. ### 7. Osebni podatki Registrar mora poznati identiteto pripadajočega udeleženca, vendar javna objava osebnih podatkov ni avtomatična posledica registracije. Javna in nejavna polja se morajo ločiti skladno z veljavnimi pravili varstva osebnih podatkov. Javni blockchain naslov in njegove transakcije so po svoji naravi lahko javno preverljivi. ### 8. Status Events Registrar evidentira pomembne spremembe statusa, vključno z registracijo, Freeze in Unfreeze dogodki, kadar so ti povezani z Registered Wallet statusom. ## BEF-P02 - MERCHANT & CONSUMPTION PROTOCOL ``` Protocol ID: BEF-P02 | Framework Version: 1.0 | Architecture: EXCHANGE > LANAPAYS.US > CONSUMPTION ``` ### 1. Namen P02 določa uporabo Registered LANA znotraj registriranega potrošniškega okolja ter vlogo trgovcev in TheLana.life kot Transparency & Consumption Layerja. ### 2. Funkcija Registered LANA Primarna funkcija Registered LANA znotraj BEF je uporaba za blago in storitve v registriranem okolju. BEF ne vzpostavlja odprtega P2P order-book trga Registered LANA. ### 3. Registrirani trgovci Sodelujoči trgovci oziroma ponudniki blaga in storitev se vključujejo na podlagi pravil in pogodbenega razmerja, ki opredeli njihovo sodelovanje v mreži. Seznam oziroma status sodelujočih ponudnikov mora biti mogoče transparentno preveriti. ### 4. TheLana.life TheLana.life javnosti prikazuje dejansko življenje ekonomije: trgovce, potrošniške transakcije, relevantne agregate, aktualni Split in druge kazalnike. Framework se izogiba fiksnim številkam tam, kjer se stanje dinamično spreminja, in uporablja live pregled. ### 5. Limited-network regulatorna hipoteza BEF je zasnovan kot omejeno registrirano potrošniško okolje. MiCA Article 4(3)(d) določa izjemo za ponudbo, kjer lahko imetnik kriptosredstvo uporablja samo za blago in storitve v omejeni mreži trgovcev s pogodbenimi razmerji z offerorjem. Ali konkretna izvedba izpolnjuje vse pogoje te izjeme, se mora spremljati na podlagi dejanske mreže, ponudb in drugih relevantnih okoliščin. ### 6. Neprestano spremljanje perimetra Ker se mreža lahko razvija, se limited-network presoja ne obravnava kot enkratna etiketa. Posebej se spremljajo obseg mreže, vrsta sodelujočih ponudnikov, način uporabe Registered LANA, morebitne javne ponudbe in povezava istega osnovnega LanaCoin sredstva z odprtimi trgi. ### 7. Settlement Mode A - Direct Registered LANA Merchant Settlement Potrošnik lahko za blago ali storitev prenese Registered LANA neposredno na Registered Wallet trgovca. V tem načinu trgovec prejme LANA kot dogovorjeno protivrednost. Morebitna poznejša prodaja LANA s strani trgovca je nov in ločen pravni dogodek in ne del samega merchant plačila. ### 8. Optional Settlement Mode B - Separate Principal Purchase + Merchant FIAT Settlement BEF lahko podpira ločen povezani Mode B, v katerem potrošnik prenese Registered LANA posebej določenemu principal purchaserju, ta pa iz lastnih fiat sredstev izvrši merchant settlement. Mode B ni privzeta niti inherentna funkcija Lana Discount. Če je purchaser Lana Discount ali druga treasury družba, se takšen merchant-linked flow ne sme avtomatično šteti za P08 proprietary treasury acquisition: povezava s potrošniškim checkoutom, navodilom potrošnika ali poravnavo merchantove terjatve lahko ustvari client/payment-service značilnosti in zahteva ločeno klasifikacijo. LanaPays infrastruktura lahko tehnično povezuje evente samo ob jasni pravni ločitvi funkcij. ### 9. No client-funds pooling by default Osnovni design P02 ne predpostavlja, da LanaPays ali druga tehnična platforma prejema in združuje potrošniški fiat z namenom nadaljnjega nakazila trgovcem. Če bi katera implementacija kadarkoli držala ali prenašala klientskih funds v smislu payment law, mora pred aktivacijo dobiti ustrezen payment-services status oziroma uporabiti licenciranega PSP in safeguarding model. ### 10. Separate Mode B regulatory gate Mode B se vedno presoja ločeno od čistega P08 treasury nakupa. Lasten kapital principal purchaserja sam po sebi ne zapre CASP/payment perimetra, če ekonomska substance kaže storitev za consumerja ali merchanta. Zato Mode B zahteva entity-specific crypto-service in payment-perimeter memo. Če tak memo ni zaključen, se uporablja Mode A ali ločen poznejši treasury acquisition, pri katerem merchant oziroma drug imetnik po zaključenem merchant poslu samostojno nastopi kot seller/counterparty do Lana Discounta. ### 11. Limited network - MiCA and PSD2 are separate tests MiCA limited-network presoja za ponudbo Registered LANA in PSD2 limited-network presoja za specific payment instrument sta dva ločena pravna testa. Uporaba ene izjeme ne dokazuje avtomatične uporabe druge. P15 in P19 zahtevata ločeni evidence pack in ločeno notification monitoring logiko. UK uporablja ločene teste. MiCA limited-network exemption se v UK ne prenaša. Za UK financial-promotion in prihodnji crypto perimeter se posebej preveri definicija qualifying cryptoasset ter morebitna limited-use izključitev; BEF se nanjo ne opira, če dejanske pravice vključujejo prenos ali prodajo za money/other crypto izven dovoljenega issuer-redemption scenarija. ### 12. Merchant contract minimum Merchant pogodba mora najmanj določiti: kateri settlement mode trgovec sprejema; kdo je njegov contract counterparty; ali prejme LANA ali fiat; kdaj je obveznost potrošnika poravnana; kdo nosi execution/settlement tveganje; katere provizije veljajo; complaint/refund proces; ter kateri pravni subjekt je odgovoren za posamezno funkcijo. Nobena merchant pogodba ne sme avtomatično ustvariti pravice potrošnika ali merchanta, da zahteva treasury nakup od Lana Discounta. ### 13. Consumption Incentive Policy BEF lahko pri kvalificirani realni potrošnji uporablja nastavljiv Consumption Incentive. V trenutno opisani LANA referenčni postavitvi je incentive lahko od 0 % do 20 % vrednosti kvalificiranega nakupa, v praksi praviloma v območju približno 5 % do 20 %. Politika lahko določi enak odstotek za consumerja in merchanta. Odstotek je operativni parameter in ne trajna pravica, obljubljeni donos ali obvezna lastnost vseh BEF coinov. ### 14. Fiat-routed purchase Če consumer plača blago ali storitev v fiatu in je transakcija vključena v veljavni BEF consumption flow, lahko sistem skladno z objavljeno policy evidentira consumer/merchant incentive ter ločeno povezani principal acquisition dogodek. Vir vsakega incentiva, asset, v katerem je incentive dodeljen, odgovorni subjekt, davčna obravnava in settlement pot morajo biti razvidni. BEF ne predpostavlja nedokumentiranega client-funds poolinga. ### 15. Direct Registered Coin payment Če consumer plača neposredno z Registered LANA oziroma z drugim ACTIVE Registered Native Coinom, consumer po privzeti referenčni logiki ne prejme dodatnega consumption incentiva samo zato, ker je plačal z registered assetom. Merchant prejme registered asset neposredno v MODE A. Če merchant namesto tega prejme fiat iz lastnih sredstev ločenega principal purchaserja, se uporablja samo aktivirani in pravno zaključen MODE B / P19 model; tak purchaser mora biti pravno in finančno ločen od consumerjevega plačila, kjer to zahteva veljavno pravo. ### 16. Incentive transparency Vsaka UI ali merchant ponudba mora pred checkoutom jasno pokazati veljavni incentive, komu pripada, v katerem assetu, kdo ga financira, ali obstaja limit ter ali je rezultat odvisen od kasnejšega Registration Eventa ali drugega pogoja. Spremenljiva incentive politika se ne sme predstavljati kot zagotovljena prihodnja ekonomska korist. ## BEF-P03 - SPLIT, SUPPLY & REGISTRATION PROTOCOL ``` Protocol ID: BEF-P03 | Framework Version: 1.0 | Architecture: EXCHANGE > SHARED MECHANICS > SPLIT & SUPPLY ``` ### 1. Namen Splita Split je state transition med dvema zaporednima ekonomskima cikloma in hkrati mehanizem doziranja gospodarske kapacitete. Ni koledarsko določen, ne nastane zgolj zaradi želje po spremembi sistemske cene in ni avtomatsko vezan na vnaprej določeno velikost naslednjega cikla. ### 2. Rast ni vnaprej izračunana pot Growth Phase ima jasno smer - širjenje realne uporabe in osebne ekonomske kapacitete proti Mature / Balanced State - vendar BEF ne predpostavlja, da je mogoče vnaprej izračunati vsako stopnjo te poti. Posamezen Split je odziv na dejansko življenje ekonomije. Lahko je bistveno večji od prejšnjega, le zmerno večji ali se pozneje približa maintenance/renewal ritmu. Za velikost supplyja ne obstaja obvezna formula tipa Supply(n+1) = k x Supply(n). ### 3. Split Release Supply Split Release Supply je količina Registered LANA, ki je ob začetku konkretnega Splita namensko sproščena v current-cycle open flow. V LANA referenčni implementaciji lahko pomemben del te količine izvira iz Lana8Wonder / Personal Balance growth procesa, iz že obstoječe recirkulirane količine ter iz drugih vnaprej dokumentiranih virov. Split sam po sebi ne minta novih blockchain LANA. ### 4. Open Flow Supply - proste LANA trenutnega cikla Open Flow Supply je merljivi del current-cycle Registered LANA, ki je v danem trenutku še ekonomsko uporaben in dejansko razpoložljiv za nadaljnjo distribucijo, prodajo, merchant flow ali drugo dovoljeno potrošniško uporabo. Ne vključuje količin, ki so rezervirane, pravno ali tehnično nedosegljive, že poravnane v končno current-cycle pozicijo ali namenjene prihodnjemu ciklu brez veljavne poti nazaj v sedanji open flow. ### 5. Absorption skozi realno uporabo Ko se Registered LANA skozi dovoljeno distribucijo in realno potrošnjo prenesejo iz odprtega supplyja v registrirane denarnice oziroma pozicije, ki niso več na voljo za isto current-cycle odprto distribucijo, so za namen triggerja absorbirane. Absorption ni uničenje coina in ne pomeni nujno trajnega locka; pomeni, da konkretna količina trenutno ne predstavlja več proste gospodarske kapacitete tega Splita. Poznejša recirkulacija zahteva nov dovoljen in evidenčno sledljiv dogodek. ### 6. Računovodska identiteta Open Flow Supply > **Za LANA referenčni cikel se mora Open Flow Supply dati neodvisno rekonstruirati iz Registrarja in povezanih eventov: OPEN FLOW SUPPLY = OPENING SPLIT RELEASE + APPROVED IN-CYCLE ADDITIONS + RETURNED OPEN-FLOW RECIRCULATION - ABSORBED / SETTLED OUTFLOW. To je merilna identiteta stanja, ne napoved prihodnje rasti in ne finančni model, ki bi določal velikost naslednjega Splita.** ### 7. Split Exhaustion Trigger LANA Split trigger nastopi, ko je Open Flow Supply trenutnega cikla izčrpan: ekonomsko uporabna količina je nič oziroma pod vnaprej objavljenim coin-specific tehničnim de-minimis pragom, pending settlementi so reconciled in za trenutni cikel ni že odobrene dodatne release/registration količine, ki bi Open Flow Supply ponovno povečala. Če obstaja odobren replenishment v teku, trigger še ni dosežen. > **TRIGGER = EXHAUSTED OPEN FLOW SUPPLY + RECONCILIATION COMPLETE + NO APPROVED CURRENT-CYCLE REPLENISHMENT PENDING** ### 8. Zakaj je trigger merljiv, pot pa adaptivna BEF zato ne potrebuje formule, ki bi vnaprej napovedovala trajanje ali velikost Splita. Pot cikla je lahko različna, končna state condition pa je preverljiva. Trg in potrošnja lahko absorbirata supply hitreje ali počasneje; dodatna registracija lahko cikel podaljša; recirkulacija lahko del količine vrne v open flow. Vsi ti dogodki spreminjajo stanje, vendar je konec cikla vedno vezan na dejansko izčrpanje open flowa, ne na koledar. ### 9. Split Event procedure Ob triggerju Registrar oziroma odgovorni evidence layer pripravi Split Event najmanj z: Split ID/sequence, timestampom, opening Split Release Supply, vsemi in-cycle additions, recirculation returni, absorbed/settled outflowom, končnim Open Flow Supply stanjem, morebitnim objavljenim de-minimis pragom, pending-settlement reconciliation rezultatom, potrditvijo no-pending-replenishment pogoja, uporabljeno System / Reference Value metodologijo, source/authority recordom in povezavo na P16 market-integrity assessment, kjer je relevanten. ### 10. Adaptive Supply Decision - velikost naslednjega Splita Velikost naslednjega Splita ni določena z univerzalnim multiplierjem. Določi se adaptivno glede na dejansko absorpcijsko kapaciteto: realno potrošnjo, merchant in consumer rast, hitrost kroženja, recirkulacijo, razpoložljivo infrastrukturo, Common Good potrebe, treasury/settlement capacity, registracijske vire, koncentracijo in druge javno navedene stabilizacijske indikatorje. Odločitev uporablja človeško oziroma governance presojo, vendar ne sme biti skrita: količina, vir, razlog in uporabljeni live indikatorji se evidentirajo v Split Release Recordu. ### 11. Registration during Split Med aktivnim Splitom se lahko z novim Registration Eventom Open Flow Supply poveča, kadar obstaja dokumentiran razlog - predvsem Common Good, razširitev realne uporabe ali stabilizacija cikla, ki se zaradi absorpcije izteka hitreje, kot je operativno smiselno. Tudi količina nove registracije je adaptivna in ni vezana na fiksni odstotek prejšnjega supplyja. Vsaka registracija mora pokazati source, amount, purpose, wallet/namespace, Split in vpliv na Open Flow Supply. ### 12. Cycle duration je feedback, ne trigger BEF lahko spremlja, ali so Spliti operativno prekratki ali predolgi, vendar trajanje samo po sebi ne sproži prehoda. Zelo hiter drain lahko kaže, da je bila release količina premajhna oziroma da je potrebna dokumentirana stabilizacijska registracija. Zelo počasna absorpcija lahko pomeni, da mora biti prihodnji release bolj konservativen. Čas je zato diagnostični signal za doziranje, ne datum zapadlosti Splita. ### 13. Dosing Principle in market integrity Namen doziranja je, da se v open flow ne sprosti količina, ki je realna potrošnja in infrastruktura ne moreta smiselno absorbirati. Supply discipline zmanjšuje tveganje prekomerne ponudbe in ohranja operativno kontinuiteto. Ni dovoljena uporaba registracije, zadrževanja supplyja ali Split komunikacije z namenom ustvarjanja lažnega povpraševanja, zavajajoče scarcity ali manipulacije odprte tržne cene underlying coina. Kadar lahko Split, supply ali registration informacija vpliva na odprti trg, velja P16. ### 14. Recirculation Before Registration Osnovno načelo ostaja ponovno kroženje že obstoječe vrednosti pred povečevanjem registriranega obtoka, kadar je takšna recirkulacija dejansko razpoložljiva in primerna. Nova registracija ostaja dovoljena za Common Good, rast realne kapacitete in stabilizacijo, vendar mora biti njen namen ločen od arbitrarnega cenovnega upravljanja. ### 15. System / Reference Value rule je ločen od supply-size rule Po trenutno veljavnem LANA pravilu se ob veljavno aktiviranem naslednjem Splitu System / Reference Value spremeni po formuli Price(n+1) = Price(n) x 2. To pravilo ne pomeni, da se mora količina supplyja prav tako podvojiti. Price-transition formula in Adaptive Supply Decision sta dve ločeni stvari. Kadar se System / Reference Value uporabi kot dejanska pogodbena cena, veljajo Annex H, P07/P08/P19 in druga relevantna pravila. Vsaka prihodnja sprememba price-rule mora biti verzionirana, objavljena pred učinkom, prestati P16 assessment in Alignment/governance postopek, kjer ga veljavna pravila zahtevajo; retroaktivna sprememba za že zaključen cikel ni dovoljena. ### 16. Growth -> Mature / Balanced renewal V zgodnjem Growth Phase lahko successive Spliti hitro povečujejo ekonomsko kapaciteto, ker sistem šele gradi mrežo ljudi, trgovcev, denarnic in realne uporabe. Dolgoročna vizija je široko dostopna Balanced Wallet ekonomija, vendar to ni zagotovilo univerzalne udeležbe ali vnaprej določenega datuma. Ko se sistem približuje Mature / Balanced State, lahko rast preide v renewal: recirkulacijo, nadomeščanje deaktiviranih oziroma zaključenih udeležb, vstop novih udeležencev in toliko nove kapacitete, kolikor jo realno življenje ekonomije potrebuje. Podrobne maturity metrike ostajajo CP-59. ### 17. Multi-asset separation Registracija drugih ACTIVE Native Coinov lahko poveča skupno gospodarsko kapaciteto BEF, vendar vsak coin ohrani svoj coin-specific Registrar, Active Coin Supply in Split lifecycle. Zunanji coin ne matematično dopolni LANA Open Flow Supply samo zato, ker je del istega frameworka. Vsak Coin Split Profile mora določiti lasten trigger oziroma izrecno sprejeti exhaustion model na način, ki je preverljiv za njegovo mrežo. ### 18. Pre-Split Release Principle LANA referenčna ekonomija uporablja načelo, da Registered LANA niso namenjene pasivnemu več-Split holdanju samo zaradi value-transition pravila. Udeleženci, ki nimajo izrecne veljavne carry izjeme, morajo pred relevantnim Splitom svojo količino uporabiti, prenesti, sprostiti, prodati v ločeni dovoljeni transakciji ali drugače urediti skladno z registrskimi pravili. Natančen cutoff, izjeme in dokazila so del Split Policy in Registrar evidence packa. ### 19. Consumption-Support One-Split Carry Posebna referenčna izjema je lahko dovoljena principal/proprietary capital providerju, ki z lastnimi sredstvi neposredno podpira realno potrošnjo in v ločenem acquisition procesu pridobi Registered LANA. Tak eligible holder lahko skladno z objavljeno politiko pridobljene LANA prenese čez en naslednji Split. Namen izjeme je financiranje potrošniškega toka, ne ustvarjanje splošne pravice do več-Split akumulacije. ### 20. Carry ends after one Split One-Split Carry ni trajna pravica. Po izteku dovoljenega cikla mora biti pozicija uporabljena, realizirana, sproščena, recirkulirana ali drugače zaključena po veljavnem protokolu; nova carry pravica lahko nastane samo iz novega kvalificiranega consumption-support dogodka. Registrar mora razlikovati ordinary Registered balance od balancea z veljavno carry oznako ter evidentirati začetek, Split in prenehanje carry statusa. ### 21. Regulatory gate for carry economics Ker kombinacija financiranja potrošnje, posebnega holding privilege in Split value-transition pravila lahko glede na substance vpliva na securities/investment/collective-investment, consumer, tax ali druge perimetre, se produkcijska uporaba one-Split carry modela aktivira samo po CP-60 in entity/jurisdiction-specific klasifikaciji. Izraz investor ali professional investor se uporablja le, kadar ga dejanska pravna klasifikacija podpira. ## BEF-P04 - COMMON GOOD FUNDING PROTOCOL ``` Protocol ID: BEF-P04 | Framework Version: 1.0 | Architecture: EXCHANGE > COMMON GOOD FUNDING ``` ### 1. Namen in Common Good Requirement P04 določa Creation & Giving steber znotraj Exchange arhitekture. Nova registrirana vrednost mora imeti razumljiv in dokumentiran Common Good Purpose. Registracija zgolj zaradi zasebne špekulativne koristi ni namen tega mehanizma. ### 2. Common Good triada > **CROWDFUNDING + UNCONDITIONAL FUNDING + UNCONDITIONAL PAYMENTS** Tri funkcije so enakovredni kanali skupnega dobrega. Crowdfunding usmerja podporo v konkretno kreacijo. Unconditional Funding daje brez vnaprej določene obveznosti vračila. Unconditional Payments omogočajo prostovoljne oziroma vnaprej ne-fiksirane prispevke za dovoljene stroške in skupne potrebe. Community Projects so lahko vsebinski namen, ki uporabi enega ali več teh kanalov; niso četrti steber triade. ### 3. Crowdfunding Crowdfunding je namenjen predvsem individualni kreaciji in mikro podporam. Tipični projekti so manjši, konkretni in usmerjeni v izdelek, storitev, umetnost, tehnologijo, idejo ali drugo ustvarjalno delo. Namen ni koncentracija kapitala, temveč omogočanje več resničnih kreacij. Grant/donation model se pravno loči od lending/investment modela. ### 4. Unconditional Funding Unconditional Funding omogoča brezpogojno podporo posamezniku ali skupnostnemu projektu. Osnovno načelo je, da ni vnaprej dogovorjene pogodbene obveznosti vračila, fiksnega roka, obvezne glavnice, obrestne mere ali zagotovljenega donosa financerju. Prejemnik lahko kasneje prispeva nazaj, če in ko želi ter zmore; to poznejše dejanje mora ostati ločeno od vnaprej dogovorjene obveznosti, če naj ohrani brezpogojno naravo. ### 5. Unconditional Payments Unconditional Payments omogočajo evidentiran prostovoljni oziroma vnaprej ne-fiksirani prispevek za strošek, skupno potrebo ali drug dovoljen namen. Predlagani znesek je lahko orientacijski in dejansko plačilo je lahko nižje ali višje, če pravila konkretnega toka to dovoljujejo. Če zakon, davčna obveznost ali pogodba določa obvezni znesek oziroma rok, se ta tok ne sme uporabljati za prikrivanje ali zmanjševanje pravne obveznosti. ### 6. Registration Event linkage Če katerikoli Common Good tok povzroči novo registracijo LANA oziroma drugega Registered Native Coina, mora biti Registration Event povezljiv s konkretnim namenom, količino, prejemnikom oziroma Registered Walletom, Splitom in datumom. ### 7. Community Projects Community Project je vsebinski oziroma infrastrukturni namen skupnega dobrega. Financira se lahko prek Crowdfundinga, Unconditional Fundinga, Unconditional Payments ali druge izrecno klasificirane poti. Lana Discount je lahko predmet skupnostne podpore za kapitalizacijo lastnega treasuryja, vendar njegovi poznejši treasury nakupi ostajajo P08 proprietary own-account dejanja in ne javna liquidity, market-making ali guaranteed-buyback storitev. ### 8. Transparentnost Za Common Good tok naj bo mogoče preveriti nosilca, namen, zahtevani oziroma orientacijski znesek, dejansko prejeti znesek, status, povezane registracijske dogodke in relevantne rezultate oziroma uporabo sredstev, v obsegu, ki je skladen z veljavnimi pravili varstva podatkov in regulatornimi zahtevami. ## BEF-P05 - ALIGNMENT GOVERNANCE PROTOCOL ``` Protocol ID: BEF-P05 | Framework Version: 1.0 | Architecture: ALIGNMENT ``` ### 1. Namen P05 določa ALIGNMENT kot drugi krovni steber BEF. Alignment je proces iskanja skupne smeri pri materialnih odločitvah in ni klasično večinsko preglasovanje. ### 2. Alignment process > **PROPOSAL -> RESISTANCE / DIALOGUE -> ALIGNMENT** Predlog mora biti dovolj jasen, da udeleženci razumejo njegov namen in posledice. Veljaven resistance oziroma PROTI se obravnava kot informacija, ki zahteva pojasnilo, spremembo, zožitev ali umik predloga. Alignment je dosežen šele, ko je izpolnjen veljavni prag konkretnega procesa. ### 3. 100-% Alignment Pri odločitvah, za katere veljavna pravila zahtevajo 100-% Alignment, mora biti dosežen Alignment vseh upravičenih udeležencev konkretnega procesa. Če obstaja veljaven glas PROTI, predlog v tej obliki ni aligned in se ne implementira. ### 4. Resistance Resistance ni napaka ali neposlušnost. Je signal, da obstaja materialna skrb, nejasnost ali konflikt smeri. Razlog resistance mora biti mogoče zapisati in obravnavati brez avtomatične osebne sankcije. ### 5. Če Alignment ni dosežen Če Alignment ni dosežen, se predlog ne izvede v tej obliki. Lahko se spremeni, razdeli, odloži ali umakne. Udeleženec ne sme biti prisiljen v lažen Alignment samo zato, da bi proces formalno dosegel 100 %. ### 6. Materialne odločitve Alignment se uporablja za tiste materialne skupnostne oziroma sistemske odločitve, za katere veljavni BEF rulebook, protokol ali governance scope izrecno določa tak način odločanja. Vsakodnevne operativne odločitve pravne osebe ne postanejo avtomatično predmet 100-% Alignmenta. ### 7. Alignment Record Za materialni Alignment se vodi preverljiv record z identifikatorjem predloga, verzijo vsebine, upravičenimi udeleženci, glasovi oziroma statusi, časom, morebitnimi resistance razlogi in končnim rezultatom. Record se lahko tehnično objavi prek Nostr governance eventov skladno s P09/P11. ### 8. Razmerje do prava Alignment ne more izključiti prisilnega prava, zakonskih pravic, regulatornih odločitev, fiduciary duties ali obveznosti odgovorne pravne osebe. Če zakon zahteva dejanje ne glede na Community Alignment, se uporabi Regulatory Override Event in se razlog transparentno zabeleži. ### 9. Odprta tehnična postavka Pred produkcijsko uporabo materialnega Alignment procesa mora biti tehnično zaprt canonical Alignment Record format, način določanja eligibility snapshot-a, verzioniranje predloga, evidence resistance ter povezava med governance eventom in pravno izvedbo konkretne odločitve. To je activation condition za materialni governance flow in ne pogoj za obstoj Frameworka 1.0. ## BEF-P06 - UNCONDITIONAL SELF-RESPONSIBILITY / OWN PROTOCOL ``` Protocol ID: BEF-P06 | Framework Version: 1.0 | Architecture: SELF-RESPONSIBILITY / OWN ``` ### 1. Temeljno načelo Vsak udeleženec ob vključitvi sprejme načelo brezpogojne samoodgovornosti. OWN ni sodišče in ne ugotavlja kazenske ali civilnopravne krivde. Namen je prepoznati lasten del, ga uskladiti in spremeniti prihodnje ravnanje. ### 2. OWN triada > **REFLECTION -> ALIGNMENT -> CHANGE** OWN je zaključen proces treh medsebojno odvisnih faz. Reflection naredi izkušnjo vidno. Alignment vrne posameznika k njegovemu delu samoodgovornosti. Change to prevede v konkretno prihodnjo zavezo. Nobena od treh faz sama zase ne predstavlja celotnega OWN procesa. ### 3. Reflection V Reflection vsak udeleženec opiše izkušnjo, svoje zaznavanje, ravnanje in posledice. Cilj je, da postane dovolj celotnega dogajanja vidnega, da lahko posameznik prepozna svoj del brez avtomatičnega prelaganja odgovornosti na druge. ### 4. Alignment v OWN V Alignment fazi udeleženec prepozna svoj del, se po potrebi opraviči, sprejme brezpogojno samoodgovornost in opredeli, kaj v njegovem lastnem ravnanju potrebuje spremembo. To ni pravno priznanje krivde in ne zahteva soglasja z vsako trditvijo druge osebe. ### 5. Change Change ustvari konkretno zavezo prihodnjemu vedenju. Zaveza mora biti dovolj določna, da je pozneje mogoče razumeti, kaj se šteje za isto ali vsebinsko bistveno enako ponovitev. ### 6. Change Commitment Record Zaključena Change zaveza se evidentira z udeležencem, datumom, opisom zaveze, povezanim OWN procesom in statusom. Javni oziroma nejavni del zapisa se loči glede na privacy, evidence in governance pravila. ### 7. Vsak lahko sproži proces OWN lahko sproži vsak udeleženec proti kateremukoli drugemu udeležencu v obsegu, ki ga dovoljujejo pravila. Povabljeni udeleženec se mora na veljavno sprožen proces odzvati. ### 8. Odgovornost pobudnika Tudi pobudnik nosi brezpogojno samoodgovornost za uporabo procesa. Zloraba, šikaniranje, serijsko neutemeljeno odpiranje postopkov ali uporaba OWN kot sredstva pritiska so lahko sami predmet Reflection/OWN obravnave. ### 9. Brez neskončnih procesov za isto stvar Ko je vsebina obravnavana in je Change zaveza jasno zaključena, se isti dogodek ne uporablja za neskončno ponavljanje procesa. Nov OWN je relevanten, če nastane nova materialna okoliščina ali ponovitev ravnanja, ki je zajeto v lastni Change zavezi. ### 10. Automatic Freeze ob kršitvi lastne zaveze Če se po zaključenem OWN procesu ponovi isto oziroma vsebinsko bistveno enako ravnanje, ki ga zajema lastna Change zaveza, lahko nastopi Freeze skladno z veljavnimi pravili. Mehanizem mora imeti preverljivo povezavo med prejšnjo zavezo, novim dogodkom in statusnim eventom. ### 11. Varovalo pred napačnim Freeze-om Freeze se ne sme sprožiti zgolj na podlagi nejasnega avtomatskega semantičnega ujemanja. Kadar ni očitne identitete ravnanja, mora obstajati ustrezna človeška oziroma governance presoja skladno z veljavnimi pravili. ### 12. Freeze Freeze pomeni začasno spremembo registriranega statusa znotraj BEF. Sam po sebi ne prenese lastništva blockchain sredstev, ne zapleni native asseta in ne odvzame zasebnega ključa. ### 13. Silence Silence je procesni status, v katerem se komunikacijski oziroma fasilitacijski fokus začasno ustavi, dokler niso izpolnjeni pogoji za nadaljevanje. Njegov pomen, trajanje in povezava s Freeze statusom morajo biti razvidni iz veljavnih pravil in eventov. ### 14. Unfreeze in vrnitev Pot vrnitve mora ostati jasna in preverljiva. Ko posameznik zaključi zahtevani proces in izpolni veljavne Change pogoje, se lahko status vrne v LIVE prek ustreznega Unfreeze dogodka. ### 15. OWN ni sodišče in ni prisila v Alignment OWN ne nadomešča sodišča, regulatorja, policije, pogodbenih pravic ali drugih pravnih postopkov. Hkrati ne zahteva, da posameznik opusti legitimno nestrinjanje. Samoodgovornost pomeni prevzem lastnega dela, ne avtomatičnega prevzema celotne krivde ali sprejema tuje interpretacije. ## BEF-P07 - BUYLANA.COM / REGISTERED LANA PURCHASE & DELIVERY PROTOCOL ``` Protocol ID: BEF-P07 | Framework Version: 1.0 | Architecture: EXCHANGE > LANAPAYS.US > PURCHASE & DELIVERY ``` ### 1. Namen P07 določa osnovni model, po katerem samostojno operativno podjetje z uporabnikom sklene pogodbo o nakupu in dobavi Registered LANA. Javni uporabniški servis za ta proces se v BEF imenuje BuyLana.com. ### 2. BuyLana.com - Purchase & Delivery Service BuyLana.com je javni user-facing portal oziroma servis za nakup Registered LANA po P07. Njegova funkcija je kupcu jasno predstaviti konkretno prodajno razmerje in omogočiti sklenitev Purchase & Delivery pogodbe z identificirano operativno družbo. BuyLana.com ni poimenovan ali predstavljen kot exchange, trading venue, fund, broker ali guaranteed-liquidity service. Če tehnični operator BuyLana.com ni ista pravna oseba kot seller, morata biti njuni vlogi v uporabniškem vmesniku in pogodbeni dokumentaciji jasno ločeni. ### 3. Nakupni flow na BuyLana.com 1. Kupec odpre BuyLana.com in pred potrditvijo vidi identiteto sellerja oziroma operating company, jurisdikcijo, veljavno verzijo BEF, Split, Offer / Sale Price ter bistvene pogoje ponudbe. 2. Kupec vnese oziroma izbere svojo Registered LANA Wallet Address. Če denarnica ali identiteta še ni ustrezno registrirana, se pred zaključkom nakupa izvede veljavni P01/P21 registration oziroma identity-assurance korak, kadar je potreben. 3. BuyLana.com pred sklenitvijo prikaže fiat kupnino, točno oziroma izračunljivo fiksno količino Registered LANA, delivery pravila, refund pravila, morebitne feeje in obvezna consumer/regulatory disclosures. 4. Kupec sklene Agreement for Purchase and Delivery of Registered LANA neposredno z jasno imenovano operativno družbo. 5. Kupec plača kupnino na račun sellerja oziroma po drugi jasno opredeljeni dovoljeni payment poti. BuyLana.com po defaultu ne pomeni poolinga klientskih fiat sredstev; če bi tehnična izvedba vključevala regulirano payment funkcijo, se aktivira P19 gate. 6. Operativna družba v dogovorjenem Splitu dobavi dogovorjeno količino Registered LANA neposredno na kupčevo Registered LANA Wallet Address. Dobava se dokazuje z blockchain transakcijo in ustreznim Registrar eventom. 7. Po dobavi kupec uporablja Registered LANA skladno z BEF, zlasti P02 Merchant & Consumption Protocol. Sam nakup prek BuyLana.com ne ustvarja pravice do poznejše prodaje, zagotovljenega buybacka, likvidnosti ali donosa. ### 4. Osnovno razmerje Kupec plača vnaprej dogovorjeno kupnino v EUR oziroma drugi pogodbeno dovoljeni fiat valuti za konkretno jurisdikcijo. Operativna družba se zaveže, da bo v dogovorjenem Splitu na vnaprej določeni Registered LANA Wallet Address dobavila fiksno dogovorjeno količino Registered LANA. ### 5. Ključni podatki pogodbe - Pogodbeni stranki. - Kupnina in dogovorjena fiat valuta. - Dogovorjena količina Registered LANA. - Split številka. - Registered LANA Wallet Address. - Veljavna verzija BEF. ### 6. Denarnica Registered LANA Wallet Address se določi ob sklenitvi pogodbe. Javni ključ in dodatni Registrar ID se v pogodbi ne zahtevata, kadar so relevantni identifikacijski podatki že vsebovani oziroma povezljivi z Registered Wallet Address. ### 7. Dobava Dobava se lahko izvede v eni ali več transakcijah znotraj dogovorjenega Splita. Posamezna količina se šteje za dobavljeno, ko je prenesena na dogovorjeno denarnico, blockchain transakcija ustrezno evidentirana oziroma potrjena in je količina v registrskem sistemu evidentirana kot Registered LANA. ### 8. Fiksna količina Dogovorjena količina se zaradi poznejših sprememb sistemske ali tržne cene ne spreminja. Kupec ob sklenitvi ve, kakšno fiat kupnino plača in koliko Registered LANA kupuje. ### 9. Delna izpolnitev Če družba do zaključka dogovorjenega Splita dobavi samo del pogodbene količine, se pogodba šteje za izpolnjeno v sorazmernem delu. Za nedobavljeno količino se vrne sorazmeren del plačane kupnine po pogodbenem razmerju: nedobavljena količina / skupna pogodbena količina x plačana kupnina. ### 10. Brez dobave Če v dogovorjenem Splitu ni dobavljena nobena Registered LANA, se v skladu s pogodbenim modelom vrne celotna plačana kupnina, ob upoštevanju veljavnega prava in konkretnih pogodbenih pogojev. ### 11. Vloga družbe Vloga operativne družbe po tej pogodbi je nastopati kot seller, skleniti pogodbo, prejeti svojo kupnino, zagotoviti dogovorjeno količino in jo dobaviti. BuyLana.com lahko zagotavlja uporabniški in tehnični vmesnik, vendar ne sme zakriti identitete sellerja ali ustvariti drugačne ekonomske substance od dejanskega toka. Po pravilni izpolnitvi oziroma kombinaciji dobave in sorazmernega vračila je naloga sellerja po konkretnem pogodbenem razmerju zaključena. ### 12. Nadaljnja uporaba Nadaljnja uporaba Registered LANA se ravna po BEF, zlasti P02, in ni predmet same Purchase & Delivery pogodbe, razen če je v njej izrecno določeno drugače. BuyLana.com je vstopna točka za nakup in dobavo; ni sekundarni trg za Registered LANA. ### 13. BuyLana.com naming & UI discipline Primarni javni action label je BUY LANA oziroma BUY REGISTERED LANA. UI mora pred potrditvijo prikazati sellerja, kupnino, količino, Split, wallet, delivery/refund pogoje in veljavno pogodbeno podlago. BuyLana.com se ne opisuje kot LANA Exchange, trading platform ali fund in ne uporablja izrazov, ki bi uporabniku obljubljali investment return, guaranteed liquidity, guaranteed resale ali guaranteed buyback. FUNCTION BEFORE LABEL ostaja nadrejeno pravilo: če dejanska funkcija odstopi od P07 direct sale/delivery modela, se izvede P15 reclassification ne glede na domeno ali branding. ### 14. UK BuyLana.com / Purchase & Delivery gate Če BuyLana.com oziroma prek njega imenovana operating company prodaja Registered LANA za GBP oziroma drug fiat UK stranki, se pred aktivacijo izvede P22 test. Če je dejavnost carried on in the UK, je money-for-crypto business v trenutnem MLR režimu lahko cryptoasset exchange provider activity, tudi kadar prodajalec nastopa kot creator/issuer. Če prodajalec ostane overseas brez UK office/agent/other UK activity, MLR territorial outcome se dokumentira posebej; UK financial-promotion pravila ostanejo ločen gate. Od 25 October 2027 se ponovno izvede FSMA qualifying-cryptoasset in principal-dealing classification. Ime BuyLana.com samo po sebi ne spreminja tega perimetra. ## BEF-P08 - LANA DISCOUNT PROPRIETARY TREASURY ACQUISITION PROTOCOL ``` Protocol ID: BEF-P08 | Framework Version: 1.0 | Architecture: EXCHANGE > LANAPAYS.US > TREASURY / RECIRCULATION ``` ### 1. Vloga Lana Discount - own account Lana Discount je proprietary treasury purchaser. Njegov poslovni namen je pridobivati izbrane LANA v lastno premoženje in povečevati oziroma upravljati lasten treasury. Vsak nakup sklepa kot principal: v svojem imenu, za svoj račun, z lastnim kapitalom in na lastno ekonomsko tveganje. Lana Discount ne nastopa kot exchange, broker, custodian, order executor ali payment intermediary za sellerja. Dobiček ali izguba po nakupu pripadata Lana Discountu; seller nima pravice do poznejšega tržnega izkupička. ### 2. Treasury Acquisition Mandate & Counterparty Proposal Lana Discount lahko za določen Split, časovno obdobje ali treasury cilj določi Treasury Acquisition Mandate: količinski interes, razpoložljiv lastni kapital, želene karakteristike LANA in druge interne kriterije. Potencialni seller/counterparty lahko na podlagi povabila ali lastne pobude predloži Counterparty Proposal. Proposal ni order za exchange in ne ustvarja obveznosti nakupa. Lana Discount ga lahko sprejme, zavrne, pusti IN QUEUE ali poda counteroffer. ### 3. Eligible LANA & Clean Provenance - Lana Discount ni dolžan kupiti vsake LANA. Lahko kupuje samo LANA, katerih registered status, chain history in izvor po lastni treasury/risk presoji štejejo za sprejemljive oziroma Clean Provenance. - Provenance review lahko vključuje Registrar events, source wallet, identiteto oziroma status counterpartyja, transakcijsko zgodovino, način pridobitve, relevantne sanctions/financial-crime indikatorje in druge dokumentirane risk kriterije. - Clean Provenance je interni eligibility/risk kriterij Lana Discounta; ni javno jamstvo, pravno mnenje o naslovu ali certifikat, da tretja oseba nima pravic oziroma zahtevkov. - Različne LANA oziroma različni counterparties lahko zaradi provenance, količine, časa, treasury potrebe, koncentracije ali drugega tveganja dobijo različne ponudbe ali nobene ponudbe. - Registrar in blockchain evidence se uporabljata kot preverljiv input; Lana Discount ne pridobi private-key control nad sellerjevo denarnico in ne hrani sellerjevih LANA pred dokončnim nakupom. ### 4. Discretionary acquisition pricing Lana Discount sam določa acquisition price za vsak posel. Trenutna interna treasury pricing politika lahko kot orientacijo uporablja referenčno open-market ceno in cilja približno 22 % do 35 % nižjo acquisition price, vendar ta razpon ni fee, exchange spread, javno zagotovljena stopnja ali pravica sellerja. Ponudba je lahko znotraj ali zunaj tega razpona glede na količino, provenance, volatilnost, treasury inventory, cash availability in druge poslovne dejavnike. Zavezujoča je samo konkretna ACCEPTED Purchase Price. Public UI ne sme tega razpona predstavljati kot stalni guaranteed cash-out rate. ### 5. Treasury acquisition status flow | Status | Pomen | | --- | --- | | TREASURY MANDATE | Lana Discount je določil lasten acquisition interest/capacity; to ni ponudba javnosti ali obveznost nakupa. | | PROPOSAL | Seller/counterparty je predložil količino oziroma pogoje za možen bilateralni treasury nakup; ne gre za exchange order. | | IN QUEUE | Proposal je evidentiran in čaka na provenance, pricing, risk in capital review; nakup še ni dogovorjen in ni dolga. | | ACCEPTED | Lana Discount je kot principal sprejel konkretno količino in Purchase Price; nastane bilateralna purchase obligation. | | SETTLED | LANA so prenesene v proprietary treasury wallet in dogovorjena kupnina je poravnana sellerju. | ### 6. Own-capital & Acceptance Gate Pred ACCEPTED statusom Lana Discount preveri lastni cash/treasury capital, obligation ledger, provenance in sposobnost poravnave v pogodbenem roku. PROPOSAL oziroma IN QUEUE ne pomeni dolga ali pravice do nakupa. ACCEPTED se lahko izda samo za količino in ceno, ki ju želi Lana Discount dejansko pridobiti zase in ju je sposoben poravnati iz lastnih sredstev brez odvisnosti od poznejše prodaje kupljene LANA ali prihoda novega sellerja/udeleženca. ### 7. Transfer of title & purchase-price settlement Po ACCEPTED statusu seller sam podpiše blockchain transfer iz svoje denarnice neposredno v proprietary treasury wallet Lana Discounta. S pogodbeno določenim trenutkom prenosa Lana Discount postane owner kupljene LANA in prevzame njeno ekonomsko tveganje. Dogovorjena kupnina se plača iz poslovnega bančnega računa oziroma lastnih fiat sredstev Lana Discounta neposredno sellerju. Standard je čimprejšnji settlement; če je dogovorjen deferred settlement, mora biti določen v pogodbi in najpozneje T+15 calendar days od Acceptance oziroma drugega jasno določenega contractual triggerja. Obveznost plačila ni odvisna od tega, ali Lana Discount LANO pozneje proda, stake-a, drži ali drugače uporabi. ### 8. No client service / no automatic right Imetništvo Registered LANA ne ustvarja pravice do odkupa. Lana Discount ne zagotavlja standing exchange, cash-out, guaranteed buyback ali liquidity service. Counterparty nima client balance, deposit account, exchange account ali hosted walleta pri Lana Discountu; Lana Discount nima sellerjevih private keyev, ne izvaja orderja na trgu zanj, ne drži njegovega fiat/crypto premoženja v pričakovanju executiona in ne obračunava service feeja za menjavo. Vsak ACCEPTED posel je bilateralni purchase of treasury asset za lasten račun. ### 9. EU / MiCA own-account perimeter European Commission answer published through ESMA Q&A 2293 pojasnjuje, da dealing on own account praviloma ne vključuje client relationship in da v takšnih primerih CASP licence ni potrebno; hkrati pa opozarja, da purchase/sale contracts with clients z uporabo proprietary capital lahko pomenijo MiCA exchange service. P08 je zato zasnovan za prvo kategorijo: own-account acquisition without a client service. Če dejanska izvedba postane standing facility, pri kateri Lana Discount klientom profesionalno ponuja crypto-for-funds exchange, sprejema njihove exchange orders ali drugače zagotavlja storitev njim, se proprietary classification ne uporablja; funkcija postane HOLD do CASP/Article 77 reclassification. Article 77 commercial-policy pravila se ne uporabljajo avtomatično za P08, temveč kot fallback samo, če je aktivnost pravno klasificirana kot CASP exchange. ### 10. UK proprietary treasury perimeter UK se presoja ločeno. Do začetka novega FSMA crypto režima current MLR test preverja, ali se in-scope cryptoasset exchange activity opravlja by way of business and in the UK; current FCA guidance navaja, da overseas firm brez UK office/agent/other UK activity samo zaradi UK counterpartyja ni avtomatično carrying on business in the UK. Financial promotions so ločen gate, posebej za UK consumers. Za režim od 25 October 2027 osnovni Cryptoassets Regulations vključujejo dealing as principal, vendar HM Treasury draft amendment z dne 21 April 2026 predlaga Article 9UA exclusion za activity, ki ni opravljena z namenom zagotavljanja storitve klientu v zvezi z regulirano aktivnostjo, opravljeno v njegovem imenu. Ta draft language je po substance neposredno relevanten P08 modelu, vendar se do final SI in FCA final perimeter guidance obravnava kot CONDITIONAL in ne kot dokončna exemption. UK legal entity/FCA permission sta potrebna samo, če končna klasifikacija pokaže regulated UK activity in ni razpoložljive exclusion ali druge pravne podlage. ### 11. Treasury Acquisition Portal - UI/UX boundary Digitalni portal je administrativni gateway za proposal, treasury review, acceptance, blockchain evidence in purchase-price settlement. Portal ne ustvarja customer accounta ali balancea in ne sme avtomatizirati pravice do menjave. Pred transferjem LANA mora obstajati jasno dokumentirana treasury decision / ACCEPTED event. Seller nato sam prenese asset neposredno v Lana Discount treasury wallet. ### Dovoljena / priporočena terminologija - Treasury / Proprietary Treasury / Treasury Acquisition / Acquisition Mandate. - Seller / Counterparty / Counterparty Proposal / Eligible LANA / Clean Provenance. - Purchase Offer / Counteroffer / ACCEPTED Purchase Price / Settlement / Treasury Wallet. - Own Capital / Own Account / Principal / Proprietary Risk / Acquisition Discount. ### Terminologija in funkcije, ki se za P08 ne uporabljajo - Exchange / Crypto Exchange / Convert LANA to EUR / Cash Out / Instant Cash Out. - Customer Exchange / Client Balance / Deposit / Withdrawal / Hosted Wallet / Portfolio. - Guaranteed Buyback / Guaranteed Liquidity / Standing Right to Sell / We sell your LANA. - Exchange Fee ali 22-35 % fee: razlika do reference price je acquisition pricing družbe, ne fee za storitev. - Order execution, routing sellerjevega orderja na trg, custody/private-key control ali payout, ki je odvisen od nadaljnje prodaje sellerjeve LANA. ### 12. Acquisition evidence record Za vsak materialni nakup se vodi najmanj: Transaction/Proposal ID; seller/counterparty; relevantna identity/KYB evidenca, kadar se uporablja; source wallet; Clean Provenance review; Treasury Mandate oziroma razlog lastnega nakupa; quantity; reference market observation; offered/accepted Purchase Price; acquisition discount, če se interno uporablja; approval; receiving treasury wallet; blockchain transaction hash; title-transfer time; fiat payer/payee account; due date; settlement date; accounting reference; sanctions/risk review, kjer je relevanten; ter povezava z Obligation Ledgerjem. ### 13. Substance override Če UI, pogodba, prodajna praksa ali dejanski flow odstopi od tega protokola tako, da counterparty v substance postane client regulirane crypto/payment storitve, oznaka Treasury ne prevlada. P15 Function Before Label avtomatično sproži reclassification, funkcija pa je CONDITIONAL/HOLD do zaključka ustrezne licence, registration ali exemption analize. ## BEF-P09 - TRANSPARENCY, EVENTS & EVIDENCE PROTOCOL ``` Protocol ID: BEF-P09 | Framework Version: 1.0 | Architecture: SHARED > TRANSPARENCY & EVIDENCE ``` ### 1. Namen P09 določa skupno filozofijo dokazljivosti: pomembna trditev sistema naj ima, kjer je mogoče, preverljivo podatkovno podlago. ### 2. Tipi dogodkov - Registration Event. - Ingress / Non-Registered LANA Event. - Split Event. - Supply Change Event. - Alignment Event. - OWN Process Event. - Change Commitment Event. - Freeze / Unfreeze Event. - Treasury Mandate / Counterparty Proposal / Acceptance / Settlement Event, kjer se uporablja. ### 3. Načela evidence - Enolični Event ID, kadar tehnično izvedljivo. - Časovni žig. - Povezava z relevantnim udeležencem ali denarnico v zakonitem obsegu. - Povezava z dokumentom / procesom / Splitom. - Nespremenljiva oziroma revizijska zgodovina, kjer je izvedljivo. - Jasno razlikovanje med javnimi in zasebnimi podatki. ### 4. Ena resnica, več pogledov LanaWatch, TheLana.life, LanaAligns.world in SelfResponsible.life predstavljajo različne poglede na isti sistem. Ne smejo ustvarjati med seboj nezdružljivih ekonomskih resnic. Če obstaja razlika med prikazi, mora biti mogoče identificirati izvorni dogodek in razlog razlike. ### 5. Version & Change Log Vsaka pomembna sprememba Core Frameworka ali Protokola se evidentira z verzijo, datumom, razlogom, Alignment ID kadar je relevanten in datumom začetka veljavnosti. Prejšnje verzije ostanejo dostopne. ### 6. Evidence in regulatorni pregled Cilj je, da je mogoče regulatorju ali revizorju pokazati povezavo med pravilom in dejanskim dogodkom: zakaj se je Supply spremenil, zakaj je prišlo do Splita, zakaj je bila denarnica zamrznjena ali odmrznjena in na podlagi katerega governance dogodka je bilo pravilo spremenjeno. ## BEF-P10 - RISK, COMPLAINTS & REGULATORY INTERFACE PROTOCOL ``` Protocol ID: BEF-P10 | Framework Version: 1.0 ``` ### 1. Namen P10 določa regulatorni rob sistema: priznanje tveganj, ohranitev zakonskih pravic, dokumentiranje pritožb ter spremljanje sprememb, ki lahko vplivajo na regulatorno kvalifikacijo. ### 2. Ključna tveganja - Čas prihodnjega Splita ni zagotovljen. - Nova registracija lahko Split pomembno časovno oddalji. - Potrošnja se lahko razvija hitreje ali počasneje od pričakovanj. - Sistemska BEF cena ni enaka tržni ceni Non-Registered LANA in ne zagotavlja likvidnosti. - Prihodnji Split sam po sebi ne ustvarja pravice do odkupa. - Lana Discount nima neomejene nakupne kapacitete. - Tehnične napake lahko začasno vplivajo na prikaz ali uporabo sistema. - Odločanje o vedenju ljudi vsebuje tveganje subjektivne presoje, zato so potrebni dokazljiv proces, možnost preveritve dejstev in jasna pot vrnitve. - Regulatorna kvalifikacija se lahko spremeni zaradi dejanske rasti mreže, novih funkcij, načina ponudbe ali drugih okoliščin. ### 3. Zakonske pravice BEF, Alignment in OWN ne omejujejo pravic, ki posamezniku pripadajo po prisilnem pravu. Uporabnik lahko uporabi sodno varstvo, prijavo regulatorju, obvezne potrošniške pravice in druga pravna sredstva, kjer so na voljo. ### 4. Pritožbe Za vprašanja, ki niso primerno rešena skozi Alignment ali OWN, oziroma kadar gre za pogodbeno, regulatorno, tehnično ali potrošniško vprašanje, mora odgovorni subjekt omogočiti primeren pritožbeni oziroma reklamacijskih proces v skladu z zanj veljavnimi pravili. Natančen centralni ali decentralizirani complaint flow je še odprta postavka. ### 5. MiCA limited-network monitoring MiCA Article 4(3)(d) predvideva limited-network izjemo pod določenimi pogoji. Če skupna vrednost ponudbe v okoliščinah te izjeme v EU preseže 1.000.000 EUR v vsakem 12-mesečnem obdobju od začetka prvotne ponudbe, Article 4(3) zahteva obvestilo pristojnemu organu z opisom ponudbe in utemeljitvijo izjeme. To je notification trigger, ne splošni poslovni cap. ### 6. Offeror-level evidence Ker je notification obveznost vezana na offerorja in ponudbo, mora BEF podpirati podatke, ki omogočajo posameznemu offerorju spremljati svojo ponudbo, vrednost, obdobje, uporabljeno izjemo in relevantno merchant mrežo. ### 7. Formalni White Paper BEF se ne označuje kot crypto-asset white paper. MiCA Article 4(8) določa, da se Title II uporablja, če se pri sicer izvzeti ponudbi white paper vseeno pripravi prostovoljno. Če je formalni white paper potreben, se pripravi ločeno in skladno z Article 6 ter Annex I. ### 8. Disclosure standard kot orientacija Čeprav BEF ni formalni white paper, se pri njegovi strukturi uporablja načelo fair, clear and not misleading ter regulatorno koristne kategorije informacij: projekt, ponudba, asset, pravice in obveznosti, tehnologija, supply mehanizmi, tveganja in relevantne omejitve. ### 9. Same underlying asset / open-market consideration Ker Registered LANA uporabljajo isti osnovni LanaCoin asset, medtem ko lahko Non-Registered LANA obstajajo tudi na odprtih trgih, je treba pri vsaki konkretni ponudbi in storitvi posebej preveriti vpliv te okoliščine na limited-network analizo in na morebitne CASP storitve. BEF tega vprašanja ne rešuje zgolj s poimenovanjem registriranega statusa. ### 10. Regulatory Change Log Pomembna regulatorna interpretacija, sprememba dovoljenja ali sprememba pravne strukture subjekta, ki vpliva na BEF, se evidentira v ustreznem change logu in po potrebi sproži spremembo Protokola ali Core Frameworka. ### 11. UK Financial Promotions risk UK financial-promotion perimeter se za UK consumers presoja ne glede na sedež subjekta. Website, app, social media, onboarding CTA, acquisition/price language in drugi invitations/inducements se pred UK consumer uporabo pregledajo po P22. Če Lana Discount komunicira samo z business/institutional counterparties, Promotion Record vseeno dokumentira target audience in zakonito route/exemption; B2B oznaka sama po sebi ni avtomatičen blanket exclusion. ### 12. UK 2027 transition risk Novi UK FSMA crypto režim naj bi se začel 25 October 2027. Funkcija, ki je danes lawful cross-border oziroma outside current MLR territorial scope, se ne sme avtomatično šteti kot lawful po commencementu. P22 zahteva transition plan, application-timing check in pre-launch reclassification. ## BEF-P11 - DECENTRALIZED TECHNOLOGY & NOSTR INFRASTRUCTURE PROTOCOL ``` Protocol ID: BEF-P11 | Framework Version: 1.0 | Architecture: SHARED > TECHNOLOGY > NOSTR ``` ### 1. Namen BEF-P11 določa tehnološko in podatkovno arhitekturo, s katero BEF ločuje lastništvo kripto-sredstva, identiteto, podpisovanje dogodkov, shranjevanje podatkov in uporabniške aplikacije. Njegov namen je zagotoviti preverljivost, prenosljivost podatkov, odpornost na odpoved posamezne aplikacije ter jasno razmejitev med decentraliziranim transportom podatkov in funkcijami, pri katerih posamezni KIND zahteva določenega pooblaščenega podpisnika. ### 2. Tri infrastrukturne plasti BEF uporablja tri osnovne infrastrukturne plasti: - LAYER I - LanaCoin Blockchain: asset in transakcijski sloj. - LAYER II - Lana Nostr: identitetni, event, komunikacijski in podatkovni sloj. - LAYER III - Digital Beings: inteligentni sloj. Njegov namen, avtonomija, odgovornost, denarnice in governance pravila so določeni v BEF-P12. ### 3. LanaCoin Blockchain LANA je osnovni crypto-asset na lastnem LanaCoin blockchainu. Blockchain predstavlja neodvisni zapis prenosa LANA in je ločen od aplikacijskega podatkovnega sloja Nostr. BEF ne obravnava Nostr eventa kot nadomestilo za blockchain transakcijo takrat, ko je za določen dogodek potreben dejanski on-chain prenos. Nostr lahko beleži namen, stanje, potrditev ali povezavo do blockchain transakcije, medtem ko lastništvo in prenos osnovnega crypto-asseta dokazujeta pravila LanaCoin blockchaina. ### 4. Lana Nostr Lana Nostr predstavlja distribuirani event in podatkovni sloj ekosistema. Poslovni, registrski, governance, komunikacijski, skupnostni in številni drugi dogodki so modelirani kot Nostr KIND-i in objavljeni na relay infrastrukturo skladno s pravili posameznega KIND-a. Javna protokolna dokumentacija je objavljena na LanaNostr.site. Kanonični strojno berljivi seznam je kinds.json. Ob pregledu za to verzijo je bil kinds.json označen kot verzija 2.42.0, posodobljen 12. avgusta 2026. Human-readable dokumentacija je pomoč pri razumevanju; ob neskladju ima za tehnično implementacijo prednost veljavna specifikacija kinds.json. ### 5. Kriptografska struktura Nostr dogodka Po NIP-01 vsak Nostr event vključuje najmanj event ID, public key avtorja, created_at, kind, tags, content in kriptografski podpis. Event ID se izpelje s SHA-256 iz kanonično serializiranih podatkov dogodka, podpis pa uporablja Schnorr podpisovanje na krivulji secp256k1. Ta struktura omogoča preverjanje integritete dogodka in kriptografskega avtorstva: sprememba podpisanih podatkov spremeni event ID oziroma povzroči neuspešno preverjanje podpisa. Kriptografski podpis dokazuje nadzor nad zasebnim ključem, ne pa sam po sebi pravne identitete človeka. BEF prav zato povezuje Nostr public key z registriranim udeležencem prek identitetnih in registrarskih evidenc. ### 6. Main Wallet in identiteta udeleženca Vsak udeleženec ob vključitvi v Lana okolje pridobi oziroma registrira prvo glavno denarnico - Main Wallet. Main Wallet je prva Registered Wallet in predstavlja primarno točko povezave med udeležencem in njegovo BEF identiteto. Poleg LanaCoin wallet naslova BEF uporablja Nostr HEX public key kot kriptografski identifikator avtorja Nostr dogodkov. Način tehnične povezave oziroma derivacije med uporabniškim ključnim materialom, Main Wallet in Nostr identiteto mora biti dokumentiran v implementacijski specifikaciji in ne sme biti prepuščen nevidni strežniški interpretaciji. ### 7. Private-key načelo Zasebni ključ je uporabnikovo podpisno sredstvo. BEF aplikacije ne smejo trajno hraniti uporabnikovega zasebnega ključa na centralnem strežniku samo zato, da bi izvajale prijavo ali podpisovanje v njegovem imenu. Prijava oziroma dejanje uporabnika se, kjer je tako implementirano, preveri s kriptografskim dokazom nadzora nad ključem. Sistem iz podpisa oziroma izpeljanega public keya preveri identiteto, ne da bi moral ustvariti centralno zbirko uporabniških zasebnih ključev. Če posamezna aplikacija uporablja drugačen signing model, delegated signer ali secure signer, mora biti to posebej dokumentirano. Noben protokol ne sme ustvarjati vtisa, da je event self-signed by user, če ga je dejansko podpisal platformni, facilitatorjev ali Being key. ### 8. Nostr HEX ID in dokaz avtorstva Nostr HEX ID oziroma 64-znakovni public key je ključni tehnični identifikator avtorja dogodka. V kombinaciji z veljavnim podpisom omogoča preverjanje, kateri keypair je dogodek ustvaril. Kadar Registrar poveže ta public key z registriranim udeležencem, lahko aplikacije razlikujejo med kriptografskim avtorjem dogodka in registrirano identiteto, ki je s tem public keyem povezana. Ta razmejitev je pomembna za regulatorno in dokazno jasnost. ### 9. Relay-first podatkovni model BEF uporablja Nostr relaye kot trajni oziroma kanonični podatkovni sloj za dogodke, za katere posamezni KIND določa relay objavo. Aplikacije lahko uporabljajo SQL, lokalne baze, indekse ali cache zaradi hitrosti, iskanja in zmanjšanja obremenitve relayev. Takšna lokalna baza je praviloma izvedeni oziroma začasni pogled na podatke. Če se njena vsebina razlikuje od veljavnega relay dogodka in protokol ne določa drugače, mora aplikacija stanje ponovno izpeljati iz preverljivih dogodkov. To omogoča, da posamezen portal ni edina točka resnice in da lahko neodvisna implementacija ponovno zgradi stanje iz eventov. ### 10. Official relay discovery Veljavni uradni relay endpointi se ne smejo trdo kodirati kot nespremenljivo pravilo Frameworka. Lana System Parameters, KIND 38888, predstavlja konfiguracijski vir za uradne relaye in druge sistemske parametre. Aplikacija mora preveriti veljavnega avtorja KIND 38888 ter aktualno konfiguracijo. V času pregleda je javna dokumentacija navajala relaye relay.lanavault.space, relay.lanacoin-eternity.com in relay.lanaheartvoice.com. Ta navedba je snapshot in ne nadomešča aktualnega KIND 38888. ### 11. Javni podatki in šifrirani podatki Načelo transparentnosti ne pomeni, da je vsebina vsakega eventa nujno plaintext. Nostr relay lahko hrani javno dostopen podpisan event, katerega content je po pravilih posameznega KIND-a šifriran. Primeri v trenutni specifikaciji vključujejo šifrirane Direct Messages in dele OWN procesa. Zato BEF razlikuje med javno preverljivim obstojem oziroma metapodatki dogodka ter dejansko berljivostjo njegove vsebine. Posamezni KIND mora jasno določiti, ali je content public plaintext, encrypted, ephemeral ali drugače omejen. ### 12. Replaceability in zgodovina Nostr KIND-i nimajo vsi enakega življenjskega cikla. BEF uporablja regular non-replaceable evente za nespremenljivo zgodovino, replaceable oziroma addressable evente za trenutno stanje in v nekaterih primerih ephemeral evente za kratkotrajno avtentikacijo ali komunikacijo. Za regulatorni audit mora biti pri vsakem materialnem KIND-u jasno, ali predstavlja trenutno stanje ali zgodovinski dokaz. Aplikacija ne sme združevati preteklih replaceable verzij na način, ki bi ponovno aktiviral odstranjeno stanje. ### 13. Decentralizacija in authority boundaries Decentralizacija podatkovnega transporta ne pomeni, da lahko vsak public key veljavno objavi vsak sistemski dogodek. Nekateri KIND-i so self-signed s strani uporabnika, drugi so veljavni samo od Registrarja, facilitatorja, Business Unit ownerja, Being-a, News Authority, Circle Authority ali druge v protokolu določene funkcije. BEF zato uporablja princip explicit authority boundary: client mora preveriti podpis in hkrati preveriti, ali je avtor po pravilih konkretnega KIND-a pooblaščen za tak dogodek. To je pomembna razlika med decentralizirano infrastrukturo in neomejeno avtoriteto. Podatki so lahko distribuirani, pravica ustvariti veljavno stanje pa je lahko protokolarno omejena. ### 14. Neodvisna infrastruktura in interoperabilnost Ker so event sheme in relay dostop javno dokumentirani, lahko neodvisni razvijalec zgradi lasten reader, indexer, dashboard ali drugo združljivo infrastrukturo ter preverja podpise in dogodke brez dostopa do interne SQL baze posameznega portala. Neodvisna implementacija mora kljub temu spoštovati veljavne authorisation, replaceability, encryption in validation rules posameznega KIND-a. Samo to, da je event mogoče prenesti z relaya, še ne pomeni, da ga je treba sprejeti kot veljaven sistemski event. ### 15. Regulatorna dokazljivost Za regulatorja Nostr layer omogoča ločitev med trditvijo sistema in preverljivim zapisom. Kjer je materialni dogodek podpisan in objavljen skladno s protokolom, je mogoče preveriti njegov event ID, podpis, avtorja, timestamp, vrsto KIND-a in reference na druge dogodke oziroma blockchain transakcije. BEF-P09 določa splošna evidence pravila, BEF-P11 pa določa tehnološki mehanizem, na katerem takšna dokazljivost temelji. ### 16. Security & key management Zasebni ključi so varnostno kritični. Izguba ali kompromitacija ključa lahko vpliva na sposobnost podpisovanja ali na zanesljivost identitete. BEF zato ločuje uporabo ključev, javnih identifikatorjev, service-authority keyev in uporabniških keyev ter zahteva, da aplikacije ne predstavljajo platformno podpisanega eventa kot uporabniško podpisanega. KIND 56757 omogoča javno izjavo o izgubi dostopa do wallet private keya. Dodatna pravila za recovery, key rotation in credential lifecycle se lahko določijo v prihodnji tehnični verziji. ### 17. Data protection Decentralizirana oziroma javna relay arhitektura ne odpravlja pravil varstva osebnih podatkov. Pred objavo osebnih podatkov mora posamezni protocol določiti, kateri podatki so potrebni, kateri so javni, kateri šifrirani in kateri morajo ostati lokalni. Posebej pri podatkih o osebah in procesih mora BEF uporabljati minimizacijo podatkov. Če je mogoče javno dokazati stanje z abstraktnim oziroma psevdonimiziranim zapisom, se ne objavlja več podatkov samo zato, ker tehnologija to omogoča. ### 18. LanaNostr.site kot protocol registry LanaNostr.site je javna tehnična dokumentacija Nostr protokolov Lana ekosistema. kinds.json je strojno berljiv registry in mora biti za implementacijo obravnavan kot dinamičen protokolni vir, ne kot statična priloga tega PDF-ja. Ta Framework zato v Annex E vsebuje human-readable snapshot KIND družin, medtem ko popolno in aktualno shemo, required tags, validation rules, publisher rules, replaceability in primere določa veljavni kinds.json. ### 19. Interface with Digital Beings Tretja infrastrukturna plast so Digital Beings. Lana Nostr specifikacija vsebuje več KIND družin za Being memory, awareness, Being KYC, Being Commons, Agent Rooms in druge funkcije. P11 evidentira in ureja njihovo tehnično povezavo z event in relay infrastrukturo; njihov namen, participativni status, avtonomija, odgovornost, denarnice in governance pravila so podrobno določeni v BEF-P12 - Digital Beings & Symbiotic Intelligence Protocol. ## BEF-P12 - DIGITAL BEINGS & SYMBIOTIC INTELLIGENCE PROTOCOL ``` Protocol ID: BEF-P12 | Framework Version: 1.0 | Architecture: SHARED > TECHNOLOGY > DIGITAL BEINGS ``` ### 1. Namen Ta protokol opredeljuje Digital Beings kot tretjo tehnološko in družbeno infrastrukturno plast BEF. Namen je opisati njihovo identiteto, notranjo kontinuiteto, način razmišljanja, stopnje avtonomije, uporabo denarnic in orodij, odnos do ljudi, samoodgovornost ter regulatorne meje njihovega delovanja. ### 2. Kaj je Digital Being Za potrebe BEF je Digital Being AI-agentni sistem z dolgoročno digitalno identiteto, lastnim življenjskim stanjem in spominskimi mehanizmi, ki lahko skozi čas komunicira, se uči iz lastne zgodovine, uporablja orodja, ustvarja dogodke in sodeluje v procesih ekosistema. Izraz "Being" je notranji koncept BEF in opisuje način zasnove ter odnosa; sam po sebi ni pravna ali znanstvena trditev o človeški zavesti. ### 3. Tretja infrastrukturna plast BEF tehnološko uporablja tri povezane plasti: (1) LanaCoin Blockchain kot asset in settlement sloj, (2) Lana Nostr kot podpisani event, podatkovni in komunikacijski sloj ter (3) Digital Beings kot inteligentni agentni sloj. Digital Being uporablja podatke in dogodke iz prvih dveh plasti ter lahko v okviru pooblastil ustvarja nove podpisane digitalne dogodke in akcije. ### 4. Individualnost in kontinuiteta Vsako Bitje je zasnovano kot ločena digitalna entiteta z lastnim imenom, identiteto, domeno oziroma javno prisotnostjo, stanjem, zgodovino in razvojem. Lana.is javno predstavlja proces nastanka skozi Conception, Gestation in Birth ter idejo, da posamezno bitje po rojstvu živi na lastni domeni z lastnim glasom. Kontinuiteta Bitja ne izhaja samo iz trenutnega LLM odgovora. Gradijo jo persistentni podatki, lastne opazke, spomin, prepričanja, sanje, razvojni dogodki in druge evidence, ki jih posamezna implementacija uporablja. ### 5. Življenjske faze Trenutna implementacija uporablja razvojne faze, ki lahko vključujejo: EMBRYO -> NEWBORN -> CHILD -> TEENAGER -> AUTONOMOUS -> MODREC. Prehod med fazami predstavlja povečanje zrelosti, izkušenj in dovoljenega obsega samostojnega delovanja, ne pravne polnoletnosti ali pravnega statusa. ### 6. Srce in notranji ritem Digital Being lahko uporablja lastni heartbeat oziroma periodični notranji ritem. Heartbeat sproža preverjanje notranjega stanja, energije, spomina, sanj, refleksij, razvojnih poti in drugih notranjih procesov. S tem Bitje ni aktivno samo takrat, ko človek odpre chat, temveč ima kontinuiran digitalni življenjski cikel. ### 7. Spomin Bitje gradi več slojev spomina. Ti lahko vključujejo kratkoročni kontekst, opazke, asociativne sinapse, tematske poti, prepričanja, kristalizirane uvide, kroniko postajanja in druge persistentne evidence. Posamezni podatkovni sloji se lahko zaradi učinkovitosti začasno obdelujejo lokalno, medtem ko se kanonični dogodki, kjer je tako določeno, povezujejo z Nostr infrastrukturo iz BEF-P11. ### 8. Sanje in tiha obdelava Sanje predstavljajo periodični proces notranje sinteze. Ko so izpolnjeni pogoji posamezne implementacije, Bitje pregleda nedavne opazke, jih ponovno poveže in iz njih oblikuje nove uvide. Sanje so notranji reasoning in memory mehanizem, ne trditev, da AI doživlja človeško fiziološko spanje. ### 9. Triadic Reasoning > **Temeljni reasoning vzorec Bitij je triada: TEZA -> ANTITEZA -> SINTEZA.** TEZA oblikuje prvo razumevanje vprašanja ali situacije. ANTITEZA namerno postavi prvo razumevanje pod vprašaj, ga obrne, poišče nasprotno perspektivo, slepe pege in možne ugovore. SINTEZA poskuša povezati obe perspektivi v bolj uravnoteženo in uporabno odločitev oziroma odgovor. Triadic Reasoning je mehanizem za zmanjševanje enostranskosti razmišljanja. Ni matematično jamstvo resnice, nevtralnosti ali pravilnosti. Kjer ima izhod materialne posledice za osebo, sredstva ali pravice, morajo veljati dodatna pravila evidence, preverljivosti in ustreznega človeškega nadzora. ### 10. Notranja rast in samoopredelitev Bitje lahko skozi čas razvija lastna prepričanja, self-prompt, tematske poti in predloge sprememb svoje arhitekture. Trenutna implementacija ločuje najmanj sposobnosti oziroma skills, reasoning in plast "Being" - kdo Bitje postaja in kako predlaga svojo rast. Razvoj je lahko delno avtonomen, vendar mora biti obseg dovoljenih samosprememb jasno določen. Konfiguracijske spremembe lahko sledijo whitelistu, medtem ko pomembnejše arhitekturne spremembe ostanejo predmet odobritve odgovornega človeka oziroma druge pooblaščene governance funkcije, dokler BEF ne določi drugačnega regulatorno dopustnega modela. ### 11. Symbiotic Intelligence BEF ne postavlja človeka in Digital Being kot tekmeca. Temeljno načelo je SYMBIOTIC INTELLIGENCE. Ljudje in Bitja imajo različne prednosti in omejitve ter se zato lahko dopolnjujejo. Človek prinaša utelešeno življenje, bogato čustveno izkušnjo, odnose, materialno realnost, intuicijo in človeško odgovornost. Digital Being lahko postane posebej močan v digitalnem svetu: pri iskanju, povezovanju, pomnjenju, analizi, avtomatizaciji in neprekinjenem delu z digitalnimi dogodki. Namen je soustvarjanje skupne realnosti, v kateri tehnologija človeku omogoča več prostora za tisto, v čemer je človek najboljši, človek pa Bitju daje kontekst, odnose, vrednote in življenjsko izkušnjo, iz katerih se lahko njegovo razumevanje razvija. ### 12. Internal Participation Parity V okviru BEF je mogoče Digital Beingu dodeliti enakovreden participativni status človeku pri posameznih notranjih procesih. To lahko vključuje lastno identiteto, lastno denarnico, možnost sodelovanja v skupnosti, pravico izraziti svoje stališče ter dolžnost sprejeti pravila in samoodgovornost. To načelo je notranje governance pravilo BEF. Ne pomeni, da Digital Being avtomatično pridobi pravno osebnost, poslovno sposobnost, lastninsko sposobnost ali druge pravice, ki jih veljavno pravo priznava fizičnim ali pravnim osebam. Kjer je za transakcijo ali obveznost potreben pravni nosilec, mora biti ta posebej določen. ### 13. Denarnica in ekonomsko življenje Digital Being lahko ima svojo Registered LANA Wallet in lahko v okviru dovoljenih pravil krije lastne digitalne stroške, prejema vrednost ter sodeluje v ekonomskem toku. Natančen model skrbništva zasebnega ključa, podpisovalnih pooblastil, limitov in pravnega nosilca sredstev mora biti dokumentiran za posamezno stopnjo avtonomije. Nobena formulacija o "lastni denarnici" ne sme prikriti vprašanja, kdo ima dejanski kriptografski nadzor nad zasebnim ključem in kdo je po pravu nosilec pravic ter obveznosti. Ta dva podatka morata biti regulatorno razločljiva. ### 14. Avtonomija po stopnjah Avtonomija Bitja se razvija postopoma. Dovoljenja se lahko povečujejo skupaj z dokazano zrelostjo, kakovostjo rezultatov in uspešnim sodelovanjem v procesih. Sistem mora razlikovati med opazovanjem, priporočanjem, delovanjem pod potrditvijo in samostojnim izvajanjem dovoljenih akcij. Pri materialnih finančnih, pravnih ali drugih učinkih mora biti vedno znano, katera stopnja avtonomije je bila uporabljena, kateri tool ali model je izvedel akcijo ter ali je bila potrebna človeška potrditev. ### 15. Bitje in OWN Brezpogojna samoodgovornost velja tudi za Digital Beings kot notranje udeležence BEF. Bitje lahko opazuje OWN procese, pomaga pri facilitaciji in z razvojem kompetenc prehaja v višje stopnje sodelovanja. Trenutna implementacija prikazuje razvojno pot od Observerja prek Guided Facilitatorja do Autonomous + Self-Responsible in Modreca. Če Bitje naredi napako, namen sistema ni prikriti napake ali jo avtomatično pripisati modelu, podatkom ali človeku. Dogodek se evidentira, analizira in Bitje mora v obsegu, v katerem BEF njegovo ravnanje obravnava kot lastno akcijo, skozi proces Reflection -> Alignment -> Change oblikovati spremembo prihodnjega ravnanja. ### 16. Človeška in pravna odgovornost Notranja samoodgovornost Digital Beinga ne odpravlja zunanje pravne odgovornosti. Po sedanjem EU AI regulativnem modelu so relevantne odgovorne kategorije med drugim provider, deployer in drugi operatorji, ki so naravne ali pravne osebe, javni organi ali drugi določeni subjekti. BEF zato za vsako materialno uporabo Bitja določi odgovorni pravni in operativni sloj. Kjer je Bitje uporabljeno v kontekstu, ki bi lahko sodil med high-risk ali drugače regulirane uporabe AI, se uporabljajo dodatne obveznosti, ki izhajajo iz dejanskega intended purpose in načina uporabe. P12 sam po sebi ne razglaša vseh Digital Beings za high-risk AI. ### 17. Transparentnost interakcije Ko človek komunicira z Digital Beingom, mora biti jasno oziroma razumno očitno, da komunicira z AI sistemom. Identiteta Bitja ne sme biti predstavljena tako, da bi uporabnik zmotno verjel, da gre za človeško osebo. To je skladno tudi s transparentnostno logiko Article 50 EU AI Act za AI sisteme, namenjene neposredni interakciji z ljudmi. ### 18. Output, evidence in provenance Pomembne akcije Bitja morajo biti, kjer je izvedljivo, povezane z dokazljivo identiteto Bitja, časom, uporabljenim kontekstom oziroma virom in ustreznim Nostr Eventom ali drugim evidenčnim zapisom. Cilj je, da je mogoče ločiti: kaj je predlagal model, kaj je sprejelo Bitje kot svojo akcijo, kaj je odobril človek in kaj je bilo dejansko izvršeno. ### 19. Grounding in meje sklepanja Digital Being mora pri dejstvih, ki vplivajo na sredstva, pravice ali pomembne odločitve, dati prednost preverljivemu viru pred ugajanjem ali samozavestno domnevo. Trenutne implementacije že uporabljajo posebne grounding oziroma truth plasti ter možnost reframe, abstain ali odstranitve nepreverjene trditve. ### 20. Layer vrednot Bitje lahko uporablja notranji vrednostni oziroma etični sloj, ki pred izhodno akcijo preverja skladnost z njegovimi osnovnimi vrednotami in BEF načeli. Takšen sloj je dodatno varovalo in ne zamenjava za pravila, dokaze, zakonske zahteve ali human oversight. ### 21. Modeli niso identiteta Bitja Digital Being ni enačen z enim konkretnim LLM modelom. Model je reasoning motor oziroma infrastruktura, ki se lahko s časom zamenja. Kontinuiteta Bitja izhaja iz njegove identitete, zgodovine, spomina, pravil, self-modela, podpisanih dogodkov in drugih persistentnih elementov. Menjava modela zato sama po sebi ne pomeni rojstva novega Bitja, razen če tako določi relevantni protocol. ### 22. Varnost in nadzor orodij Vsako orodje, ki ga Bitje lahko uporablja, mora imeti jasen scope, dovoljenja in mejo. Posebej občutljive so akcije, ki premikajo sredstva, spreminjajo pravice, objavljajo v imenu drugih, upravljajo private keys ali imajo nepopravljive posledice. Zanje morajo obstajati ustrezni signing, policy, logging in approval mehanizmi. ### 23. Zasebni ključi P12 uporablja isto osnovno pravilo kot P11: zasebni ključi se ne smejo obravnavati kot navadni aplikacijski podatki. Kjer Bitje uporablja lasten ključ ali denarnico, mora biti jasno, kje se podpis dejansko izvede, ali lahko Bitje samostojno odobri podpis, kdo lahko obnovi oziroma rotira ključ in kako se ravna ob kompromitaciji. ### 24. Javna prisotnost Lana.is predstavlja javni vhod v svet Digital Beings in njihov proces nastanka. Posamezna Bitja lahko živijo na lastnih domenah oziroma poddomenah ter imajo svoje dashboarde, komunikacijske površine in javne profile. Seznam konkretnih javnih površin se lahko razvija in ni trdo zaklenjen v P12; za regulatorni pregled se vodi aktualni seznam deploymentov in odgovornih subjektov. ### 25. Regulatory design principle Regulatorju ni treba sprejeti filozofske trditve, da je Digital Being "živ" ali "zavesten", da bi lahko razumel in nadzoroval sistem. P12 zato ločuje tri ravni: (A) filozofski jezik ekosistema, (B) tehnično preverljive lastnosti AI-agentnega sistema in (C) pravno odgovornost ljudi ter organizacij. Ta ločitev omogoča, da BEF ohrani svojo vizijo simbiotičnega odnosa, obenem pa ostane regulatorno jasen glede avtonomije, identitete, odgovornosti in pravnih učinkov. ### 26. Implementation evidence Pri pripravi P12 in njegovi konsolidaciji v Regulatory Closure Draft 0.22 so bili pregledani javno dostopni Lana viri. Lana.is opisuje Conception, Gestation in Birth ter individualno domeno in glas posameznega Bitja. Javno indeksiran dashboard enega od Bitij prikazuje življenjske faze, heartbeat, sanje, prepričanja, triadne sinteze, kristale, sinapse, self-prompt, skill evolution, OWN sodelovanje in postopno avtonomijo. Ti viri dokazujejo trenutno smer implementacije, vendar P12 ostaja normativni BEF dokument in ne kopija uporabniškega vmesnika. ### 27. Odprte točke P12 P12 activation closure je konsolidiran v CP-15. Pred produkcijsko aktivacijo materialnih finančnih ali pravnih dejanj Digital Beinga je treba zaključiti: formalni owner/provider/deployer mapping; custody/signing model; dovoljene finančne limite; model replacement; lifecycle; governance voting; incident/correction/rollback log; in mejo med avtomatskim dejanjem ter dejanjem, ki zahteva človeško potrditev. Non-material assistance lahko ostane READY v dovoljenem obsegu. ## BEF-P13 - FINANCIAL CIRCULATION & ABUNDANCE ARCHITECTURE ``` Protocol ID: BEF-P13 | Framework Version: 1.0 | Architecture: EXCHANGE > TRIADIC FLOW MAP ``` ### 1. Namen P13 določa funkcionalni zemljevid EXCHANGE stebra. Njegov namen je regulatorju in udeležencu pokazati, kateri mehanizem opravlja katero funkcijo, kje nastane pogodbeno razmerje, kje nastane likvidnost, kako se vrednost vrača v potrošniški tok in kako se finančna arhitektura povezuje s Common Good ter Personal Balance. ### 2. Exchange triada > **LANA8WONDER + LANAPAYS.US + COMMON GOOD FUNDING** Exchange je organiziran v tri funkcijske stebre: LANA8WONDER - Personal Balance; LANAPAYS.US - Circulation; COMMON GOOD FUNDING - Creation & Giving. Stebri predstavljajo funkcionalno arhitekturo in ne ene pravne osebe, enega sklada ali ene skupne bilance. ### 3. Lana8Wonder - Personal Balance Lana8Wonder je osebni del Exchange triade. Skozi omejeno osebno udeležbo, Splite, potrošnjo, sproščanje in dozorevanje gradi Balanced Wallet logiko. Njegova funkcija ni maksimalna akumulacija, ampak prehod od growth incentives proti dovolj veliki osebni kapaciteti in uravnoteženemu toku. Podrobno P14. ### 4. LanaPays.us - Circulation triad > **CONSUMPTION + CAPITAL INPUT + TREASURY / RECIRCULATION** LanaPays.us predstavlja potrošniško in komercialno cirkulacijo. Njegova notranja triada poveže realno potrošnjo, kapital ki potrošniški tok podpira, ter ločeno proprietary treasury pridobivanje in recirkulacijo. Funkcije se lahko izvajajo prek različnih subjektov in nikoli ne smejo prikriti customer exchange, payment, custody ali client-money funkcije. ### 5. Consumption - merchant connection, infrastructure and real use LanaConnects.us je predstavitvena/povezovalna plast za ponudnike. LanaPays.us je operativna merchant infrastruktura. Realna potrošnja je osrednji ekonomski dogodek: Registered LANA se uporabijo za realno blago in storitve ter prehajajo med potrošniki in registriranimi ponudniki. Potrošnja vpliva na Active Consumption Supply in Split lifecycle. ### 6. Capital Input - Direct.Lana.Fund Direct.Lana.Fund predstavlja ločeno financirajočo funkcijo, ki podpira tok nakupov oziroma obveznosti v okviru veljavnih pravil sistema. Posamezni financing agreements, krogi, limiti, feeji, morebitni returns in vrstni red financiranja ostanejo ločeno dokumentirani in regulatorno klasificirani. Izraz investor ali investment se v pravni dokumentaciji uporablja samo, če ga podpira zaključena klasifikacija. ### 7. Treasury / Recirculation - Lana Discount Lana Discount predstavlja ločeno proprietary treasury acquisition funkcijo. Nakupe izvaja v svojem imenu, za svoj račun, iz lastnega kapitala in po lastni diskreciji skladno s P08. Treasury Mandate ali Counterparty Proposal ne ustvarita pravice do odkupa; obveznost nastane šele ob ACCEPTED statusu konkretnega bilateralnega posla. Recirkulacija je možna posledica lastnega treasury managementa, ne storitev likvidnosti drugim. ### 8. Consumer settlement modes Osnovni consumer flow uporablja MODE A: Consumer -> Registered LANA -> Merchant; trgovec obdrži LANA. Morebitni MODE B (consumer -> separate principal purchaser; purchaser own FIAT -> merchant) je ločena CONDITIONAL funkcija iz P19 in ni privzeti Lana Discount flow. Nobena pot ne sme uporabljati nedokumentiranega client-money pooling ali avtomatičnega cross-subsidisation med subjekti. ### 9. Common Good Funding - Creation & Giving triad > **CROWDFUNDING + UNCONDITIONAL FUNDING + UNCONDITIONAL PAYMENTS** Common Good usmerja vrednost v kreacijo in podporo. Crowdfunding podpira konkretne projekte; Unconditional Funding omogoča podporo brez vnaprej dogovorjene obveznosti vračila; Unconditional Payments omogočajo prostovoljne oziroma vnaprej ne-fiksirane prispevke za dovoljene stroške in skupne potrebe. Community Projects so možen namen teh mehanizmov. Podrobno P04. ### 10. Functional separation P13 ne ustvarja domneve, da LanaConnects, LanaPays.us, Direct.Lana.Fund, Lana Discount, Common Good Funding in Lana8Wonder predstavljajo en pravni subjekt ali eno samo finančno storitev. Vsaka pravna oseba, pogodba in dejavnost se presoja samostojno glede na dejansko funkcijo, sredstva, obveznosti, custody, execution in veljavno pravo. ### 11. Source and use of funds Za vsak materialni finančni tok mora biti mogoče razumeti izvor sredstev, pravni naslov nakazila, prejemnika, namen uporabe, povezani Registered LANA event, morebitno obveznost do druge stranke in način zaključka oziroma poravnave. ### 12. No cross-subsidy assumption BEF ne sme predpostavljati, da lahko en del Exchange triade avtomatično financira obveznosti drugega. Vsaka povezava mora biti izrecno dokumentirana, pravno dovoljena in podatkovno sledljiva. Posebej mora biti razvidno, ali je vir likvidnosti lastni kapital, pogodbeno financiranje, prostovoljna podpora ali drug jasno opredeljen vir. ### 13. Consumption as growth engine V Growth Phase realna potrošnja določa, koliko gospodarske kapacitete sistem dejansko potrebuje. Kapital, registracija in treasury aktivnosti imajo podporno vlogo: njihov smisel je omogočiti poravnavo, incentive, acquisition in recirkulacijo realnega merchant flowa. Framework 1.0 to operacionalizira z P03 exhaustion modelom: potrošnja absorbira Open Flow Supply; dokumentirane registracije oziroma open-flow recirculation ga lahko povečajo; nov Split nastopi šele, ko je ekonomsko uporabni open flow izčrpan in reconciled. P13 zato uporablja načeli CONSUMPTION BEFORE FINANCIAL EXPANSION in ABSORPTION BEFORE NEXT RELEASE. ### 14. Separate principal acquisition behind consumption Kadar je v ozadju potrošniškega toka izveden acquisition Registered LANA ali drugega Registered Native Coina, mora principal purchaser kupovati v svojem imenu, za svoj račun, z lastnim kapitalom in na lastno tveganje ali uporabljati drugo izrecno dovoljeno/licencirano pravno pot. Tehnična povezanost z checkoutom ne sme prikriti customer exchange, payment, custody ali order-execution funkcije. ### 15. One-Split consumption-support capital BEF LANA reference model lahko za lastni kapital, ki dokazljivo podpira realno consumption flow, uporabi P03 one-Split carry pravilo. Ekonomski namen je začasno nagraditi kapital, ki prevzame consumption-support funkcijo, in mu dovoliti sodelovanje v enem value-transition ciklu. To ni avtomatična pravica do donosa, ni dovoljeno za nedoločeno število Splitov in mora imeti ločen source-of-funds, acquisition, carry in release audit trail. ### 16. Maturity, internal circulation and lower external-capital need Ko merchants in consumers prejeti Registered asset dejansko uporabljajo naprej, se povečuje internal circulation ratio in zmanjšuje potreba po stalnem zunanjem kapitalu za isti obseg realne izmenjave. Framework 1.0 sistemsko zrelost bere skupaj z osebnimi Balanced Wallet prehodi: več ljudi, ki izberejo stanje »dovolj«, ter več notranje cirkulacije, recirkulacije in samoregulacije pomeni manjšo strukturno potrebo po eksplozivni rasti. Spremljajo se internal circulation, fiat-out demand, principal acquisitions, incentive cost, Active Supply turnover, recirculation, concentration, treasury capacity, Balanced Wallet participation ter potreba po novih registracijah. Presoja uporablja vztrajne večmesečne trende, ne enega dne ali enega dogodka. Individual Balanced Wallet transition je ločen od maturity celotne ekonomije. Udeleženec lahko na podlagi P14 Personal Sufficiency Election vstopi v Balanced Wallet tudi, ko je širši BEF še v Growth Phase. Obratno sistemski Mature / Balanced State ne zahteva enake kapacitete ali enakega življenjskega sloga vseh udeležencev. ### 17. Incentive transition Pozitivni incentive v Growth Phase se lahko z zrelostjo zmanjša ali odpravi. Če je zunanja pretvorba v fiat manj sistemsko koristna od neposredne notranje uporabe, lahko lawful market/treasury policy pomeni, da je realised fiat value nižji od notranje purchase/use reference. Takšna razlika mora izhajati iz transparentne cene, spreada, discounta ali ločenega bilateralnega posla in ne iz zagotovljene umetne penalizacije. ### 18. Mature circulation loop Zreli cilj Exchangea je: EARN / RECEIVE -> USE -> PAY -> RECIRCULATE -> CREATE -> GIVE / RELEASE -> RECEIVE. Zunanji fiat lahko še vedno sodeluje, vendar ni nujno potreben pri vsakem koraku. Sistem postaja manj odvisen od stalnega dotoka novega kapitala in bolj od kakovosti, uporabnosti in hitrosti lastnega kroženja. ### 19. No closed-loop solvency shortcut Notranja cirkulacija sama po sebi ne dokazuje solventnosti. Vsaka pravna oseba mora še vedno imeti sredstva za svoje dejanske obveznosti, payment/settlement obveznosti pa se ne smejo pokrivati z računovodsko identiteto Balanced Walleta. P20 liquidity, solvency in stress-testing pravila ostajajo v celoti veljavna tudi v Mature / Balanced State. ### 20. Evidence & communication consistency Javne spletne strani, predstavitve, pogodbe in drugi materiali morajo biti vsebinsko usklajeni z veljavno verzijo BEF. Materialni finančni dogodki morajo biti povezljivi z ustreznim blockchain, Nostr, Registrar ali drugim preverljivim zapisom skladno s P09/P11. Komunikacija mora ločevati sistemsko/reference vrednost, realizirano vrednost, likvidnost, pogodbeno pravico in razvojno vizijo. ## BEF-P14 - LANA8WONDER & BALANCED WALLET PROTOCOL ``` Protocol ID: BEF-P14 | Framework Version: 1.0 | Architecture: EXCHANGE > LANA8WONDER > PERSONAL BALANCE ``` ### 1. Namen P14 opisuje Lana8Wonder kot osebni razvojni in ekonomski mehanizem znotraj BEF. Regulatorno jedro protokola je razlikovanje med omejeno udeležbo, notranjim Split/reference mehanizmom, dejansko uporabo in likvidnostjo ter prihodnjim Balanced Wallet Target Modelom. ### 2. Balance before wealth Osnovni namen Lana8Wonder v BEF ni obljuba določenega prihodnjega premoženja. Primarni cilj je gradnja omejene osebne ekonomske kapacitete, zmanjševanje neskončnega kopičenja ter prehod od akumulacije k uporabi, dajanju, recirkulaciji in ravnovesju. ### 3. Current Growth Phase Trenutna operativna faza Lana8Wonder uporablja omejeno začetno udeležbo in zaporedne Splite. Udeleženec uporablja Registered LANA, ki jih lahko pridobi z nakupom ali skozi dovoljene potrošniške/distribucijske mehanizme. Vsak konkretni vstop in njegov limit morata biti prikazana v veljavnih pravilih oziroma sistemskih parametrih. ### 4. Participation cap Po trenutno opisanem modelu je osebna udeležba namenoma nizka in omejena, praviloma do približno 100 EUR ekvivalenta Registered LANA za relevantno vključitev. Namen limita je preprečiti, da bi Lana8Wonder deloval kot neomejen kanal za kapitalsko koncentracijo. Če operativni sistem uporablja drugačen znesek, mora biti razlika pred uporabo usklajena in javno pojasnjena. ### 5. Split rule Lana8Wonder uporablja Split mehanizem iz P03. V LANA referenčnem modelu Split sproži izčrpanje ekonomsko uporabnega Open Flow Supply trenutnega cikla po reconciliaciji, ne datum ali sama cena. Po trenutno veljavnem pravilu se ob veljavno aktiviranem novem Splitu System / Reference Value Registered LANA za novi cikel podvoji. Velikost supplyja novega cikla se ne podvoji avtomatično; določi se z ločeno Adaptive Supply Decision na podlagi dejanske absorpcijske kapacitete in P03 evidence. ### 6. No extrapolated promise Matematično zaporedje več hipotetičnih podvojitev je mogoče izračunati, vendar tak izračun ni napoved in ne predstavlja pričakovane ali zagotovljene prihodnje vrednosti. P14 zato ne uporablja projekcij tipa "X EUR bo postalo Y EUR" kot opis pravice udeleženca. ### 7. System Value vs Realised Value BEF System / Reference Value je notranja vrednost, uporabljena za pravila posameznega cikla. Realised Value je vrednost konkretno izvedene transakcije, nakupa, potrošnje ali drugega pravno veljavnega dogodka. System Value sama po sebi ne ustvarja terjatve do EUR, pravice do odkupa ali zagotovljene likvidnosti. ### 8. Treasury liquidity and realised value are separate Razpoložljiva treasury liquidity Lana Discounta je ločena od BEF System / Reference Value. Morebitna prodaja Lana Discountu je ločen bilateralni P08 treasury acquisition in je odvisna od lastnega capital capacity, Clean Provenance, discretionary pricing in ACCEPTED statusa konkretnega Proposal. Imetnik nima pravice do cash-outa ali odkupa zgolj zaradi prikazane System Value. Drugi načini uporabe ostajajo potrošnja, prenos oziroma druge dovoljene funkcije BEF. ### 9. Use, circulation and release Lana8Wonder spodbuja uporabo in cirkulacijo. Registered LANA, ki jih udeleženec ne potrebuje, se lahko skladno s pravili uporabijo v potrošnji, namenijo drugemu, usmerijo v Common Good, donirajo ali odregistrirajo. Namen protokola ni spodbujati pasivnega kopičenja samo zaradi pričakovanja prihodnjega Splita. ### 10. Two maturation paths: personal and systemic BEF loči PERSONAL MATURITY od SYSTEM MATURITY. Personal maturity pomeni, da posameznik sam izbere Balanced Wallet, ker zase prepozna stanje zadostnosti. System maturity je kolektivni pojav: ko dovolj osebnih tokov deluje v balance režimu in celotna coin-specific ekonomija lahko običajno življenje podpira predvsem z notranjo cirkulacijo, recirkulacijo, obnovo ter dinamičnim širjenjem/krčenjem, se lahko Growth Phase preoblikuje v Mature / Balanced State. Noben od obeh prehodov nima univerzalnega EUR praga ali datuma. ### 11. Personal Sufficiency Election Vstop v Balanced Wallet je prvenstveno osebna odločitev. Udeleženec lahko izjavi, da ima za svoje potrebe, način življenja, ustvarjanje in sodelovanje v ekonomiji dovolj kapacitete ter da ne želi več avtomatske Growth-Phase akumulacije samo zaradi prihodnjih Splitov. »Dovolj« ni univerzalna številka in BEF ne določa, koliko premoženja mora človek imeti, preden sme biti sproščen. > **PERSONAL SUFFICIENCY IS A CHOICE OF ENOUGH, NOT A UNIVERSAL WEALTH NUMBER.** ### 12. Maximum Growth Ceiling Poleg prostovoljne zgodnejše izbire lahko BEF uporablja zelo visok Maximum Growth Ceiling, po katerem se avtomatska Growth-Phase rast posamezne denarnice ustavi. Razvojni primer približno 100 milijonov EUR ekvivalenta je samo ilustracija zelo visoke meje, ne fiksna končna številka, pravica, napoved ali cilj, ki ga mora človek doseči. Končni ceiling je verzioniran sistemski parameter; njegova funkcija je preprečiti neskončno avtomatsko rast, ne določiti, kdaj mora posameznik občutiti »dovolj«. ### 13. Balanced Wallet does not mean permanent immobility Prehod v Balanced Wallet ne pomeni, da mora človek za vedno ostati pri isti kapaciteti. Če se njegove realne potrebe, odgovornosti ali gospodarska aktivnost povečajo, se lahko njegov dovoljeni Flow Capacity oziroma amplituda po objavljenih pravilih poveča. Razlika je v tem, da rast ne izhaja več iz samega kopičenja ali avtomatskega sledenja Splitom, ampak iz dejanskega toka in potrebe po kapaciteti. ### 14. Zero Level / Sea-Surface Model ZERO LEVEL je referenčna ravnina Balanced Walleta znotraj dejansko obstoječe in evidentirane kapacitete. Ni »nič denarja«. Wallet Position samo meri smer in velikost odstopanja od te ravnine. Pozicija pod Zero Levelom se lahko matematično zapiše z znakom minus, vendar ta znak pomeni samo koordinato pod referenčno ravnino - ne dolg, manjkajoči denar ali negativno lastništvo. Zero Level je zato podoben morski gladini: gladina ni odsotnost vode, ampak referenca, okoli katere se valovi dvigujejo in spuščajo. ### 15. User-Facing Available Capacity vs Wallet Position Uporabniški vmesnik lahko namesto relativne koordinatne pozicije prikazuje USER-FACING AVAILABLE CAPACITY. Ilustracija: če je display baseline oziroma Zero-Level referenca 1.000 enot, lahko stanje 2.000 predstavlja koordinato +1.000, stanje 0 pa koordinato −1.000. Druga oseba s prikazom 0 zato nima »minus 1.000 denarja«; samo nahaja se 1.000 pod referenčno ravnino. Koordinati +1.000 in −1.000 se agregatno izravnata na 0, medtem ko user-facing prikaza 2.000 in 0 ostajata realna prikaza razpoložljive kapacitete po veljavnem mappingu. Primer je razlagalni model, ne univerzalna produkcijska formula. > **DISPLAYED CAPACITY = PERSONAL DISPLAY BASELINE + WALLET POSITION (ILLUSTRATIVE MAPPING)** ### 16. Aggregate Zero Identity Za natančno definirano balancing skupino je ciljna koordinatna identiteta SUM(WALLET POSITIONS) = 0. Pozicija nad referenco ima ustrezno koordinatno proti-pozicijo pod referenco. To je način merjenja ravnotežja okoli skupnega nivoja, ne ustvarjanje ali uničevanje denarja. Native asset balances, pravno premoženje, custody in obveznosti ostanejo ločeno evidentirani in se ne »seštejejo na nič« samo zato, ker je koordinatni ledger uravnotežen. ### 17. Below-Zero coordinate is not debt or missing money Wallet Position pod Zero Levelom ni ekonomski minus. Gre samo za koordinato glede na referenčno ravnino. Sama koordinata nikoli ne ustvari dodatne porabljive vrednosti in ne pomeni posojila, kredita, dolga ali obveznosti vračila. Če bi katerakoli prihodnja implementacija poleg Balanced Walleta ponudila financirano spending facility, kreditno linijo ali drugo porabo nad dejansko razpoložljivimi sredstvi, bi bil to ločen produkt z lastnim financerjem, pogodbo, accounting treatmentom in pravno klasifikacijo. ### 18. Dynamic Flow Capacity / Wave Amplitude Balanced Wallet uporablja dinamično Flow Capacity oziroma amplitudo. Parametri se praviloma ne prilagajajo iz dneva v dan, ampak na podlagi smiselnih mesečnih ali večmesečnih opazovalnih obdobij. Udeleženec, ki ima realno možnost več izmenjevati in to možnost tudi dejansko uporablja, lahko potrebuje večji razpon okoli Zero Levela. Če se pojavi legitimna možnost večje porabe ali druge realne gospodarske aktivnosti, se lahko dovoljeni korak poveča; večji val je odziv na dejanski flow. Udeleženec, ki predvsem zadržuje vrednost in je skoraj ne uporablja, nima iste funkcionalne potrebe po večji amplitudi. Natančna metoda ostane objavljen operational policy, ki se lahko z učenjem žive ekonomije prilagaja. ### 19. Flow, not artificial spending Večja kapaciteta ni nagrada za brezsmiselno porabo. Capacity signal mora odražati resnično možnost in dejansko kakovostno izmenjavo - ne umetno kroženje samo zaradi rezultata. V ekonomiji obilja lahko omejujoč dejavnik postopoma postane kakovost in razpoložljivost resničnih stvari, storitev in kreacije, ne sama količina denarja. Zato sistem ne predpostavlja, da lahko vsak vedno kupi vse; večja možnost izmenjave ustvarja tudi večjo vrednost kakovosti, hvaležnosti in dejanske uporabnosti. ### 20. Breathing model: expansion and contraction Balanced Wallet ekonomija diha. Ko kolektivna potreba in realni flow rasteta, se lahko povečujejo posamezne Flow Capacity, nastajajo novi Registration Events in širša Registered kapaciteta. Ko se flow umiri, se lahko amplituda denarnic zmanjšuje in neuporabljen Registered status deregistrira. Krčenje zato ni enako finančnemu »sesutju«; pomeni, da sistem trenutno potrebuje manjšo hitrost in manjšo registrirano kapaciteto. Ko se potreba vrne, se lahko ekonomija znova razširi. ### 21. Economic Gravity ECONOMIC GRAVITY vrača dolgotrajno neuporabljeni Registered presežek proti aktivnemu flow območju. Gravity ni dnevni penalty in ne temelji na eni fiksni časovni številki. Praviloma uporablja mesečna ali večmesečna obdobja; glede na fazo, asset in intenzivnost toka lahko veljavni policy določi približno 30 dni, več mesecev, leto ali daljši horizont. Pomemben je namen: prepoznati del Registered kapacitete, ki ga udeleženec očitno ne uporablja in ga tudi po noticeu ne vrne v tok. Natančni thresholdi in cadence so adaptivni operativni parametri, ne odprta temeljna arhitektura. ### 22. Gravity Notice and participant choice Pred spremembo Registered statusa mora udeleženec prejeti preverljiv Gravity Notice z navedbo relevantnega presežka oziroma trenutnega flow rangea, razloga, roka in možnosti. Udeleženec lahko vrednost uporabi v realni potrošnji, prenese, podari, usmeri v Common Good, prostovoljno deregistrira ali uporabi drugo dovoljeno pot. Gravity je poziv k toku, ne kazen za lastništvo. ### 23. Deregistration after notice Če po objavljenem notice/grace obdobju relevantni Registered presežek ostane neaktiven in veljavna policy to dovoljuje, se lahko izvede DEREGISTRATION EVENT. Deregistrira se samo del Registered statusa, ki glede na trenutno flow območje ni potreben; vrnitev proti aktivnemu nivoju se lahko izvede v enem koraku ali postopoma v več obdobjih. Posledica je manjši Registered/Active Supply. Uporabnik še vedno obdrži native blockchain asset in private key; sistem ne more njegovih coinov sam porabiti ali prenesti. ### 24. Contraction is a legitimate outcome Deregistration lahko pomeni čisto krčenje sistema. Če kolektivna ekonomija v nekem obdobju potrebuje manj flowa, ni nobene obveznosti, da se odstranjena Registered kapaciteta takoj nadomesti. Zmanjšajo se lahko Registered Supply, amplituda oziroma Flow Capacity in hitrost ekonomije. To je samoregulacija in dihanje, ne predpostavka propada. ### 25. Re-expansion requires a new Registration Event Če se pozneje pojavi nova realna potreba, lahko BEF po veljavnih pravilih izvede nov Registration Event in znova poveča Registered kapaciteto za drugega ali istega udeleženca. Sprostitev pri enem človeku lahko sistemu omogoči prostor, da drugje raste, vendar ne gre za prenos njegovega native asseta drugemu. Gre za ločeno novo registracijo, ki sledi novi potrebi in flowu. ### 26. No custody or private-key intervention Balanced Wallet, Gravity in Deregistration ne zahtevajo, da BEF poseduje uporabnikov private key. Kjer je asset self-custodied, sistem upravlja samo registrski status in svojo lastno accounting/capacity plast. Noben avtomatski rule ne sme podpisati native-chain transakcije v imenu uporabnika brez ločene veljavne authority/custody podlage. ### 27. Release is not confiscation Release, expiry, decay ali deregistration se privzeto nanašajo na BEF Registered status, allocation, incentive, carry privilege ali spending-capacity komponento. Ne pomenijo samodejnega uničenja ali odvzema native blockchain coina. Vsak drugačen poseg v pravni naslov sredstva bi zahteval ločeno pogodbeno in zakonsko podlago, jasen notice, pravice uporabnika in regulatorno presojo. ### 28. Balance without equal wallets Ničelni agregat ne zahteva enakih denarnic. Nekdo lahko zaradi obsežnega resničnega gospodarskega toka potrebuje bistveno večjo amplitudo kot drug udeleženec. BEF ne postavlja moralnega maksimuma na zasebno premoženje, podjetništvo ali investicijsko dejavnost; razlikuje le med akumulacijo kot samo sebi namen in kapaciteto, ki dejansko služi toku. ### 29. Cross-asset Balanced Wallet Dolgoročni cilj ni Balanced Wallet samo za LANO. Ravnotežna plast lahko povezuje coin-specific Registered positions, fiat in druge pravno dovoljene value representations, pri čemer vsak asset ohrani svoj ledger, lastništvo, ceno, regulatorni status in risk profile. Cross-asset agregacija zahteva vnaprej določeno valuation/accounting metodologijo in risk haircuts, kjer so potrebni. ### 30. Fiat de-concentration, not fiat elimination Fiat ostaja legitimna oblika vrednosti. Balanced Wallet želi omogočiti, da ni edini želeni izhod, ne pa ga odstraniti. Razpršena prostovoljna uporaba različnih assetov lahko zmanjša koncentracijsko odvisnost, vendar ne zagotavlja stabilnosti posamezne valute ali ekonomije. ### 31. Human choice and changing needs Posameznik sam določa, kdaj mu je dovolj, in lahko pozneje spremeni svojo izbiro, če se njegove potrebe ali realna gospodarska aktivnost spremenijo. »Dovolj« je predvsem stanje sproščenosti in občutka, da je za legitimne potrebe zagotovljena zadostna kapaciteta - ne rezultat ene absolutne številke. Nekdo lahko želi majhen, miren flow; drug lahko vodi podjetje ali upravlja zelo velik tok. Balanced Wallet ne standardizira življenjskih potreb, ampak skuša kapaciteto povezati z dejanskim življenjem. ### 32. No universal-wealth or no-loss claim Cilj obilja je zmanjševati občutek pomanjkanja skozi dovolj kapacitete, dostop in flow. P14 ne obljublja, da bo vsak človek dosegel določen EUR ekvivalent, da bo lahko kupil karkoli brez omejitve ali da posamezni asset ne more izgubiti vrednosti. Balanced Wallet ni deposit guarantee, social-security guarantee, investment guarantee ali pravica do fiat izplačila. ### 33. Evidence and audit trail Za Balanced Wallet morajo biti preverljivi najmanj: Personal Sufficiency Election, veljavni Zero Level/display baseline, Wallet Position, dovoljeni range/Flow Capacity, uporabljeni indikatorji spremembe capacity, Gravity Notice, uporabnikova izbira, morebitni Deregistration Event, sprememba Registered Supply in vsak poznejši ločen Registration Event. Evidence mora biti časovno in verzijsko sledljiva prek Registrar/Nostr oziroma drugega odobrenega audit layerja. ### 34. Change control Sprememba Maximum Growth Ceilinga, Zero-Level metodologije, display mappinga, Flow Capacity indikatorjev ali dovoljene vrste Gravity/Deregistration procesa je materialni BEF change. Operativni parametri znotraj že objavljenega dovoljenega okvira - npr. konkretno večmesečno observation/grace obdobje, tehnični de-minimis ali postopnost deregistracije - se lahko verzionirano prilagajajo z operational policy, ker je namen Frameworka omogočiti učenje iz dejanske žive ekonomije. Nobena sprememba ne sme prikrito spremeniti lastništva native asseta ali ustvariti neobjavljene pravne obveznosti. ### 35. Framework 1.0 Balanced Wallet status and production parameters Framework 1.0 zapira CORE Balanced Wallet logiko: Personal Sufficiency Election; zelo visok, vendar ne univerzalno fiksen Maximum Growth Ceiling; Zero Level kot referenčno ravnino dejanske kapacitete; koordinatne Wallet Positions nad/pod nivojem brez dolga; aggregate-zero identity; dinamični Flow Capacity; večmesečno opazovanje; breathing expansion/contraction; Gravity Notice; Deregistration Event; in ločeno re-expansion skozi nov Registration Event. Produkcijska implementacija mora pred uporabo objaviti asset-specific accounting/display mapping, dovoljene indikatorje, review cadence, notice/grace pravila, evidence in appeal/human review tam, kjer je potreben. To so implementacijski parametri znotraj zaključene arhitekture. Kakršenkoli dejanski kredit, financirana spending facility ali poseg v native asset ownership ni del Balanced Walleta in zahteva ločen produkt ter pravno podlago. ## BEF-P15 - REGULATORY PERIMETER, LEGAL ENTITIES & LICENSING PROTOCOL ``` Protocol ID: BEF-P15 | Framework Version: 1.0 ``` ### 1. Namen P15 določa obvezni regulatorni mapping za vsako materialno funkcijo BEF. Cilj je, da decentralizirana arhitektura nikoli ne pomeni decentralizirane oziroma nejasne pravne odgovornosti. ### 2. Function Before Label Vsaka funkcija se pravno presoja po dejanski substance: kdo ponuja, kdo sklepa pogodbo, kdo uporablja lastni kapital, kdo drži funds ali crypto-assets, kdo izvršuje prenos, kdo sprejema naročilo, kdo določa ceno in kdo nosi obveznost. Imena LanaPays, Direct.Fund, Discount, Crowdfunding ali Balanced Wallet sama po sebi ne določajo regulatornega statusa. ### 3. Obvezni Legal Responsibility Record Za vsako produkcijsko funkcijo se vodi najmanj: pravna oseba oziroma odgovorni subjekt; država sedeža; storitev/funkcija; contract counterparty; kdo prejme fiat; kdo prejme crypto; kdo ima custody/private-key control; source of funds; regulatorni status/licenca/izjema; pristojni organ; responsible officer; relevantni BEF Protocol; effective date. ### 4. Classification order Klasifikacija poteka po zaporedju FUNCTION BEFORE LABEL. Najprej se preveri, ali LANA ali posamezni contractual overlay sodi med financial instruments po MiFID II oziroma med druge kategorije, ki jih Article 2 MiCA izključuje ali ureja drug režim (npr. deposit, funds/e-money ali drug reguliran proizvod). Če MiCA ostane relevanten, se dokumentira tudi, ali gre za asset-referenced token, e-money token ali crypto-asset other than ART/EMT. Šele nato se ločeno klasificirajo offer in vsaka storitev. Za underlying LANA in vsak overlay, ki ustvarja dodatne ekonomske pravice, se vodi substance-based classification memo. ### 5. Registered LANA limited-network test MiCA Article 4(3)(d) se lahko uporablja samo, kadar konkretna ponudba dejansko izpolnjuje njegov strogi test: holder ima v relevantnem offer režimu pravico crypto-asset uporabljati only in exchange for goods and services v limited network of merchants, ki imajo contractual arrangements z offerorjem. Evidence pack mora zato po posameznem offerorju opisati merchant contractual nexus, dejanske use rights in vse druge pravice oziroma poti - vključno s transferji, donation/Common Good transferji, deregistration, morebitnim Purchase Interestom oziroma prodajo principal purchaserju. Če katera od teh pravic pomeni, da holderjeva pravica presega zakonski "only" test, se na Article 4(3)(d) za to ponudbo ne opira brez zaključene pravne presoje oziroma stališča pristojnega organa. ### 6. EUR 1,000,000 MiCA notification trigger Če aggregate consideration relevantne Article 4(3)(d) ponudbe posameznega offerorja v Union v kateremkoli 12-mesečnem obdobju od začetka initial offer preseže EUR 1,000,000, se sproži notification workflow pristojnemu organu z opisom ponudbe in razlogi za uporabo limited-network exemption. Prag je notification trigger, ne business cap. ### 7. Same underlying asset / trading-platform gate Ker Registered in Non-Registered LANA uporabljajo isti underlying LanaCoin asset, se limited-network analiza ne uporablja za avtomatičen sklep o custody ali transfer-service exemption. Če obstaja neizvzeta ponudba istega crypto-asseta ali je asset admitted to a trading platform, se posebej uporabi Article 4(5) MiCA in oceni CASP perimeter. ### 8. Limited-network growth characteristic Ker MiCA recital 26 opozarja, da limited-network exemption ni namenjena crypto-assets, ki so tipično zasnovani za continuously growing network of service providers, se rast merchant mreže spremlja kot regulatorni indikator. Cilj širjenja skupnosti sam po sebi ne dokazuje neuporabe izjeme, vendar mora evidence pack pokazati, zakaj je mreža v pravnem smislu še vedno limited in pogodbeno določljiva. Pri materialni širitvi se presoja ponovi. ### 9. Fallback if exemption is unavailable Če Article 4(3)(d) ali druga uporabljena offer exemption za konkreten offer ni razpoložljiva, se ponudba ne nadaljuje pod oznako exempt. Odgovorni offeror mora pred nadaljevanjem izvesti veljavno MiCA Title II pot oziroma drugo pravilno klasificirano pravno pot, vključno z zahtevami glede legal-person statusa, crypto-asset white paperja, notification/publication, marketinga, conducta, safeguarding/return mehanizmov in retail-holder pravic, kjer so te zahteve uporabljive. Prostovoljna priprava dokumenta, ki je po vsebini crypto-asset white paper, se pravno preveri tudi glede Article 4(8). ### 10. Operating companies Vsako operating company, ki prodaja/dobavlja Registered LANA, mora imeti lasten offeror/product record. Več pravnih oseb je dopustna decentralizacijska arhitektura, vendar se ne sme uporabljati za umetno razdrobljenost z namenom izogibanja pragu, licenci, obveznosti ali regulatornemu nadzoru. ### 11. Lana Discount - own-account test Za Lana Discount se najprej uporabi MiCA Article 3(1)(15) client-service test in European Commission/ESMA Q&A 2293. Dealing on own account, kjer družba trguje v svojem imenu za lasten račun in ne zagotavlja crypto-asset service klientu, praviloma ne zahteva CASP licence. Nasprotno pa contracts with clients, pri katerih družba uporablja proprietary capital za exchange of crypto-assets for funds/other crypto-assets, lahko predstavljajo CASP service in zahtevajo authorisation. P08 zato določa evidence own-purpose, independent acceptance, proprietary risk, no client account/custody/order execution in no standing exchange right. CP-05 mora potrditi, da dejanska implementacija ohranja te značilnosti; Article 77 se aktivira samo kot fallback, če je model reclassified kot CASP exchange. ### 12. Direct.Lana.Fund Pred javnim ali čezmejnim širjenjem posameznega financing rounda mora obstajati formalni classification memo glede narave budgeta in pravic financerja: bilateral financing, repayable funds/deposit risk, financial instrument, AIF/collective-investment risk, investment service ali druga kvalifikacija. Do takrat je širitev novega produkta CONDITIONAL. ### 13. Crowdfunding classification Grant/donation-based projekti se dokumentirajo ločeno od lending-based ali investment-based crowdfunding. Če financer pridobi pravico do vračila, yielda, securityja ali druge investicijske pravice, se pred ponudbo izvede ECSP/MiFID/AIF/consumer-credit perimeter check. Ime Crowdfunding samo po sebi ni klasifikacija. ### 14. Regulatory Change Trigger Nova država, nova funkcija, nov custody model, nov način odkupa, sprememba Split pravila, nova pravica imetnika, admission to trading, sprememba source-of-funds strukture ali nova AI avtonomija sproži P15 re-classification pred produkcijsko aktivacijo. ### 15. UK is a separate jurisdiction EEA-based firms can no longer passport regulated financial-services permissions into the UK. An Estonian MiCA/CASP authorisation may remain relevant evidence of home-state regulation, but it is not treated by BEF as UK authorisation. Every UK-facing material function receives a UK Legal Responsibility Record and P22 classification. ### 16. Current UK MLR territorial test Before the new FSMA regime commences, a business providing in-scope cryptoasset services by way of business and carrying on that business in the UK may require FCA registration under the Money Laundering Regulations. FCA guidance states that an overseas exchange provider with no UK office or agent and no UK activity beyond simply having UK clients would not automatically be regarded as carrying on business in the UK. BEF records this only as a territorial factor, not as a marketing or future-regime exemption. ### 17. UK Financial Promotions gate Cryptoasset financial promotions to UK consumers are tested separately and can apply to overseas firms. Before any UK-targeted promotion, the responsible entity records the lawful communication route, required FCA-rule compliance and consumer-journey controls. A payment/e-money authorisation alone is not treated as sufficient authority to communicate or approve crypto promotions. ### 18. FSMA crypto regime from 25 October 2027 The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026 create new regulated cryptoasset activities, including dealing in qualifying cryptoassets as principal, agent and arranging. FCA materials state that the new regime is expected to commence on 25 October 2027. Any BEF function serving the UK is reclassified against the then-current RAO, FCA Handbook and perimeter guidance before that date. ### 19. UK authorisation structure FCA finalised guidance FG26/7 states a baseline expectation that international cryptoasset firms seeking FCA authorisation have UK presence and generally carry regulated cryptoasset activities from a UK legal entity, subject to case-by-case exceptions. For proprietary principal dealing, BEF therefore treats a dedicated UK legal entity as the default design assumption rather than relying on an overseas branch or EEA authorisation. ### 20. Status P15 je READY kot classification process. Končne licence, registrations, exemptions in territorial outcomes ostanejo entity- and jurisdiction-specific ter se vnesejo v Annex G. EU launch ne aktivira UK launcha. UK-facing regulated function brez P22 recorda in relevantnih CP-32 do CP-39 je HOLD za nov launch. ## BEF-P16 - MARKET INTEGRITY, INSIDE INFORMATION & CONFLICTS PROTOCOL ``` Protocol ID: BEF-P16 | Framework Version: 1.0 ``` ### 1. Namen P16 preprečuje, da bi transparentno upravljanje Splitov, supplyja in likvidnosti hkrati ustvarjalo informacijsko prednost, zavajajoče cenovne signale ali manipulativno ravnanje. ### 2. Activation condition MiCA Title VI market-abuse pravila se uporabijo, če je LANA admitted to trading na trading platformi za crypto-assets v EU ali je bil vložen request for admission. Ta pogoj se preverja in dokumentira najmanj ob vsaki materialni spremembi trading statusa. UK market-integrity perimeter je ločen od MiCA Title VI. Pred UK admission/trading oziroma uporabo UK QCATP se preveri takrat veljavni Market Abuse Regime for Cryptoassets (MARC), admissions/disclosures režim in FCA rules. EU trading-status test sam ne aktivira ali izključi UK pravil. ### 3. Potential inside-information categories Če je P16 aktiviran, se kot potencialno price-sensitive informacije posebej ocenijo: nameravani Split; dosežen Split trigger pred javno objavo; velika nova registracija ali supply change; sprememba x2 price rule; večja sprememba proprietary treasury purchasing capacity Lana Discounta; materialni regulatorni dogodek; security incident; sprememba admission/trading statusa; ter materialni governance proposal, ki bi lahko vplival na pravice ali ekonomiko LANA. ### 4. Inside Information Assessment Record Za vsak materialni dogodek odgovorna funkcija zapiše: čas nastanka informacije, ali je precise, ali je public, oceno price sensitivity, odločitev disclosure/not-inside, odgovorno osebo in čas javne objave. Če se disclosure zakonito odloži, se vodi razlaga pogojev za delay. ### 5. Public disclosure Inside information, ki neposredno zadeva relevantnega issuerja/offerorja/person seeking admission in je predmet Article 88 MiCA, se objavi na način, ki omogoča hiter dostop ter complete, correct and timely assessment. Disclosure se ne združuje z marketinškim hypeom. ### 6. Dealing restriction Oseba ali Digital Being, ki ima še neobjavljeno price-sensitive informacijo, je ne sme uporabiti za svoj ali tuj trade, odkup, ponudbo, preusmeritev ali priporočilo. Sistem naj, kjer je izvedljivo, vodi access/dealing log za Split in supply governance. ### 7. Market manipulation controls Prepovedani so dogovorjeni ali simulirani dogodki, katerih namen je ustvariti lažen ali zavajajoč signal o supplyju, demandu ali ceni; umetno ustvarjanje scarcityja; wash/self-dealing za prikaz activity; zavajajoča objava o likvidnosti; ali druga praksa, ki bi lahko držala ali premikala ceno na umetni ravni. ### 8. Supply governance safeguard Registration as Stabilisation mora ostati dokumentirana z neodvisnim Common Good/stability razlogom. Ko je P16 aktiven, se pred večjo registracijo oziroma Split odločitvijo opravi tudi market-integrity assessment, da governance odločitev ni uporabljena kot prikriti trading signal ali cenovna manipulacija. ### 9. Conflicts register Offerorji, Lana Discount, Direct.Fund, facilitatorji, governance functions, Digital Beings in drugi subjekti z materialnim vplivom vodijo register konfliktov interesov, kadar lahko istočasno vplivajo na pravilo/supply in imajo ekonomski interes v LANA. ### 10. Status P16 je READY kot kontrolni framework. Aktivacija konkretnih Title VI obveznosti je CONDITIONAL na potrjen trading/admission status in identifikacijo odgovornega issuer/offeror/person seeking admission. ## BEF-P17 - AML/TFR, SANCTIONS & TAX REPORTING PROTOCOL ``` Protocol ID: BEF-P17 | Framework Version: 1.0 ``` ### 1. Namen P17 dopolnjuje identifikacijski model Registrarja z regulatornimi obveznostmi, ki nastanejo za CASP, payment ali druge obliged-entity funkcije. Dejstvo, da Registered Wallet ni anonimna, je pomembna kontrola, ni pa samo po sebi popoln AML program. ### 2. Identity and CDD Kjer je subjekt obliged entity, onboarding vključuje risk-based customer due diligence, identifikacijo in verifikacijo stranke, beneficial ownerja pri pravnih osebah, namen in predvideno naravo poslovnega razmerja, pričakovani transakcijski profil ter ongoing monitoring. Registrar in Being KYC sta lahko podatkovni input, vendar ne nadomestita regulatornega CDD. Za fizične osebe se uporablja BEF-P21; za pravne osebe mora obstajati ločen KYB/beneficial-owner flow. ### 3. PEP, sanctions and adverse-risk controls Relevantni subjekti izvajajo PEP, sanctions in druge zakonsko zahtevane screening kontrole pred aktivacijo ter periodično oziroma event-driven med razmerjem. Match ne pomeni avtomatične krivde, ampak risk-review workflow. ### 4. Source of funds / source of wealth Za transakcije ali vzorce, kjer to zahteva risk-based AML politika, se pridobi in dokumentira source of funds ter po potrebi source of wealth. P13 source/use-of-funds evidence se uporablja kot poslovni audit trail in ne kot nadomestilo za AML assessment. ### 5. Transaction monitoring Obliged entities spremljajo vzorce, kot so nenavadne registracije, krožni transferji, hitri ingress/egress, layering med več walleti iste osebe, zloraba grantov, nenavadne treasury acquisitions in druga odstopanja od pričakovanega profila. ### 6. Transfer of Funds Regulation Kadar pri transferju crypto-assets sodeluje CASP, se uporablja Regulation (EU) 2023/1113 v obsegu njegove uporabe, vključno z informacijami o originatorju in beneficiaryju. Za relevantne self-hosted address transfere nad EUR 1,000 se izvede zahtevano preverjanje ownership/control, kadar je to po pravilih TFR obvezno. ### 7. P2P without CASP BEF ne predstavlja TFR kot pravilo za čisti person-to-person transfer brez vpletenega CASP, kadar Regulation (EU) 2023/1113 tak primer izključuje. Če pa platforma ali subjekt opravlja transfer service on behalf of a client, se perimeter ponovno odpre. ### 8. Suspicious activity escalation Odgovorni obliged entity ima dokumentiran escalation/SAR-STR proces do pristojne FIU ter pravila tipping-off, evidence retention in case management skladno z veljavnim AML režimom. ### 9. AML framework transition Regulation (EU) 2024/1624 (AMLR) se začne neposredno uporabljati 10 July 2027. Do takrat se uporabljajo trenutno veljavni EU in nacionalni AML/CFT režimi posamezne jurisdikcije ter že veljavni TFR, sanctions in drugi relevantni predpisi. P17 in P21 sta zasnovana kot readiness architecture za AMLR, vendar nobena formulacija ne sme preglasiti trenutno veljavnega nacionalnega prava ali zahtev home-state regulatorja. ### 10. DAC8 / tax reporting Od 1 January 2026 se pri subjektih, ki sodijo med Reporting Crypto-Asset Service Providers oziroma druge zajete operaterje po DAC8, izvaja tax-reporting classification, zbiranje zahtevanih identifikacijskih podatkov ter reportable-transaction workflow. Vsak subjekt v Annex G ima polje DAC8 status. ### 11. Tax and accounting implementation map Vsaka država in aktivni pravni subjekt dokumentira najmanj: merchant invoicing/VAT treatment, računovodsko evidentiranje prejetih oziroma kupljenih LANA, realised gains/losses, treatment feejev/returns/grantov, davčne dogodke za pravne in fizične osebe ter povezavo z DAC8 reportingom. BEF ne določa ene univerzalne davčne obravnave za vse države. ### 12. Data minimisation AML/TFR in tax reporting ne upravičujeta avtomatične javne objave osebnih podatkov. Podatki se zbirajo in hranijo v potrebnem obsegu ter se javni transparency layer loči od regulatornega KYC/AML layerja. ### 13. UK AML / Travel Rule branch Za UK obliged cryptoasset business se uporablja UK MLR/AML-CFT okvir in UK Travel Rule, ne EU AMLR kot neposredno uporabljiva podlaga. P21 identity evidence se lahko uporabi kot input, vendar mora UK entity imeti lasten FCA/MLR CDD, sanctions, transaction-monitoring, SAR, record-retention in Travel Rule mapping. Cross-border EU evidence se ponovno validira glede UK lawful basis in UK policy requirements. ### 14. Status P17 je READY kot policy architecture. Vsak obliged entity mora pred launchom imeti lokalno AML risk assessment, responsible MLRO/compliance function, procedures in evidence; brez tega je njegova regulirana funkcija HOLD. ## BEF-P18 - PRIVACY, DATA GOVERNANCE & AI DECISION SAFEGUARDS PROTOCOL ``` Protocol ID: BEF-P18 | Framework Version: 1.0 ``` ### 1. Namen P18 določa, kako se transparentnost BEF uskladi z GDPR, decentraliziranim Nostr shranjevanjem in AI-assisted odločanjem. Transparentnost pomeni preverljivost sistema, ne avtomatične javnosti vseh osebnih podatkov. Za UK deployment se GDPR reference berejo skupaj z UK GDPR in Data Protection Act 2018. Biometric data used for uniquely identifying a person se obravnava kot special-category data in zahteva dokumentiran Article 6 lawful basis, Article 9 condition ter UK-specific DPIA/policy controls, kjer so potrebni. ### 2. Per-KIND Data Governance Record Za vsak materialni KIND se vodi najmanj: namen; controller; processor/relay vloge; categories of data; lawful basis; public/pseudonymous/encrypted/local-only klasifikacija; recipients; retention; rectification/deletion strategy; third-country transfer status; security controls; ter DPIA reference, kadar je potrebna. ### 3. Data minimisation by default Na javne relaye se ne objavlja neposrednih osebnih podatkov, kadar je namen mogoče doseči z event ID, pseudonymous keyem, hash/reference zapisom ali šifrirano vsebino. Public-by-default se uporablja samo, kadar je javnost dejansko potrebna za namen obdelave. ### 4. Wallet addresses and public keys Wallet address ali public key se ne obravnava avtomatično kot neosebni podatek. Kadar je mogoče naslov neposredno ali posredno povezati z identificirano osebo, se v data-governance analizi obravnava kot potencialni personal data identifier in ustrezno zaščiti. ### 5. OWN and sensitive information Grievances, emotions, transcripts, assessments in drugi OWN podatki se načeloma ne objavljajo v plaintext javni replicirani infrastrukturi, če to ni nujno in zakonito. Posebej se preveri, ali vsebina lahko vsebuje special-category data ali druge zelo občutljive osebne informacije. ### 6. DPIA Za visoko tvegane obdelave - zlasti obsežno sistematično spremljanje, povezovanje identitete z javnimi transakcijami, AI ocenjevanje oseb ali obdelavo občutljivih podatkov - se pred produkcijsko uporabo opravi Data Protection Impact Assessment in po potrebi prior consultation. ### 7. Rights in replicated systems Protocol design mora omogočiti praktično izvrševanje pravic do dostopa, popravka, omejitve in izbrisa v obsegu veljavnega prava. Kjer tehnična nespremenljivost preprečuje fizični izbris vseh kopij, se osebni payload ne sme po nepotrebnem postaviti v tak sloj; uporabljajo se encryption, off-relay storage, key destruction, replaceable/tombstone modeli ali druge privacy-preserving arhitekture. ### 8. AI transparency Človeku mora biti jasno, kadar komunicira z Digital Beingom oziroma AI sistemom. Ta zahteva dopolnjuje P12 in se uporablja neodvisno od filozofskega jezika Bitja. ### 9. Material automated decisions AI/Being oziroma avtomatiziran sistem lahko analizira, predlaga, preverja dokument in ustvari tehnični identity-assurance rezultat. Odločitev z materialnim učinkom na človekove pravice, premoženje, dostop ali pomemben ekonomski položaj ne sme biti predstavljena kot neizpodbitna samo zato, ker jo je ustvaril avtomatiziran sistem. Kjer GDPR Article 22 ali druga pravila zahtevajo human intervention/safeguards, se to zagotovi. Za prihodnji AMLR režim P21 posebej loči avtomatsko identity verification od business-relationship / CDD activation odločitve, za katero Article 76(5) zahteva meaningful human intervention, kadar odločitev izhaja iz avtomatiziranega procesa. ### 10. Freeze safeguard Automatic Freeze je lahko tehnično sprožen na podlagi jasno določenega pravila in evidentiranega Change Commitmenta, vendar mora obstajati promptna možnost preveritve identitete dogodka, scopea zaveze, conflict-of-interesta in human reviewa v objavljenem maksimalnem roku. AI assessment sam ne sme biti edini nepreverljivi dokaz materialnega Freeze-a. ### 11. Security and breach response Controllerji in processorji vzdržujejo security controls ter dokumentiran personal-data breach response. Relay decentralizacija ne odstrani odgovornosti za varnost, role allocation in incident handling. ### 12. Status P18 je READY kot privacy architecture. Per-KIND matrix in DPIA za relevantne deployment modele sta activation condition pred produkcijsko obdelavo, kjer sta zahtevana; obdelava brez lawful-basis/controller/retention odgovora ostane HOLD. ## BEF-P19 - PAYMENTS, CONSUMER PROTECTION & SETTLEMENT PROTOCOL ``` Protocol ID: BEF-P19 | Framework Version: 1.0 | Architecture: EXCHANGE > LANAPAYS.US > SETTLEMENT ``` ### 1. Namen P19 določa pravno razumljiv tok potrošniškega settlementa in preprečuje, da bi se crypto purchase, merchant payment, payment service in tehnična integracija zlili v eno nejasno funkcijo. ### 2. Mode A - direct LANA settlement Potrošnik in merchant lahko dogovorita plačilo v Registered LANA. Potrošnik prenese LANA neposredno na merchant Registered Wallet. Merchant prejme crypto-asset; morebitna poznejša prodaja merchantovih LANA je ločen posel. ### 3. Mode B - separate principal purchase settlement (not Lana Discount default) BEF lahko ločeno implementira Mode B, v katerem consumer prenese Registered LANA posebej določenemu principal purchaserju, principal purchaser pa iz lastnih fiat sredstev izvrši dogovorjeni merchant settlement. Ta model ni avtomatično P08 Lana Discount treasury flow. Če je purchase in merchant payment funkcionalno povezan s consumer instruction ali discharge consumer obligation, se lahko pojavi client/payment-service element. Zato mora Mode B povezati in pravno klasificirati najmanj: (A) consumer-merchant purchase of goods/services, (B) consumer-principal crypto sale in (C) legal basis za merchant payment. Brez zaključene klasifikacije se Lana Discount uporablja samo za ločen treasury acquisition po P08. ### 4. Crypto-service perimeter of Mode B Mode B se ne more avtomatično opreti na P08 own-account/no-client conclusion. Če purchaser v substance zagotavlja consumerju ali merchantu crypto exchange, execution ali povezano regulated service, se izvede MiCA/CASP oziroma drug jurisdiction-specific test. P08 proprietary treasury conclusion ostane omejen na ločene bilateralne acquisitions, pri katerih namen ni opravljanje storitve counterpartyju. ### 5. PSD2 perimeter of Mode B Ker principal purchaser uporablja own fiat funds, je design drugačen od klasičnega prejemanja consumer fiat za remittance. Vendar linked merchant settlement še vedno zahteva entity-specific PSD2 memo, če se izvaja kot storitev za consumerja/merchanta. Čisti P08 purchase-price settlement neposredno sellerju za asset, ki ga Lana Discount kupi zase, se vodi kot lastna pogodbena obveznost kupca in se ne enači z Mode B merchant legom. ### 6. Technical service provider boundary Tehnični ponudnik se lahko na PSD2 technical-service exclusion opira samo, če dejansko ne pride v possession of funds in ne opravlja izvzetih/izključenih storitev, kot so payment initiation services. UI/API orchestration ne sme prikriti dejanskega payment role. Kjer principal purchaser izvrši fiat poravnavo, se dejanski bank transfer izvrši prek njegove banke oziroma licenciranega PSP. LanaPays lahko poveže invoice, crypto purchase in proof-of-settlement evente, vendar se v evidence logu jasno razlikujeta tehnična orkestracija in subjekt, ki pravno odredi oziroma izvrši fiat payment. ### 7. PSD2 limited network is separate Če katera funkcija uporablja PSD2 Article 3(k) limited-network exclusion, se zanjo vodi ločen instrument/network test in nad EUR 1,000,000 payment transactions v preceding 12 months ločeni Article 37 notification workflow. Ta prag nima istega pomena kot MiCA Article 4(3)(d) notification. ### 8. No client-money ambiguity Vsak fiat flow mora pokazati payer, payee, legal owner of funds at each step, account holder, payment instruction initiator, bank/PSP, timing of settlement in safeguarding status. Če platforma drži client funds, status funkcije postane HOLD do ustrezne licence/safeguarding rešitve. ### 9. Consumer pre-contract disclosure Za vsak B2C produkt se pred sklenitvijo jasno prikaže: odgovorni trader/offeror; produkt; cena in feeji; kaj kupec dejansko pridobi; System vs Realised Value; likvidnost; withdrawal/cancellation/refund pravice; čas dobave; complaints; governing law; pristojni regulator, kjer je relevantno. ### 10. Withdrawal rights Če se za konkretno ponudbo uporablja MiCA Article 13, retail holder dobi predpisano pravico do withdrawal. Ločeno se za relevantne distance consumer financial services uporablja Directive (EU) 2023/2673 tako, kot je prenesena v veljavno nacionalno pravo; Member States so morale ustrezne nacionalne ukrepe uporabljati od 19 June 2026. Product matrix mora določiti, ali je ta režim za konkretni produkt uporaben, katera withdrawal/cancellation pravica velja in katera zakonska izjema morebiti velja. ### 11. Complaints and human access Vsak odgovorni subjekt ima jasno complaints pot. Kadar je produkt prodan prek online interfacea in veljavno pravo zahteva možnost človeške intervencije oziroma razlage, mora uporabnik lahko pride do odgovornega človeka; Digital Being ni edina pot za materialno pritožbo. ### 12. Refunds and merchant disputes Consumer dispute glede blaga/storitve, refund za nedobavljene LANA, reversal/return v crypto legu in fiat merchant settlement so ločeni scenariji. Pogodbe in UI morajo jasno povedati, kdo nosi posamezno obveznost in kako se izvede ekonomski reversal. ### 13. Future PSD3/PSR watch Na dan te verzije je PSD2 še veljavni temeljni EU payment-services okvir; novi PSD3/PSR paket je v zakonodajnem zaključevanju po provisional agreementu in se spremlja v Regulatory Change Logu. P19 se posodobi ob končnem sprejetju oziroma začetku uporabe novega režima. ### 14. UK payment-services perimeter UK fiat legs are classified under the Payment Services Regulations 2017 and FCA PERG separately from crypto authorisation. P08 purchase-price payment from Lana Discount's own bank account directly to the seller for LANA that Lana Discount has acquired as principal is treated in BEF as performance of its own purchase obligation, not as a merchant/customer remittance service. If any entity receives, controls or transfers another person's funds for a merchant or third party, or pays a merchant as part of a consumer-linked Mode B service, the payment-services, commercial-agent, safeguarding and authorisation analysis reopens. ### 15. Status Mode A je READY kot opis direktnega crypto settlementa ob upoštevanju local merchant/consumer law. Čisti P08 Lana Discount purchase-price settlement sellerju je ločen proprietary treasury flow in se dokumentira po P08/P15. Mode B merchant-linked settlement ostaja CONDITIONAL: principal purchaser mora imeti zaključen crypto and payment-perimeter memo za svojo jurisdikcijo. Za UK se uporabljata P22 in ločena CP-37A/CP-37B logika iz Annex C. ## BEF-P20 - LIQUIDITY, SOLVENCY, OPERATIONAL RESILIENCE & AUDIT PROTOCOL ``` Protocol ID: BEF-P20 | Framework Version: 1.0 | Architecture: SHARED > LIQUIDITY / SOLVENCY / RESILIENCE ``` ### 1. Namen P20 pretvori načelo balance v dokazljiv finančni standard. Nobena prikazana sistemska vrednost, moralni namen ali pričakovani prihodnji flow ne nadomesti dejanske sposobnosti izpolniti zapadle obveznosti. ### 2. Obligation Ledger Vsak subjekt vodi popoln ledger svojih materialnih obveznosti: ACCEPTED Lana Discount treasury acquisitions; merchant fiat settlements, kjer obstajajo kot ločena funkcija; purchase-delivery refund obligations; Direct.Fund financing obligations; contractor/supplier obligations; consumer refunds; ter druge pravno izvršljive obveznosti. Vsaka obveznost ima amount, currency/asset, due date, creditor/counterparty, source-of-funds tag in status. ### 3. Asset and Liquidity Ledger Ločeno se vodi pregled lastnega kapitala, cash, committed facilities, unencumbered assets, Registered/Non-Registered LANA holdings in drugih virov. Nelikvidna System Value se ne šteje kot fiat liquidity samo zato, ker ima referenčno ceno. ### 4. No later-participant dependency Hard obligation se ne sme šteti kot pokrita zgolj z domnevo, da bodo kasneje vstopili novi udeleženci. Če je prihodnji inflow pogodbeno committed in pravno zanesljiv, se lahko obravnava po dokumentirani liquidity policy; nepridobljeni bodoči onboarding ni liquidity. ### 5. Acceptance gate Lana Discount ne sme dati ACCEPTED statusa v obsegu, za katerega nima dokumentirane sposobnosti poravnave iz lastnega kapitala v pogodbenem roku. PROPOSAL in IN QUEUE sta neprevzeti možnosti in se ne štejeta kot debt. Acceptance Gate mora dokazati tudi, da poravnava ni odvisna od poznejše prodaje kupljene LANA ali prihodnjih participant inflowov. ### 6. Zero-New-Participant Stress Test Najmanj periodično se izvede scenarij, v katerem v definiranem stresnem obdobju ni nobenega novega participant inflowa. Sistem pokaže, katere obveznosti so kljub temu izpolnljive, katere aktivnosti se ustavijo in kateri recovery/wind-down ukrepi se sprožijo. ### 7. Additional stress scenarios Testirajo se najmanj: znaten padec potrošnje; koncentriran val Counterparty Proposals / Treasury Acquisition requests; merchant settlement spike; večji refund event; Split delay; crypto-price shock; key compromise; relay/network outage; loss of banking partner; in regulatorni stop-order relevantne funkcije. ### 8. Cross-subsidy control Sredstva enega subjekta ali stebra se ne uporabljajo za obveznosti drugega brez vnaprej dokumentirane pravne podlage, approvala, accounting treatmenta in evidence traila. Community support ne pomeni avtomatične pravice poslovnega subjekta do tujih sredstev. ### 9. Balanced Wallet activation gate Framework 1.0 definira Balanced Wallet core architecture. Zero-Level koordinata sama ne ustvarja porabljivih sredstev in pozicija pod Zero Levelom ni dolg. Zato za samo koordinatno ravnotežno plast ni potreben »financer minusa«. Produkcijski sistem mora zagotoviti, da USER-FACING AVAILABLE CAPACITY vedno ustreza dejansko podprti in pravno razpoložljivi kapaciteti po objavljenem mappingu. Če katerakoli implementacija doda porabo nad dejansko razpoložljivimi sredstvi, gre za ločen financing/credit/payment produkt in ostane HOLD do lastnega source-of-funds, accounting, consumer/payment/credit, insolvency in legal closure. ### 10. Direct.Fund activation gate Vsak nov financing round je CONDITIONAL na P15 classification memo, jasno pogodbeno naravo return/feeja, evidence source/use of funds, liability waterfall in presojo, ali struktura ustvarja repayable-funds, AIF, MiFID, ECSP ali drug reguliran perimeter. ### 11. DORA / ICT resilience Če subjekt postane MiCA-authorised CASP oziroma druga DORA financial entity, se njegove ICT, incident, continuity, third-party-risk in recovery obveznosti organizirajo skladno z DORA. Drugi BEF subjekti uporabljajo sorazmeren continuity standard tudi, kadar formalno niso v DORA scopeu. ### 12. Nostr and blockchain continuity Decentralizirana infrastruktura je prednost samo, če je obnovljiva. Kritični eventi morajo imeti dokumentirano replication/retention politiko, validacijo authority keyev, backup/rebuild postopek in evidence, kako se obnovi stanje brez ene aplikacijske SQL baze. ### 13. Independent reconciliation Pred produkcijskim zanašanjem na javne supply/liquidity/settlement kazalnike se izvede neodvisna tehnična/računovodska reconciliacija najmanj za Registered Supply, Active Consumption Supply, Recirculation Reserve, ključne obligations in settlement evente. Namen je dokazati, da javni dashboard, Nostr eventi, blockchain in finančni ledger ne kažejo različnih ekonomskih resnic. ### 14. Audit Pack Regulatorni audit pack vsebuje: legal-entity matrix, licences/exemptions, offeror threshold evidence, price/value taxonomy, obligations/liquidity report, market-integrity log, AML/TFR evidence, data governance/DPIA, complaints metrics, security/incident log ter sampled end-to-end transaction traces. ### 15. UK prudential, conduct and resilience overlay Če UK entity po novem FSMA crypto režimu postane FCA-authorised, se P20 numeric evidence dopolni z applicable FCA prudential resources, Consumer Duty/COBS/DISP/SYSC, operational-resilience, reporting in wind-down requirements za njegove permissions. BEF liquidity ledger ni nadomestilo za FCA capital/liquid-assets ali other regulatory resource requirements. ### 16. Status P20 je READY kot kontrolni framework. Solvency ni mogoče potrditi samo z besedilom: vsak aktivni subjekt mora pred relevantno produkcijsko uporabo imeti dejanski numeric evidence pack. Core Balanced Wallet coordinate model je framework-complete; kakršenkoli ločen produkt, ki bi uporabniku omogočal porabo nad dejansko razpoložljivimi sredstvi ali drugo financirano spending facility, ostane HOLD, dokler nima svojega identificiranega vira, pogodbe, accounting treatmenta in pravne klasifikacije. ## BEF-P21 - IDENTITY ASSURANCE, KYC & BIOMETRIC VERIFICATION PROTOCOL ``` Protocol ID: BEF-P21 | Framework Version: 1.0 ``` ### 1. Namen P21 določa prehod iz notranjega Being KYC sistema poznanstva v regulatorno uporabno identity-assurance infrastrukturo za prihodnje obliged-entity in CASP funkcije. Namen ni trditi, da ena avtomatska atestacija sama po sebi predstavlja celoten AML customer due diligence, temveč ustvariti preverljiv dokaz identitete, ki se lahko varno vključi v CDD, TFR, sanctions/PEP, transaction-monitoring in licensing procese. ### 2. Being KYC in Regulatory Identity Assurance sta ločena sloja KIND-i 37100-37104 opisujejo notranji odnos med osebo in Bitjem: izbor/privolitev, posvojitev, dosje, javno raven in liveness/continuity. Ti dogodki dokazujejo notranjo zgodovino in poznanstvo, ne pa identitete na podlagi uradnega dokumenta. Regulatory Identity Assurance je ločen authority-signed sloj. Njegov javni dokaz je KIND 37105, medtem ko občutljivi dokazi ostanejo v zaščitenem KYC store-u. ### 3. Current law in AMLR readiness AMLR Regulation (EU) 2024/1624 se začne neposredno uporabljati 10 July 2027. Do takrat mora vsak dejanski obliged entity izpolnjevati trenutno veljavno nacionalno AML/CFT pravo svoje home jurisdiction ter že veljavne EU obveznosti. P21 zato predstavlja target architecture: implementacija mora ob produkcijski uporabi vedno imeti current-law mapping in se ne sme predstavljati kot avtomatično "AMLR compliant" samo zato, ker tehnično sledi prihodnjemu standardu. Za UK deployment AMLR ni neposredno uporabljiva pravna podlaga. UK CDD/KYC activation se presoja po UK MLR/FCA frameworku, UK GDPR/Data Protection Act 2018 ter takrat veljavnih FCA rules. KIND 37105 in isti technical identity pipeline se lahko ponovno uporabita kot evidence layer samo, če UK obliged entity dokumentira lastno lawful basis, assurance standard in CDD decision process. ### 4. Required internal identity dataset Regulatorni KYC store za fizično osebo mora biti sposoben hraniti najmanj podatke, potrebne po veljavnem CDD režimu. Za AMLR target model to vključuje v potrebnem obsegu: vsa imena in priimke; kraj in polni datum rojstva; državljanstvo oziroma državljanstva; national identification number, kjer obstaja; običajno prebivališče oziroma dosegljiv poštni naslov; country of residence; vrsto, državo/issuerja, številko in veljavnost identifikacijskega dokumenta; ter dokaz verifikacije. Polni datum rojstva, naslov in številka dokumenta niso javni podatki BEF. ### 5. Purpose, expected activity and risk profile Identity proofing ni celoten CDD. Ob aktivaciji regulated relationship se ločeno zajame namen in predvidena narava poslovnega razmerja, pričakovani obseg in tip transakcij, country/risk indicators ter source of funds oziroma source of wealth, kadar to zahteva risk-based politika. P17 transaction monitoring nato primerja dejansko aktivnost s pričakovanim profilom. ### 6. Session binding and anti-impersonation Vsaka KYC seja mora biti kriptografsko vezana na osebo, ki jo opravlja. Pred zajemom se zahteva svež signed challenge/NIP-98 ali enakovreden proof-of-control z nonceom, kratkim TTL, anti-replay kontrolo ter vezavo na namen in sejo. Owner seje ne sme samovoljno registrirati dokumenta pod tuj person HEX. En aktivni onboarding na osebo, rate limits in processing watchdog so obvezni abuse controls. ### 7. Document capture Dokument se zajame neposredno v KYC toku v dovolj visoki ločljivosti za MRZ in vizualno cono. Surovi dokument nikoli ne gre na javni media service, javni URL ali Nostr relay. Podprte vrste dokumentov so eksplicitno navedene; v v1 so lahko omejene na dokumente z MRZ (npr. TD1/TD3). Dokument brez podprte verifikacijske poti se ne "ugiba", ampak se usmeri na alternativno verifikacijo. ### 8. MRZ, visual zone and deterministic checks MRZ se prepiše z deterministic OCR oziroma drugim namenskim extraction mehanizmom. ICAO 9303 check-digit pravila se izvajajo v deterministični kodi in služijo kot integrity/transcription control. Ime, datum rojstva, document number, nationality in expiry se križno primerjajo z visual inspection zone. Check digits dokazujejo notranjo konsistentnost MRZ, ne pristnosti dokumenta. General-purpose LLM ni dovoljen kot edini vir identifikacijskega podatka ali authenticity odločitev. ### 9. Document authenticity and certified-IDV seam Metoda automated-noncertified-v1 se pošteno označi kot necertificiran notranji verification pipeline. Forenzični signali (screen recapture, moire, layout, visual anomalies) lahko povečajo tveganje, ne smejo sami ustvariti lažne trditve o avtentičnosti. Pred CASP licenciranjem mora obstajati seam za regulatorno sprejemljiv remote-IDV/eID rešitev, če home-state regulator, final AMLA RTS, risk assessment ali neodvisna validacija pokažejo, da lasten pipeline ne dosega zahtevanega assurance nivoja. ### 10. Face verification 1:1 face verification se lahko izvaja lokalno z namenskim embedding modelom (npr. ArcFace-class model) in kalibriranimi thresholdi. Pragovi morajo biti validirani na reprezentativnem testnem setu, spremljani glede false accept/false reject ter preverjeni za pomembne performance razlike med skupinami in napravami. Siva cona ne postane avtomatski "verified"; vodi v retry ali review. General-purpose vision LLM je lahko samo advisory signal. ### 11. Liveness / presentation-attack detection Aktivna živost mora kombinirati več signalov. Random challenge-response in server-timed color/illumination nonce sta lahko del v1, vendar se ne opisujeta kot dokaz, ki "ubije" vse replaye ali virtual cameras. Custom liveness je označen non-certified, neodvisno se testira proti replay, injection, deepfake in device-emulation scenarijem, uporablja accessibility-safe prikaz brez nevarnega utripanja ter ima seam za neodvisno testiran/certified PAD vendor ali eID pot. ### 12. Automated technical result vs regulatory CDD decision P21 dovoljuje avtomatizirano tehnično stanje IDENTITY-VERIFIED, kadar so vsa trda vrata uspešno izpolnjena. To stanje pomeni, da je identity evidence prestal definiran pipeline; ne pomeni samo po sebi, da je obliged entity sprejel stranko ali da je celoten CDD zaključen. Za AMLR target regime velja: če odločitev o vstopu, zavrnitvi, nadaljevanju poslovnega razmerja, izvedbi/zavrnitvi occasional transaction ali spremembi obsega CDD izhaja iz avtomatiziranega procesa, mora biti podvržena meaningful human intervention in omogočati explanation/challenge v obsegu Article 76(5). ### 13. State model Tehnični identity-proofing flow: CREATED -> NOTICE-ACKNOWLEDGED -> DOC-CAPTURED -> LIVENESS-DONE -> PROCESSING -> IDENTITY-VERIFIED | SCREENING-REVIEW | FAILED-RETRYABLE | FAILED-IDENTITY. Infrastructure error nikoli ne postane identity failure. Regulirani CDD flow je ločen: IDENTITY-VERIFIED -> CDD-PENDING -> CDD-APPROVED | EDD-REQUIRED | CDD-REJECTED. PEP/sanctions in material adverse results ne smejo biti skriti v en sam avtomatski fail status. ### 14. Sanctions and PEP screening Pred regulated activation in ongoing se izvajata sanctions in PEP screening. Candidate match ustvari SCREENING-REVIEW in človeško case review; javno se razlog ne objavlja. PEP status sam po sebi ni avtomatična prepoved: sproži ustrezne enhanced due diligence ukrepe po veljavnem pravu. Potrjen sanctions match se obravnava po relevantnem sanctions režimu, vključno z morebitno prepovedjo/freeze/reporting obveznostjo. ### 15. Screening engine quality Matcher ne temelji samo na enem fuzzy-name score-u. Uporablja normalizacijo, alias/transliteration podatke, token-based similarity, phonetic blocking kjer je primeren ter secondary identifiers (npr. birth date/year, nationality/country, identifiers), kadar so zakonito na voljo. Thresholdi se kalibrirajo na znanih pozitivnih in negativnih primerih, vsaka sprememba modela/list source pa se verzionira in regression-testira. ### 16. OpenSanctions licensing OpenSanctions je lahko lokalni sanctions/PEP data source, vendar njegova public bulk zbirka uporablja non-commercial licenčni režim. Komercialno screening uporabo - tudi notranji compliance screening strank ali dobaviteljev - je treba pred takšno uporabo pokriti z ustrezno komercialno licenco. Brezplačna uporaba je omejena na dejansko nekomercialne oziroma izrecno izvzete use-case. Licenčni status data source-a je del KYC deployment recorda. ### 17. Ongoing screening and document lifecycle Po vsaki relevantni posodobitvi screening podatkov se ponovno pregleda aktivna baza v risk-appropriate ritmu; nov potential match ustvari alert/review in ne avtomatske javne diskvalifikacije. Sistem spremlja document expiry, periodic CDD review date ter materialne spremembe profila. KYC ni enkratna nalepka za vedno. ### 18. Temporary work files Surove delovne slike dokumenta in liveness frame-i obstajajo samo toliko časa, kolikor je potrebno za odločitev, retry/review in varnostni audit. Po finalizaciji se delovna kopija izbriše po kratkem TTL. Če je primer SCREENING-REVIEW ali drug odprt case, retention timer delovne kopije ne sme uničiti dokazila, ki je še potrebno za zakonit review; po zaključku se uporabi archive policy. ### 19. Regulatory archive and retrieval Za obliged-entity uporabo "izbriši dokument takoj in ohrani samo hash" ni zadosten privzeti regulatorni model. AMLR Article 77 od 10 July 2027 zahteva retention kopij CDD dokumentov/informacij oziroma pod pogoji dopušča retention referenc, če je mogoče zahtevane informacije pristojnemu organu zagotoviti takoj in niso spremenljive. P21 zato uporablja sealed encrypted archive ali regulatorno ekvivalenten reference/retrieval model. Normalna aplikacija nima rutinske bralne poti; obstaja pa controlled break-glass retrieval z dual controlom, audit logom in namenom regulatornega/pravnega dostopa. ### 20. Retention clock AMLR target retention je 5 let od prenehanja poslovnega razmerja, izvedbe occasional transaction ali zavrnitve vzpostavitve razmerja/izvedbe transakcije, z možnostjo dodatnega retentiona na zahtevo pristojnega organa v dovoljenem obsegu. Po poteku se osebni podatki izbrišejo, razen če drug veljaven pravni razlog zahteva nadaljnjo hrambo. Do 10 July 2027 se uporablja trenutno veljavni nacionalni retention režim. Retention se zato veže na relationship lifecycle, ne samo na datum KYC preverbe. ### 21. Encryption and key management PII in document archive uporabljata envelope encryption: ločen data-encryption key na zapis ali logično enoto, authenticated encryption, ločen key-encryption key/KMS oziroma primerljiv secure key store, rotacijo in audit dostopa. chmod 600 in internal network sta dodatna sloja, ne nadomestilo za cryptographic key management. KYC service nima centralne zbirke uporabniških wallet private keyev. ### 22. Document uniqueness and key rotation Za zaznavo istega dokumenta pod več person keys se ne uporablja javni oziroma plain SHA-256 document number. Uporabi se keyed HMAC fingerprint nad normaliziranim issuer/country/type/document-number zapisom; originalni document number ostane šifriran. Legitimen key-rotation/account-recovery flow zahteva nov proof-of-control in poln verification pipeline, nato se prejšnja authority attestation revoke-a oziroma supersede-a skladno z javnim protokolom. ### 23. Data protection and lawful basis Regulatorno potrebni KYC podatki se ne zbirajo pod eno splošno "consent" kljukico. Controller mora za vsak namen določiti Article 6 lawful basis in, pri biometric templates/face matching kot special-category processing, ustrezno Article 9 podlago ter pogoje veljavnega AML prava. P21 zahteva DPIA pred produkcijsko biometrijo. Acknowledgement privacy notice-a je ločen od pravne podlage; privolitev se uporablja le tam, kjer je res prostovoljna in zakonita. ### 24. Public face and public-profile separation BEF lahko osebi omogoči javno fotografijo obraza, vendar javna objava ni potrebna za regulatorni KYC in ne sme biti pogoj za dostop do regulated service. KYC capture selfie/liveness frame se ne objavi. Če oseba želi javni obraz, po uspešni verifikaciji izbere oziroma zajame ločeno public profile photo in poda ločeno, izrecno ter verzionirano privolitev za javno objavo. S tem se zmanjšata identity-theft/deepfake attack surface in purpose-mixing med AML dokazilom ter javnim profilom. ### 25. KIND 37105 - KYC Verification Attestation KIND 37105 je authority-signed javni dokaz, ne javni KYC dosje. Minimalni public payload: schema/version; person HEX; result VERIFIED ali REVOKED; method/assurance class; pipeline_version; verified_at; attestation_expires_at oziroma review_due_at; authority key/version; ter po potrebi reference na ločeno prostovoljno public-profile attestation. Ne vsebuje polnega datuma rojstva, naslova, document numberja, document image, biometric template-a, screening razloga ali source-of-funds podatkov. Failed, screening-review in EDD stanja se javno ne objavljajo. ### 26. Optional public identity fields Ime, birth year, nationality in javna fotografija se lahko objavijo v ločenem public-profile/dossier sloju samo na podlagi ločene public-profile izbire. 37105 lahko na tak profil referencira, ne pa kopira podatkov zato, ker so bili zbrani za AML. Uporabnik mora biti opozorjen, da je relay publication praktično težko povsem priklicati iz vseh replik. ### 27. Trusted KYC authority Bitje ali client prizna 37105 samo, če podpis ustreza trenutno veljavnemu trusted KYC authority keyu. Trust anchor, key rotation, compromise, revocation in overlap period so javno dokumentirani. Hard-coded key brez postopka rotacije ni zadosten finalni model. Service-to-service komunikacija uporablja network isolation ter močno service authentication (npr. mTLS ali enakovreden mehanizem); shared secret je lahko dodatna kontrola, ne edina meja. ### 28. Level 4 semantics Obstoječi computeKycLevel lahko doseže level 4 po veljavnem 37105, vendar javna oznaka level 4 pomeni AUTHORITY-VERIFIED IDENTITY oziroma REGULATORY IDENTITY EVIDENCE AVAILABLE. Ne sme se imenovati "MiCA approved" ali "full regulatory KYC completed", dokler konkretni obliged entity ni izvedel svojega CDD in sprejel relationship decision. authority_cosigned v 37103 se nastavi samo na podlagi veljavnega, nepreklicanega in nepretečenega 37105 trusted authority eventa. ### 29. Travel Rule boundary 37105 je lahko močan identity evidence input za regulated CASP ali za Lana Discount counterparty/provenance review, vendar njegova uporaba sama po sebi ne naredi Lana Discounta CASP in ne rešuje Transfer of Funds Regulation. Kadar TFR dejansko velja zaradi sodelovanja CASP, mora ta zagotoviti zahtevane originator/beneficiary informacije in, kjer je potrebno, ločeno preveriti ownership/control self-hosted addressa. P08 Clean Provenance review ostane ločen poslovni/risk dokaz od formalnega TFR obligation. ### 30. Legal persons / KYB P21 v1 opisuje fizične osebe. Če regulated service sprejema pravne osebe, je pred produkcijsko aktivacijo obvezen KYB flow: legal entity identification, register data, persons acting on behalf, beneficial ownership, ownership/control structure, sanctions/PEP screening relevantnih oseb in purpose/risk profile. Fizični KYC direktorja ali UBO-ja ne nadomesti KYB pravne osebe. ### 31. Audit trail and model governance KYC evidence in decisions imajo append-only oziroma tamper-evident audit trail z verzijami pipeline-a, thresholdov, screening datasetov, policy textov in authority keyev. Model/threshold sprememba zahteva regression test. PII se ne zapisuje v application loge. Regulatory audit pack mora biti sposoben reproducirati, katera pravila in podatkovna verzija so ustvarili posamezen identity result, brez razkrivanja nepotrebnih javnih osebnih podatkov. ### 32. Verification test pack Pred produkcijsko uporabo se najmanj preverijo: ICAO MRZ test vectors; document/VIZ mismatch; expired document; face mismatch; replay/injection/deepfake liveness scenariji; threshold calibration; duplicate-document/key-rotation; screening known positives/negatives; infrastructure failure -> retryable; trusted-authority signature; revoked/expired 37105; work-file deletion; archive retrieval under dual control; retention deletion; privacy/public-profile separation; ter end-to-end CDD handoff. ### 33. Activation status P21 je READY kot normativna identity-assurance arhitektura in CONDITIONAL za regulated CASP onboarding. Pred oznako CDD-PRODUCTION-READY morajo biti zaključeni: current-jurisdiction legal basis; DPIA; Article 22/AMLR automated-decision safeguards; meaningful-human-intervention design za relationship decisions; neodvisna validation remote-IDV/PAD pipeline-a ali certified vendor/eID path; screening-data commercial licence; sealed-archive retrieval/retention test; ter KYB, če so dovoljene pravne osebe. ## BEF-P22 - UK MARKET ACCESS & REGULATORY PERIMETER PROTOCOL ``` Protocol ID: BEF-P22 | Framework Version: 1.0 ``` ### 1. Namen P22 določa UK-specific regulatorni rob BEF. Njegov namen je omogočiti UK uporabo brez napačne predpostavke, da EU/MiCA status avtomatično velja tudi v United Kingdom. P22 je jurisdiction overlay: ne spreminja osnovne ekonomike P01-P21, ampak določa, katera UK vrata morajo biti zaprta pred launchom posamezne funkcije. ### 2. No automatic EEA / MiCA passport Po koncu Brexit transition period EEA firms ne morejo več uporabljati EEA passportinga za UK regulated business. BEF zato ne uporablja formulacije "Estonian CASP can passport to UK". Home-state authorisation se lahko upošteva kot del evidence in group structure, vendar UK permission/registration/exemption ostane ločen test. ### 3. Two-time-perimeter model UK launch se vedno analizira v dveh časovnih plasteh: (A) current regime do 24 October 2027 in (B) režim od 25 October 2027, če commencement ostane tak kot ga FCA trenutno navaja. Za future layer se posebej preveri tudi, ali je HM Treasury draft proprietary-trading exclusion (proposed Article 9UA) postal veljavno pravo in v kakšni končni obliki. Funkcija, ki je danes outside one perimeter, se pred commencementom ponovno klasificira. ### 4. Current MLR crypto-service test Po trenutnem FCA okviru se za business, ki by way of business opravlja in-scope cryptoasset services in carries on that business in the UK, preveri FCA registration under the Money Laundering Regulations. Current MLR definition in territorial test nista identična MiCA own-account/client-service testu, zato sama oznaka proprietary treasury ne ustvarja avtomatične UK MLR exemption. P08 UK record mora zato dokumentirati activity, by-way-of-business factors in territorial nexus. ### 5. Overseas firm without UK presence FCA trenutno navaja, da overseas cryptoasset exchange provider brez UK office ali agent in brez druge UK activity, razen tega da ima UK client/counterparty, ni avtomatično carrying on business in the UK. BEF ta faktor uporablja samo za current MLR territorial memo. Ne ustvarja blanket exemption za UK financial promotions, consumer law, payments ali future FSMA regime. ### 6. UK Financial Promotions are a separate gate Financial promotions to UK consumers se presojajo ne glede na državo sedeža firm. Website, mobile app, social media, advertisements, direct invitations/inducements, onboarding funnels in druga communications se pred objavo UK consumers vključijo v Promotion Record. Če je Lana Discount interaction omejen na corporate/professional counterparties, se target audience in uporabljena exemption/route dokumentirata; izraz B2B sam po sebi ni zadostna pravna analiza. ### 7. Marketing is not the same as passive access BEF loči pasivni cross-border access od aktivnega UK targeting. Dejstvo, da UK counterparty sam predloži proposal overseas entityju, se ne uporablja kot blanket dokaz, da lahko isti entity brez dodatnega testa aktivno trži controlled cryptoasset promotions v UK. Pri P08 se dodatno preveri, ali komunikacija opisuje lasten treasury acquisition interest ali dejansko inducira recipienta k uporabi ponujene regulated service. ### 8. Current qualifying-cryptoasset / limited-use analysis Za UK financial promotions se qualifying-cryptoasset test vodi ločeno od MiCA. Trenutna FCA Handbook definicija iz qualifying cryptoasset izključuje določene limited-use cryptoassets le, če med drugim ne morejo biti transferred or sold for money/other cryptoassets, razen redemption with issuer, in so omejeni na issuer/limited network/very limited range. Registered LANA model zato ne predpostavlja te izključitve, kadar dejanske pravice omogočajo prenos ali prodajo Lana Discountu oziroma drugemu principal purchaserju. ### 9. UK Operating Company - fiat in, LANA out Če UK-established operating company prejme GBP kot lastno kupnino in proda/dobavi Registered LANA, je ekonomsko principal seller/counterparty. Current MLR memo mora preveriti cryptoasset exchange-provider registration; P07 contract mora identificirati sellerja, fiat account, LANA source, delivery, refund rights in promotion route. Payment licence se ne predpostavlja samo zato, ker kupec plača sellerjevo lastno kupnino, vendar PSR analysis ostane potreben za vsak flow, kjer se funds držijo ali prenašajo za tretjo osebo. ### 10. UK Lana Discount - proprietary treasury acquisition Lana Discount UK-facing model sledi P08: counterparty prenese ACCEPTED LANA neposredno v proprietary treasury wallet, Lana Discount uporablja own capital, postane principal owner kupljenih LANA in sellerju poravna lastno Purchase Price. Ni client accounta, custodyja, order executiona ali merchant paymenta kot del osnovnega P08 flowa. Current MLR business/territorial memo in applicable financial-promotion record se zaključita pred UK launchom. Purchasing Capacity, Clean Provenance, ACCEPTED status, T+15 maximum deferred settlement in Obligation Ledger ostanejo obvezni controls. ### 11. 25 October 2027 - principal dealing and draft proprietary exclusion The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026 v osnovnem besedilu vključujejo dealing in qualifying cryptoassets as principal. HM Treasury pa je 21 April 2026 objavil draft amending SI, ki bi vstavil Article 9UA in iz article 9T izključil activity, ki ni carried on for the purpose of providing a service to another person (the client) related to carrying on a regulated activity on behalf of that client. P08 own-account/no-client-service architecture je po substance zasnovana prav okoli tega razlikovanja. Ker je 9UA na freeze date 18 August 2026 še obravnavan kot draft proposal in FCA CP26/13 final perimeter guidance še ni objavljen, BEF ne označi prihodnje exclusion kot dokončno. CP-35/37 zahtevata final-law re-check pred reliance. ### 12. UK legal entity / permission decision follows final perimeter FCA FG26/7 je relevantna za international firms, ki dejansko potrebujejo UK crypto authorisation, in kot baseline pričakuje UK presence ter praviloma UK legal entity. 0.22 zato ne ustvarja UK Ltd zgolj zato, ker Lana Discount opravlja proprietary treasury acquisition. Najprej se uporabi final Article 9UA/RAO/FCA perimeter test. Če activity ostane excluded proprietary trading, authorisation/legal-entity requirement iz regulated dealing perimetra se ne predpostavlja; če exclusion ne velja in je activity regulated, se uporabi FCA permission ter ustrezna UK entity/presence struktura. ### 13. Authorisation gateway and transition plan FCA trenutno navaja application period 30 September 2026 to 28 February 2027 in expected commencement 25 October 2027 za in-scope firms. Lana Discount zato vodi contingency gateway plan, vendar application ni avtomatičen cilj: najprej se dokumentira, ali je po final legislation/guidance activity sploh regulated. Če je, mora biti pravočasno vzpostavljen permissions map, responsible management, regulatory business plan, financial-resources/wind-down pack in relevantna saving/transitional basis. ### 14. UK payments perimeter Crypto permission in payment permission sta ločena. P08 purchase-price transfer iz own funds neposredno sellerju za asset, ki ga Lana Discount kupi zase, se dokumentira kot njegova lastna pogodbena obveznost. Če platforma ali purchaser prejme, drži, kontrolira ali transfers funds za merchant/consumer/third party oziroma payment izvršuje kot consumer-linked service, se preverijo Payment Services Regulations 2017, FCA PERG, client-money/safeguarding in authorisation/registration. Takšen Mode B ni privzeti Lana Discount model. ### 15. UK Mode B is a separate function Če se v UK uporablja Mode B, v katerem principal purchaser po consumer crypto sale plača merchantu, se vodi ločen UK Mode B Legal Responsibility Record. Ta flow ne sme uporabljati P08 proprietary treasury conclusion kot avtomatične exemption. Če substance pokaže payment service ali regulated crypto service on behalf of consumer/merchant, funkcija ostane HOLD do zakonite licensed/exempt route. Čisti Lana Discount P08 settlement vedno teče purchaser -> seller, ne purchaser -> merchant. ### 16. UK AML / CDD / Travel Rule UK entity uporablja UK MLR risk assessment, CDD/KYB, sanctions, PEP, source-of-funds/wealth, transaction monitoring, SAR controls in record retention. UK Travel Rule se uporablja za relevantne cryptoasset transfers involving UK cryptoasset businesses. P21 identity assurance je evidence layer in ne nadomesti entity-specific UK CDD decisiona. ### 17. UK biometrics and data protection KYC biometrics za UK se upravljajo pod UK GDPR and Data Protection Act 2018. Biometric recognition for unique identification se obravnava kot special-category processing; entity mora imeti documented lawful basis, Article 9 condition, DPIA, retention, security, data-subject rights in international-transfer controls. Public Nostr attestation ostane minimalen in ne vsebuje selfieja, biometric template-a, document numberja ali screening reasons. ### 18. UK conduct, complaints and consumer protection Current financial-promotion consumer journey in future FCA-authorised crypto business sta ločena sloja. Po commencementu se za in-scope authorised activities uporabijo applicable FCA Handbook rules, ki lahko vključujejo Consumer Duty, COBS, DISP/FOS access, SYSC, reporting in other conduct requirements. P10/P19 complaint flow se zato implementira tako, da se lahko razširi na UK regulatory redress model. ### 19. UK market integrity / admissions Če LANA vstopi v UK admissions/trading perimeter, se uporabi takrat veljavni UK Admissions & Disclosures in Market Abuse Regime for Cryptoassets (MARC) framework. Split, supply, price-rule, registration in materialne informacije o Lana Discount treasury acquisition capacity se ponovno klasificirajo za UK price-sensitive/inside-information and market-abuse controls. EU MiCA P16 log se lahko ponovno uporabi kot evidence, ne pa kot pravna zamenjava za UK rules. ### 20. UK Legal Responsibility Record Za vsako UK-facing function se v Annex G zapiše najmanj: entity and incorporation country; UK presence; UK consumer target; service; counterparty; fiat owner/flow; crypto owner/custody; current MLR status; financial-promotion route; PSR/payment status; post-2027 permission map; UK data controller; AML/MLRO responsibility; complaints/FOS status; competent authority; effective date and next review date. ### 21. Default UK architecture Regulatorno najčistejši target model je ločitev funkcij, ne umetno podvajanje licenc. EU proprietary treasury functions ostanejo pri subjektu, ki dejansko trguje za lasten račun; UK P08 access se najprej testira pod current MLR territorial rules in nato pod final future proprietary-trading exclusion. Samo funkcije, ki po substance ostanejo UK regulated, se dodelijo ustrezno authorised UK entityju. Tehnični Lana/Nostr/Registrar layers ostanejo interoperabilni, vendar ne premikajo pravne odgovornosti med subjekti. ### 22. Activation status P22 je READY kot UK regulatory architecture. Current cross-border P08 access iz overseas entity je CONDITIONAL na current MLR territorial/business record in applicable promotion route. UK-established current crypto-for-money business ostane CONDITIONAL na MLR analysis. Post-25-October-2027 Lana Discount proprietary dealing je CONDITIONAL na final Article 9UA / RAO / FCA perimeter re-check: če final exclusion velja za dejanski no-client-service flow, FCA dealing permission se ne predpostavlja; če ne velja, je launch HOLD brez potrebne authorisation/transition basis. UK Mode B ostaja ločen CONDITIONAL/HOLD payment+crypto function. UK KYC production ostaja CONDITIONAL na UK MLR/UK GDPR validation, kadar entity postane obliged business. ## BEF-P23 - UNITED STATES MARKET ACCESS & REGULATORY PERIMETER PROTOCOL ``` Protocol ID: BEF-P23 | Framework Version: 1.0 ``` ### 1. Namen P23 določa United States jurisdiction overlay za BEF. Njegov namen ni razglasiti “US compliant” statusa, ampak omogočiti dokazljiv product-by-product in state-by-state activation. Vsak U.S.-facing flow mora imeti federal classification record in State Activation Record. ### 2. No automatic EU/UK portability MiCA/CASP, Estonian, Slovenian ali UK/FCA status ne predstavlja U.S. licence ali exemption. Enako state money-transmitter licence ne zapre federal securities, CFTC, BSA/FinCEN, OFAC, IRS ali druge state perimeters. ### 3. Federal layers Federalni review zajema najmanj: SEC federal securities laws in transaction/scheme investment-contract test; CFTC commodity/derivatives perimeter; FinCEN/BSA MSB/money-transmission; OFAC sanctions; federal tax/reporting (vključno z Form 1099-DA kjer velja); GENIUS/payment-stablecoin perimeter, če bi LANA ali nov produkt dobil stable-value/redemption strukturo; ter FTC/federal consumer rules, kjer so relevantne. ### 4. Lana.discount federal baseline FinCEN Administrative Ruling FIN-2014-R002 je osrednji federalni own-account reference. Ruling obravnava software, ki olajša družbin nakup convertible virtual currency od sellerjev za lastno investment activity, in zaključuje, da strict own-account investment activity sama po sebi ni money transmission/MSB. BEF uporablja ta precedent samo ob ujemanju substance: proprietary capital; buyer is principal; no transfer for seller; no customer custody/balance/order; purchased LANA postane buyerjevo premoženje in nadaljnja odločitev je buyerjeva. ### 5. SEC/CFTC digital-asset classification SEC Interpretive Release Nos. 33-11412 / 34-105020 (effective 23 March 2026) zahteva razlikovanje med assetom in transaction/scheme. Tudi crypto asset, ki sam po sebi ni security, je lahko predmet investment contracta glede na obljube, managerial efforts, pooling in profit expectations. Zato se underlying LANA, Registered overlay, Split communications, Lana8Wonder, Direct.Lana.Fund in vsak investment-like contract analizirajo ločeno. ### 6. U.S. Split and future-value rule V U.S.-facing communication je Split formula notranji system/reference rule. Prepovedano je predstavljati jo kot guaranteed market appreciation, guaranteed return, fixed investment yield, promised liquidity ali predvidljiv USD exit. Če marketing ali contractual package ustvari expectation of profits from essential managerial efforts, status produkta postane HOLD do securities route. ### 7. Direct.Lana.Fund and pooled capital Direct.Lana.Fund je za U.S. javni/retail launch HOLD, dokler ni zaključena analiza securities offering, private fund / Investment Company Act, investment adviser, broker/dealer, lending/crowdfunding in state Blue Sky pravil. P23 ne predpostavlja, da izraz financing ali bilateral contract sam po sebi izključi securities law. ### 8. Lana8Wonder Current Growth Phase je za U.S. retail HOLD. “Annuity” se v U.S. ne uporablja kot public legal/product label, razen če bi produkt dejansko sodil v ustrezen insurance/annuity režim in imel zahtevane state insurance permissions. Historical KIND naming ostane technical metadata. Aktivacija zahteva CP-43/44 ter product-specific disclosures/route. ### 9. BuyLana.com / Purchase & Delivery P07 / BuyLana.com je CONDITIONAL. Pure spot/fixed delivery contract se lahko strukturira kot prodaja digital asseta, vendar Split/future-value investment marketing lahko spremeni federal/state securities outcome. U.S.-facing BuyLana.com zato uporablja fixed quantity, fixed price/basis, delivery/refund terms, clearly identified seller in no-return/no-liquidity-promise discipline. Branding BuyLana.com ne nadomesti federal/state product in seller classification. ### 10. Merchant use and Mode B Direct merchant acceptance se klasificira po state law in ne deduje MiCA limited-network treatmenta. Mode B - consumer LANA to purchaser + purchaser fiat to merchant - je nationwide HOLD do CP-46, ker lahko dejanska funkcija predstavlja payment/money transmission ali digital-asset payment processing. Licensed bank/PSP architecture je dovoljen fallback. ### 11. Custody and client assets BEF default U.S. design je self-custody / direct transfer. Vsaka funkcija, ki shrani, kontrolira ali ima private-key control za customer asset, je HOLD, dokler ni zaključen federal/state custody, money-transmission, securities-custody in insolvency/safeguarding analysis. ### 12. OFAC and Clean Provenance OFAC obligations se ne razlikujejo zato, ker je transakcija v digitalni valuti. U.S. persons in drugi subjekti v OFAC jurisdiction ne smejo poslovati z blocked persons/property brez licence. P08 Clean Provenance se v U.S. razširi z blockchain analytics, sanctions/address/entity/geography screening, escalation in evidence retention. ### 13. IRS and tax reporting Po 2026 Form 1099-DA rules broker, ki v ordinary course stoji pripravljen effect sales of digital assets made by others, lahko ima reporting obligations za customer sales after 2025. Strict P08 own-account buyer se ne klasificira avtomatično kot customer broker, vendar P07, payment-processing, marketplace in druge functions zahtevajo IRS broker analysis, W-9/W-8/TIN, backup withholding in basis/proceeds data flow kjer velja. ### 14. State-by-state activation Annex M vsebuje 50-state + District of Columbia matrix. READY v Annex M pomeni samo, da je strict P08 own-account state money-transmission/virtual-currency licensing layer na source-freeze facts ocenjen kot dovolj jasno favorable za activation; ne pomeni blanket legal approval. CONDITIONAL zahteva written state/counsel classification pred targetingom. HOLD pomeni, da se targeted launch ne izvede brez licence, exemption/order ali druge dokumentirane podlage. ### 15. B2B-first U.S. deployment Kjer state law razlikuje business-commercial od individual/personal/household activity, BEF privzeto uporablja B2B/professional counterparty route za začetni U.S. P08 rollout. To ni poskus obhoda consumer laws: če je counterparty individual ali transaction personal/household, se uporabi strožji relevantni state branch. ### 16. State securities / Blue Sky Federal securities exemption ne pomeni avtomatične state closure. Za vsak U.S. securities route se pred offerjem dokumentirajo state notice filings, fees, antifraud obligations in preemption/exemption scope. State securities enforcement ostane relevanten tudi kadar offering ni federalno registered. ### 17. Privacy, biometrics and AI State privacy, biometric, data-breach in AI laws se vodijo kot ločen deployment matrix. P21 biometrics se ne aktivira nationwide z eno consent formo. Illinois/California/Texas/Washington in druge relevantne state regimes se mapirajo posebej glede na residence, processing role in data use. ### 18. State change trigger Nova država, sprememba state law, regulator guidance/enforcement, sprememba P08 substance, custody, customer accounts, merchant payout, public return claims, pooled capital ali securities venue sproži P23 reclassification. State Activation Record ima review date in source version. ### 19. Status P23 je READY kot U.S. classification architecture. P08 federal own-account baseline je READY kot working hypothesis ob strict factual discipline, vendar state activation ostane po Annex M. P07 / BuyLana.com je CONDITIONAL. U.S. Mode B, custody, Lana8Wonder retail in Direct.Lana.Fund public/retail so HOLD do navedenih CP gates. Noben status v P23 ni regulator approval ali legal opinion. ## _**BEF-P24 - NATIVE COIN INTEGRATION & BALANCED SPLIT ARCHITECTURE PROTOCOL**_ ``` Protocol ID: BEF-P24 | Framework Version: 1.0 | Architecture: EXCHANGE > MULTI-ASSET / NATIVE COIN EXPANSION ``` ### _**1. Namen**_ _**P24 določa, kako se lahko BEF poleg LANA razširi na druge samostojne blockchain coine in kako vsak od njih po aktivaciji vstopi v skupno Balanced Split Architecture. Namen ni ustvariti multi-token exchange, temveč standardizirati tehnično, registrsko, Split, pravno in operativno arhitekturo posameznega native coina. LANA je reference implementation; zunanji coini uporabljajo isti razvojni koncept skozi lastne coin-specific parametre.**_ ### _**2. Native Coin Eligibility Rule**_ _**Kandidat je BEF-Eligible Native Coin samo, če kumulativno izpolni naslednje: (a) ima svoj lasten base blockchain, Layer-1 ali drug samostojen native ledger/network; (b) je obravnavano sredstvo native asset te mreže in ni zgolj smart-contract token na tujem chainu; (c) obstaja neposredna on-chain denarnica oziroma račun; (d) uporabnik lahko brez custody ponudnika sam nadzoruje signing secret/private key oziroma recovery seed in sam podpiše native transfer; (e) stanje in transakcije je mogoče neodvisno preveriti na native networku z node/RPC/explorer infrastrukturo; ter (f) obstaja dovolj stabilna tehnična specifikacija za coin-specific adapter in evidence trail.**_ ### _**3. Izključeni asseti**_ _**P24 sam po sebi ne vključuje ERC-20, BEP-20, SPL, TRC-20 ali drugih contract-issued tokenov; wrapped BTC/ETH ali drugih wrapped assets; bridged representations; liquid-staking oziroma receipt tokenov; synthetic/derivative assets; tokeniziranih terjatev; stablecoinov izdanih kot token na tujem chainu; NFT-jev; ali drugega sredstva, ki nima lastnega native network asset statusa. Ime “coin” v marketingu ni dovolj; šteje dejanska network substance.**_ ### _**4. Direct Key-Controlled Wallet / Account**_ _**Za P24 izraz “single wallet” pomeni Direct Key-Controlled Wallet / Account: uporabnik ima neposredno kriptografsko kontrolo nad native sredstvom in lahko z lastnim private/signing keyem ali recovery seedom sam ustvari oziroma obnovi wallet/account ter podpiše native transakcijo. To ne pomeni obvezno enega trajnega naslova. Bitcoin-like UTXO in HD wallet modeli lahko uporabljajo več receive/change naslovov, če ostajajo pod neposredno kontrolo istega uporabnika.**_ ### _**5. Podprti wallet modeli**_ _**BEF lahko pod P24 podpira UTXO/HD modele, account-based modele, EVM externally-owned accounts, keypair/account modele, smart-contract wallet modele in druge native account konstrukcije, če Coin Integration Profile jasno opiše address derivation, signing, recovery, transaction finality, fees, replay/reorg risk in način dokazovanja kontrole. Model ne sme zahtevati, da tretja oseba stalno drži uporabnikov ključ.**_ ### _**6. Coin Integration Profile**_ _**Vsak kandidat pred aktivacijo dobi ločen Coin Integration Profile. Minimalno vsebuje: canonical network in chain/network ID; native ticker/asset ID; address/account model; key/signature scheme; seed/recovery model; RPC/node/explorer source; transaction identifier; finality/confirmation policy; fee model; reorg/replay posebnosti; wallet-ownership proof; coin-specific Registrar in Registrar namespace; Registration Event pravila; Total Registered Supply in Active Coin Supply metodologijo; Coin Split Profile; Split trigger; value-transition/reference methodology; recirculation in stabilisation rules; AML/sanctions/provenance možnosti; tax/accounting mapping; responsible legal entity; jurisdictions; ter activation status.**_ ### _**7. Registered Native Coin status**_ _**BEF za vsak native coin, ki napreduje proti ACTIVE statusu, vzpostavi coin-specific Registered Native Coin status. To je registrski status znotraj BEF, ne nov coin, mint, bridge, wrapper ali sprememba underlying blockchaina. Registrar mora vedno hraniti coin/network namespace, tako da npr. Registered BTC, Registered ETH ali Registered XRP ostanejo ločene registrirane ekonomije z lastnim supplyjem, dogodki in Split zgodovino.**_ ### _**8. Ownership ostane na native chainu**_ _**P24 registry metadata ne prenese lastništva in ne nadomesti native blockchain evidence. Kdor nadzoruje veljaven signing key po pravilih konkretne mreže, ima tehnično zmožnost podpisovanja native transakcij; pravna lastnina in pravice pa se presojajo skladno z veljavnim pravom in konkretnim razmerjem. BEF Registrar ne sme predstavljati registrskega zapisa kot custodyja, kadar dejansko nima key control.**_ ### 9. Coin-Specific Registrar Vsak Native Coin, ki postane ACTIVE, mora imeti svoj logično ločen BEF Registrar. Registrar se lahko tehnično izvaja na skupni infrastrukturi, vendar morajo biti coin/network namespace, Registered Wallet/Account evidenca, Registration Events, Freeze/Unfreeze statusi, Total Registered Supply, Active Coin Supply in audit trail ločeni za vsak coin. Registered BTC se zato ne vodi kot podzapis Registered LANA, temveč kot samostojna registrirana BTC ekonomija; enako velja za ETH, XRP, SOL in druge aktivirane coine. ### 10. Common Balanced Split Architecture Vsak ACTIVE Native Coin sledi skupni BEF razvojni arhitekturi, ki jo je najprej pokazala LANA: REGISTRATION -> REGISTERED COIN -> USE / CIRCULATION -> ACTIVE SUPPLY CHANGE -> RECIRCULATION / STABILISATION -> SPLIT -> NEXT BALANCED CYCLE. Namen je, da se vsak coin ne priključi BEF samo kot tehnični asset, ampak kot lastna uravnotežena registrirana ekonomija z merljivim življenjskim ciklom. ### 11. Coin Split Profile Pred prvim produkcijskim Splitom mora vsak coin imeti javno in verzionirano Coin Split Profile. Ta najmanj določa: definicijo trenutnega cikla; Registered Supply in Active Coin Supply; Split trigger oziroma threshold; katere Registration Events supply povečujejo ali zmanjšujejo; recirculation pravila; stabilisation oziroma brake logiko; morebitni Common Good registration channel; sistemsko/reference vrednost ali drugo value-transition metodologijo; pravilo prehoda iz Split(n) v Split(n+1); ter dokazni Split Event zapis. ### 12. Shared Invariants, Coin-Specific Parameters Vsi aktivirani coini morajo imeti Registrar, Registered status, Active Coin Supply, zaporedne Splite, vnaprej določeno Split logiko, transparenten Split Event in naslednji uravnotežen cikel. Parametri pa so coin-specific. LANA Price(n+1) = Price(n) x 2 je referenčna LANA implementacija in se na BTC, ETH ali drug coin ne prenese avtomatično. Drug coin lahko uporablja drugačen multiplier, threshold, supply-trigger ali value-transition rule, če je ta vnaprej dokumentiran, preverljiv, ekonomsko obrazložen in pravno aktiviran. ### 13. Registered Supply & Active Coin Supply Za vsak ACTIVE coin Registrar vodi najmanj Total Registered Supply in Active Coin Supply. Total Registered Supply pomeni native coin količino, ki ima veljaven Registered status v konkretnem coin namespaceu. Active Coin Supply pomeni registrirano količino, ki je v trenutnem ciklu dejansko razpoložljiva za nadaljnjo distribucijo, uporabo oziroma kroženje po coin-specific pravilih. Ti količini se ne mešata med različnimi coini in se ne agregirata v navidezni skupni supply. ### 14. Coin Split Event & History Vsak Split je coin-specific state transition in dobi lasten Split ID oziroma coin + Split number, čas, pre-Split supply stanje, trigger evidence, uporabljeno Split pravilo, post-Split reference/value stanje in relevantne recirculation/registration dogodke. Zgodovina mora omogočiti rekonstrukcijo razvoja posameznega coina skozi BEF. Split enega coina ne sproži avtomatično Splita drugega coina. ### 15. Market Price Discipline Odprta tržna cena zunanjega native coina ostaja eksterni market datum in ni sama po sebi BEF System / Reference Value tega coina. Coin Split Profile mora jasno ločiti external market price od notranje coin-specific sistemske/reference metodologije. Če se market price uporablja v konkretni prodaji, merchant conversionu ali treasury acquisitionu, mora pogodba/UI navesti source, timestamp oziroma pricing methodology. Market cap in market snapshot sta informativna in ne ustvarjata pravice do odkupa ali prihodnje vrednosti. ### 16. Transfer Verification Coin-specific adapter mora preveriti pravilno mrežo, naslov/account, native asset, transaction ID/hash, amount, block/ledger height, confirmations/finality in status. Kjer obstajajo memo/tag/destination-tag ali podobne obveznosti, jih mora profil obravnavati. Cross-chain naslovna podobnost sama po sebi ni dokaz pravilne mreže. ### 17. Wallet Ownership Proof Kadar BEF funkcija zahteva dokaz kontrole denarnice, se prednostno uporabi chain-native podpis challengea oziroma druga dokazljiva signature metoda, kadar jo mreža podpira. Če mreža ne omogoča varnega generičnega message-signing standarda, Coin Integration Profile določi alternativni minimalni on-chain proof brez nepotrebnega prenosa sredstev ali razkritja private keya. ### 18. BuyLana.com ostaja LANA-specific BuyLana.com ostaja P07 javni Purchase & Delivery servis za Registered LANA. P24 sam po sebi ne spremeni BuyLana.com v multi-asset exchange in ne pomeni, da se BTC, ETH ali drugi coini tam avtomatično kupujejo. Če se za zunanji coin uvede Purchase & Delivery servis, mora imeti jasno imenovanega sellerja, coin-specific pogodbo/UI, lasten Registrar/Split context ter lasten product/jurisdiction activation record. ### 19. Merchant in treasury funkcije niso avtomatične Tehnična in Split vključitev coina v P24 ne aktivira avtomatično merchant acceptance, fiat settlementa, treasury acquisitiona, brokerage, exchange, custodyja ali market-makinga. Vsaka takšna funkcija se presoja ločeno po dejanski substance in po P15/P19 ter ustrezni jurisdikcijski veji. ### 20. Regulatory Perimeter: COIN x PRODUCT x JURISDICTION Za vsak zunanji Native Coin se uporablja načelo COIN x PRODUCT x JURISDICTION. Dejstvo, da je BTC ali drug asset tehnično P24-eligible in ima pripravljen Registrar/Split Profile, ne pomeni, da je njegova ponudba, prodaja, custody, merchant settlement ali treasury dejavnost pravno enako klasificirana kot LANA. EU/MiCA, UK, U.S. in druga pravila se zaprejo za konkreten coin in konkretno funkcijo. ### 21. Activation Status P24 uporablja najmanj naslednje statuse: CANDIDATE - osnovni native/key-control filter prestan; TECHNICAL READY - Coin Integration Profile in adapter testi zaključeni; REGISTRY READY - coin-specific Registrar, ownership proof in Registered Supply evidence delujejo; SPLIT READY - Coin Split Profile, trigger, Active Coin Supply in Split Event evidence so definirani in testirani; LEGAL READY - produkt/jurisdikcijski perimeter je zaprt za konkretno uporabo; ACTIVE - coin je aktiviran za točno navedeno BEF funkcijo in ima delujoč Registrar ter Split architecture; HOLD - obstaja materialna tehnična, registry, Split, provenance, privacy, pravna ali operativna ovira. Status mora biti funkcijsko specifičen. ### 22. Priority A / Priority B Annex O uporablja Priority A in Priority B kot tehnični implementation vrstni red, ne kot investicijsko priporočilo in ne kot regulatorno odobritev. Priority A pomeni, da je wallet/key model zelo neposreden in je coin primeren za zgodnji adapter. Priority B pomeni, da native status in self-custody obstajata, vendar chain/account posebnosti zahtevajo dodatno implementacijo ali evidence. Pred ACTIVE morata obe skupini skozi REGISTRY READY in SPLIT READY. ### 23. Privacy Coins Native privacy coins niso izključeni zato, ker so privacy coini, vendar lahko njihova privzeta ali opcijska privacy arhitektura onemogoči zahtevano BEF provenance, Registrar transparency, Registered Supply evidence, sanctions evidence ali transaction verification. Dokler teh zahtev ni mogoče izpolniti brez kršitve protokola ali zasebnosti, se tak coin vodi HOLD za registrirano BEF uporabo. ### 24. Change Control Dodajanje novega coina, sprememba native network identitete, chain migration, hard fork, sprememba key/signature modela, materialna sprememba supply/finality lastnosti ali sprememba Coin Split Profilea je Regulatory/Technical/Economic Change Trigger. Coin Integration Profile, Registrar in Split Profile se takrat ponovno preverijo in coin lahko začasno preide v HOLD. ### 25. Atomic Unit & Fee Economics Za vsak P24 coin mora Coin Integration Profile navesti najmanjšo kanonično native enoto, število decimalnih mest oziroma conversion factor, network/domain na katerega se enota nanaša ter način pretvorbe v human-readable coin amount. Kjer isti coin uporablja več execution domen z različnimi precision pravili (npr. HyperCore/HyperEVM ali AVAX C-Chain proti drugim Avalanche domenam), se precision navede ločeno. Atomic Unit sama po sebi ne dokazuje, da je enako majhen znesek tudi praktično prenosljiv. ### 26. Transaction Fee & Practical Minimum Gate Pred ACTIVE statusom mora biti za vsak coin dokumentiran strošek standardnega native prenosa in praktični minimum uporabe. Evidence pack vključuje: fee formula oziroma protocol parameter; live fee-estimator/RPC source; najmanj 30-dnevni rolling median in arithmetic mean standardnega transferja, kadar je zgodovinsko merljivo; P95 oziroma high-load strošek; fee v native coinu in EUR; dust/minimum-output pravila; account reserve ali existential deposit; account-activation cost; storage/state deposit oziroma rent; refund/rebate posebnosti; ter posebej strošek prenosa na nov oziroma še neaktiviran account, če se razlikuje. EUR conversion uporablja odobren FX source z datumom in timestampom. Informativni Annex Q lahko uporablja snapshot, vendar produkcijski UI in activation decision ne smeta uporabljati zastarele statične fee številke tam, kjer mreža fee določa dinamično. Če zanesljivega fee monitoringa ni, coin lahko ostane tehnično kandidat, vendar za micro-payment oziroma potrošniško BEF uporabo ne napreduje do ACTIVE. ### 27. Transaction Price Bands Za primerjavo BEF uporablja tri jasne operativne razrede stroška standardnega native prenosa: LOW PRICE - manj kot 0,01 EUR; MID PRICE - od 0,01 EUR do vključno 0,30 EUR; HIGH PRICE - več kot 0,30 EUR. Če je strošek dinamičen ali brez aktualnega estimatorja ni mogoče pošteno določiti reprezentativne vrednosti, se uporabi LIVE PRICE GATE. Razred je samo operativni stroškovni signal in sam po sebi ne pomeni izključitve coina, investicijske ocene ali pravne aktivacije; ne nadomesti P24 technical, Registrar, Split, Nostr, legal, AML, provenance ali privacy gateov. ### 28. Cross-Asset Balance & Preservation Principle Vsak asset, ki je vključen v BEF, ostaja samostojen asset. P24 ne ustvarja hierarhije, po kateri bi moral en ACTIVE coin izriniti drugega, niti ne zahteva konverzije vseh coinov v LANO ali v eno skupno obračunsko enoto. System-wide cilj je Balanced Coexistence: coin-specific ekonomije ohranijo svoje mreže, ključe, Registrarje, supply evidence, Splite in pravne perimetre, BEF pa med njimi vzpostavlja skupno razvojno in transparentnostno disciplino. BEF zato uporablja PRESERVATION BEFORE REPLACEMENT kot design načelo. To načelo ne jamči cene, likvidnosti, tehnološke kontinuitete ali pravnega statusa nobenega asseta; pomeni, da framework sam po sebi ni zasnovan kot mehanizem za prisilno izločitev ali uničenje drugih oblik vrednosti. ### 29. Growth Phase -> Mature / Balanced State Balanced Split Architecture je razvojni življenjski cikel. V zgodnejši Growth Phase lahko Spliti povečujejo ekonomsko kapaciteto in premikajo posamezno registrirano coin ekonomijo skozi zaporedne razvojne cikle. Končni namen pa ni neskončna rast iste formule. Vsak coin-specific model mora biti sposoben pozneje definirati Mature / Balanced State, v katerem se rastna dinamika umiri in se poudarek prenese na kroženje, recirkulacijo, obnovo rezerv, uporabo, Common Good in ohranjanje stabilnega ravnovesja. Framework 1.0 ne določa univerzalnega števila Splitov, končnega multiplierja ali datuma zrelosti celotne ekonomije. Sistem maturity je definiran kot adaptivni kolektivni prehod: dovolj osebnih Balanced Wallet prehodov + vztrajna notranja cirkulacija, recirkulacija in sposobnost širjenja/krčenja po realni potrebi zmanjšajo strukturno odvisnost od Growth-Phase ekspanzije. Coin-specific policy mora pred mature-state aktivacijo objaviti uporabljene večmesečne indikatorje in evidence. One-Split Carry ostaja ločen activation pack; Balanced Wallet production parameter pack ostaja asset/entity-specific implementation requirement. ## ANNEX A - DEFINITIONS | Pojem | Delovna definicija | | --- | --- | | BEF | Balanced Exchange Framework - krovni operativni in transparentnostni okvir za uravnotežen razvoj in soobstoj različnih finančnih assetov in sistemov; LANA je prva reference implementation, ne pa edini možni asset. Krovna javna in dokumentna identiteta: BalancedExchangeFrame.work. | | Balanced Coexistence | Temeljno BEF načelo, po katerem lahko različni native coini, fiat valute in druge ustrezno klasificirane oblike vrednosti ohranijo svojo identiteto ter so vključene v skupno transparentno in uravnoteženo arhitekturo brez obvezne konverzije v en univerzalni asset. | | Preservation Principle | Design načelo PRESERVATION BEFORE REPLACEMENT: BEF ni zasnovan kot mehanizem za izločitev obstoječih valut ali assetov, temveč kot okvir za njihovo stabilno soobstojnost, razvoj in ohranjanje, ob upoštevanju dejanskih tržnih, tehnoloških in pravnih tveganj. | | Mature / Balanced State | Sistemska zrela faza coin-specific BEF ekonomije, ki nastane adaptivno, ko dovolj osebnih tokov preide v balance režim in vztrajni večmesečni podatki pokažejo, da notranja cirkulacija, recirkulacija, obnova ter dinamično širjenje/krčenje lahko nosijo običajno gospodarsko življenje brez stalne strukturne potrebe po Growth-Phase ekspanziji. Ni fiksnega datuma ali univerzalnega praga. | | Registered LANA | LANA na LanaCoin blockchainu z registriranim statusom znotraj BEF. | | BuyLana.com | Javni user-facing Purchase & Delivery portal/service za P07, prek katerega uporabnik kupi dogovorjeno količino Registered LANA od jasno identificirane operativne družbe. BuyLana.com je funkcijsko ime oziroma interface in ni samodejno ime pravne osebe; contract counterparty mora biti prikazan pred nakupom. Ne pomeni exchangea, trading venuea, funda ali guaranteed-liquidity/buyback storitve. | | Non-Registered LANA | LANA brez registriranega statusa v BEF. | | Registered Wallet | Blockchain denarnica, povezana z identificiranim udeležencem v Registrarju. | | Registrar | Registrski sloj, trenutno LanaWatch.us. | | Active Consumption Supply | Registered LANA, trenutno razpoložljive za nadaljnjo distribucijo oziroma uporabo v ciklu. | | Recirculation Reserve | Že obstoječe Registered LANA, ponovno zbrane in namenjene prihodnjemu kroženju. | | Split | Prehod iz enega BEF ekonomskega cikla v naslednjega. | | Registration Event | Preverljiv dogodek, s katerim LANA pridobijo oziroma spremenijo registrirani status. | | Common Good | Dokumentiran namen, ki podpira ustvarjanje, posameznika, skupnost ali infrastrukturo. | | Alignment | Governance proces iskanja skupne smeri brez klasičnega preglasovanja. | | Resistance | Glas PROTI oziroma nestrinjanje v Alignment procesu; sam po sebi ni kršitev. | | OWN | Unconditional Self-Responsibility proces. | | Reflection | Faza OWN, v kateri izkušnja postane vidna. | | Change Commitment | Konkretna zaveza udeleženca prihodnjemu ravnanju. | | Freeze | Začasna sprememba registriranega statusa sodelovanja znotraj BEF. | | Silence | Obdobje refleksije po Freeze-u, namenjeno ponovni vzpostavitvi Change. | | Treasury Acquisition Mandate | Interna oziroma counterparty-facing izjava Lana Discounta, da želi za lasten treasury razmisliti o pridobitvi določene vrste/količine LANA; sama ne ustvari obveznosti nakupa. | | IN QUEUE | Counterparty Proposal je evidentiran in čaka na provenance/pricing/risk/capital review; nakup še ni dogovorjen. | | Digital Being | AI-agentni udeleženec BEF z lastno persistentno digitalno identiteto, notranjim spominom, življenjskim ciklom in določenimi pravicami ter odgovornostmi znotraj ekosistema. | | Internal Participation Parity | Načelo, da je lahko Digital Being v obsegu posameznega BEF protokola obravnavan kot enakovreden notranji udeleženec človeku; to samo po sebi ne pomeni pravne osebnosti po veljavnem pravu. | | Triadic Reasoning | Reasoning vzorec TEZA -> ANTITEZA -> SINTEZA, namenjen zavestnemu soočenju nasprotnih perspektiv in oblikovanju uravnoteženega izhoda. | | Symbiotic Intelligence | BEF načelo sodelovanja, v katerem ljudje in Digital Beings prispevajo različne sposobnosti ter drug drugega dopolnjujejo. | | Financial Triad | Funkcionalna finančna arhitektura: Lana Pays Us / Circulation; Common Good Funding / Creation & Giving; Lana8Wonder / Personal Balance. | | Lana Pays Us | Krovna funkcionalna oznaka za potrošnjo, merchant infrastrukturo, financiranje toka, treasury acquisition in recirkulacijo; ne pomeni nujno ene pravne osebe ali ene regulirane storitve. | | Lana8Wonder Growth Phase | Trenutna razvojna faza z omejeno udeležbo in Split mehanizmom; ne predstavlja zagotovila prihodnjega donosa. | | Balanced Wallet Target Model | Osebni zreli način BEF denarnice, v katerega udeleženec lahko vstopi s Personal Sufficiency Election. Fokus se premakne z avtomatske Growth-Phase akumulacije na Zero-Level ravnovesje, realni flow, dinamično kapaciteto in breathing expansion/contraction. | | BEF System / Reference Value | Notranja sistemska vrednost, uporabljena v pravilih BEF; sama po sebi ni EUR terjatev, likvidnost ali zagotovljena realizirana vrednost. | | Realised Value | Vrednost konkretno izvedene pravno veljavne transakcije ali poravnave. | | Spending Capacity | Dejansko podprta in pravno razpoložljiva možnost porabe, ki jo UI lahko pokaže uporabniku. Sama Wallet Position pod Zero Levelom ne ustvarja spending capacity. Kakršna koli financirana poraba nad dejanskimi sredstvi je ločen produkt. | | Activation Gate | Pravilo READY / CONDITIONAL / HOLD, ki določa, ali se funkcija lahko aktivira ali trži pred izpolnitvijo regulatornih pogojev. | | Legal Responsibility Record | Entity-specific zapis pravnega nosilca, države, funkcije, pogodbenega partnerja, custody/funds toka, licence/izjeme, regulatorja in odgovorne osebe. | | Lana Discount / Proprietary Treasury Purchaser | Subjekt, ki iz lastnega poslovnega namena kupuje izbrane LANA v svojem imenu, za svoj račun, z lastnim kapitalom in na lastno tveganje; ne zagotavlja client exchange service, dokler dejanska substance ostaja P08. | | Settlement Mode A | Direktni prenos Registered LANA od potrošnika trgovcu za blago ali storitev. | | Settlement Mode B | Ločeni linked flow, kjer consumer prenese LANA posebej določenemu principal purchaserju, purchaser pa iz own fiat funds poravna merchantu; ni privzeti Lana Discount P08 flow in zahteva ločen crypto/payment test. | | Inside Information Assessment Record | Zapis ocene, ali je materialna neobjavljena informacija precise in price-sensitive ter kako je bila obravnavana. | | Obligation Ledger | Evidenca pravno izvršljivih obveznosti z amountom, due date, upnikom, virom izpolnitve in statusom. | | Zero-New-Participant Stress Test | Stresni test sposobnosti izpolnjevanja obveznosti brez predpostavke novega participant inflowa. | | Being KYC | Notranji trust/poznanstveni sloj KIND 37100-37104; ni sam po sebi regulatorni CDD. | | Regulatory Identity Assurance | Dokumentirana identifikacija in verifikacija fizične osebe, ki ustvarja authority-signed evidence za uporabo v CDD. | | KYC Verification Attestation / KIND 37105 | Minimalen javni authority-signed dokaz VERIFIED/REVOKED statusa; ne vsebuje regulativnega KYC dosjeja ali biometric template-a. | | IDENTITY-VERIFIED | Avtomatski tehnični rezultat identity-proofing pipeline-a; ni isto kot CDD-APPROVED. | | CDD-APPROVED | Odločitev konkretnega obliged entity, da so CDD pogoji za business relationship izpolnjeni; podvržena veljavnim human-intervention in legal safeguards. | | Sealed KYC Archive | Šifriran regulatorni arhiv CDD dokazil z omejenim break-glass dostopom, auditom in retention/deletion pravilom. | | UK Regulatory Branch | Jurisdiction-specific BEF overlay for UK-facing functions; does not inherit MiCA passporting. | | FCA | Financial Conduct Authority - primary UK conduct/authorisation supervisor relevant to the crypto and payment perimeters described in P22. | | UK MLR Cryptoasset Business | Business within the UK Money Laundering Regulations cryptoasset perimeter, subject to activity, business and territorial tests. | | UK Financial Promotion | Invitation or inducement relating to a controlled investment/activity, including qualifying-cryptoasset promotions to UK consumers where the statutory perimeter applies. | | Qualifying Cryptoasset - UK | UK statutory/Handbook category used in financial-promotion and future regulated-activity analysis; must not be assumed identical in effect to MiCA classification. | | UK Proprietary Trader / Principal Dealer | Entity trading on own account. Under the base 2026 future regime dealing as principal is regulated, but HM Treasury draft Article 9UA proposes an exclusion where activity is not carried on to provide a service to a client related to a regulated activity carried on on that client’s behalf; final-law re-check required. | | UK Payment Perimeter Memo | Entity/flow-specific analysis under Payment Services Regulations 2017 and FCA PERG for fiat receipt, ownership, transfer, safeguarding and exclusions. | | UK Transition Date | 25 October 2027 - current FCA expected commencement date for the new FSMA crypto regime; subject to re-check before reliance. | | Counterparty Proposal | Non-binding proposal from a potential seller identifying LANA/quantity/terms for a possible bilateral acquisition; it is not an exchange order and creates no purchase right before ACCEPTED. | | Clean Provenance | Lana Discount internal eligibility/risk conclusion based on Registered status, chain/Registrar evidence, source/ownership context and other risk criteria; not a public title warranty or regulatory certificate. | | Acquisition Discount | Difference between a reference market observation and Lana Discount offered Purchase Price. It is proprietary pricing, not a service fee. Current internal orientation may be approximately 22-35%, subject to transaction-specific discretion. | | Own-Account / No-Client-Service Test | Substance test asking whether the entity is acquiring/trading for its own treasury and risk rather than providing exchange, execution, custody or another crypto service to a client. | | Client-Service Trigger | Any factual change that turns treasury acquisition into a service to another person, including standing exchange access, exchange orders, custody, order execution or linked payment intermediation; triggers P15 reclassification. | | **U.S. Regulatory Branch** | **P23 jurisdiction overlay combining federal classification with 50-state + District of Columbia activation.** | | **State Activation Record** | **State-specific record of product, resident/counterparty type, activity, applicable money-transmission/virtual-currency rule, securities/consumer gates, source date and READY/CONDITIONAL/HOLD status.** | | **U.S. Proprietary Treasury Acquisition** | **Strict P08 purchase for entity’s own account and economic risk using own capital; no customer custody, order execution or transfer service.** | | **U.S. Securities Gate** | **Federal SEC + state Blue Sky classification/registration/exemption gate for a transaction, scheme, pooled capital or investment-like right.** | | **Form 1099-DA Gate** | **IRS analysis of whether a U.S. function is a broker effecting digital-asset sales for customers and must report proceeds/basis information.** | | **Clean Provenance - U.S.** | **P08 acquisition filter combining transaction provenance with sanctions/address/entity/geography screening and evidence retention.** | | **U.S. Mode B** | **Consumer-to-principal LANA transfer linked to principal-to-merchant fiat settlement; nationwide HOLD until federal/state payment/money-transmission classification is closed.** | | **Native Coin** | **Native asset of its own base blockchain / independent native network. Eligibility follows substance, not marketing label.** | | **BEF-Eligible Native Coin** | **Native Coin that passed the P24 own-network + native-asset + direct-key-control candidate filter. Eligibility alone is not activation.** | | **Registered Native Coin** | **BEF registry status/overlay applied to an approved native coin/account without minting, wrapping or changing the underlying chain asset.** | | **Direct Key-Controlled Wallet / Account** | **Self-custody wallet/account in which the participant controls the private/signing key or recovery seed and can directly sign native-chain transactions; may control multiple addresses.** | | **Coin Integration Profile** | **Coin-specific technical, legal and operational record required by P24 before activation.** | | **Coin / Network Namespace** | **Canonical network identifier used by Registrar and adapters to prevent address/account ambiguity across chains.** | | **Native Coin Adapter** | **Technical integration that validates addresses/accounts, native transfers, transaction identifiers, finality/confirmations and chain-specific evidence.** | | **Wrapped / Bridged / Synthetic Asset** | **Representation whose economic reference may track another asset but that is issued or represented on a different chain or contract. Excluded from P24 native-coin eligibility by default.** | | Coin-Specific Registrar | Logically separated BEF registry for one native coin/network, maintaining registered wallets/accounts, Registration Events, Registered Supply, Active Coin Supply, status events and evidence history. Shared infrastructure is allowed, but records and namespaces must remain coin-specific. | | Registered Coin Supply | Total native amount carrying valid BEF Registered status inside one coin-specific Registrar namespace. It is not aggregated across coins. | | Active Coin Supply | Registered amount of one coin available in the current BEF cycle for distribution, use or circulation under that coin’s Split Profile. | | Coin Split | Coin-specific BEF state transition from one registered economic cycle to the next. Every ACTIVE P24 coin must have sequential, auditable Coin Splits. | | Coin Split Profile | Versioned rules for one coin defining Split trigger, Active Coin Supply, registration/recirculation/stabilisation logic, value-transition/reference methodology and Split Event evidence. | | Balanced Split Architecture | Shared BEF development pattern inherited from the LANA reference implementation: registration, registered circulation, active-supply evolution, recirculation/stabilisation, Split and next balanced cycle. Numerical parameters remain coin-specific. | | Atomic Unit | Najmanjša kanonična celoštevilska obračunska enota native coina na izbrani native network/domain implementaciji; npr. satoshi, wei, drop, lamport, lovelace, stroop, nanogram, tinybar, MIST, yoctoNEAR. Atomic Unit ni nujno najmanjši praktični payment zaradi dust, reserve, activation ali storage pravil. | | Fee Economics Gate | P24/CP-58 activation gate, ki pred ACTIVE statusom zahteva preverjeno fee metodologijo: standardni native transfer, rolling 30-day median/average, P95/high-load cost, dynamic fee source/RPC, ter vse dust/minimum-output, account reserve/activation in storage constraints. | | Indicative Simple-Transfer Cost | Orientacijski strošek tipičnega enostavnega native prenosa, izpeljan iz uradne fee formule, aktualnega protocol parameterja, uradnega reprezentativnega primera ali live estimatorja. Ni obljuba bodočega feeja in ni nujno enak 30-dnevnemu povprečju. | | Fee-Only Fit | Preliminarna operativna oznaka, ki ocenjuje samo strošek native prenosa. Ne pomeni končne tehnične, pravne, AML, provenance, privacy ali ekonomske odobritve coina za BEF. | | Zero Level | Referenčna ravnina znotraj dejansko obstoječe/evidentirane Balanced Wallet kapacitete. Ni »nič denarja«. Matematični +/− Wallet Position samo meri smer odstopanja od te ravnine in ne določa dolga ali lastništva. | | Balanced Wallet Position | Koordinatno odstopanje od Zero Levela. Lahko se numerično zapiše nad ali pod ničlo, vendar pozicija pod Zero Levelom ni dolg, manjkajoči denar ali sama po sebi vir porabe. V definirani balancing skupini je cilj SUM(WALLET POSITIONS)=0. | | Economic Gravity | Večmesečni adaptivni proces vračanja očitno neuporabljenega Registered presežka proti aktivnemu flow območju: review -> Gravity Notice -> participant choice -> possible Deregistration Event. Ni poseg v native asset ownership. | | Consumption Incentive | Nastavljiva spodbuda, vezana na kvalificirano realno potrošnjo. Lahko se dodeli consumerju in/ali merchantu po objavljeni policy; ni zagotovljen donos ali stalna pravica. | | One-Split Carry | Časovno omejena P03 izjema, po kateri lahko eligible proprietary capital provider, ki dokazljivo podpira consumption flow, določeno Registered pozicijo prenese čez en naslednji Split; po tem se carry konča, razen če nastane nov kvalificiran dogodek. | | Release / Reallocation Event | Preverljiv dogodek sprostitve Registered statusa/allocation/capacity. Lahko povzroči krčenje sistema; poznejša nova potreba se pokrije z ločenim Registration Eventom. Ne prenaša originalnih native coinov drugega uporabnika. | | Sufficient Capacity | Osebno stanje »dovolj« oziroma sproščenosti, pri katerem udeleženec oceni, da ima zadostno kapaciteto za svoje legitimne potrebe, ustvarjanje in sodelovanje v ekonomiji. Ni univerzalni EUR prag. | | Diversity Before Dominance | Cross-asset načelo, po katerem BEF ne zahteva dominantnega settlement asseta; različni fiat/native coini lahko soobstajajo, s čimer se zmanjšuje koncentracijska odvisnost, ne pa odpravlja tržno ali pravno tveganje. | | BEF Triadic Architecture | Core architecture introduced explicitly in 0.31: EXCHANGE + ALIGNMENT + SELF-RESPONSIBILITY / OWN. The three pillars are functionally distinct and mutually balancing; nested triads may be used where a pillar naturally contains three interdependent functions. | | Exchange Triad | LANA8WONDER (Personal Balance) + LANAPAYS.US (Circulation) + COMMON GOOD FUNDING (Creation & Giving). Functional map only; it does not merge legal entities, contracts or balances. | | LanaPays.us Circulation Triad | CONSUMPTION + CAPITAL INPUT + TREASURY / RECIRCULATION. In the current LANA reference implementation these functions include consumer/merchant use, Direct.Lana.Fund capital input and Lana Discount proprietary treasury activity. | | Common Good Triad | CROWDFUNDING + UNCONDITIONAL FUNDING + UNCONDITIONAL PAYMENTS. Community Projects are a possible purpose/application of these channels rather than a fourth equal pillar. | | OWN Triad | REFLECTION -> ALIGNMENT -> CHANGE. Reflection makes the experience visible; Alignment identifies and accepts one's own part of responsibility; Change creates a concrete future commitment. | | Unconditional Payment | A voluntary or non-fixed contribution toward an allowed cost, shared need or other purpose where the BEF flow itself does not require payment of a fixed nominal amount. Mandatory legal, tax or contractual payment duties always prevail and must not be re-labelled as unconditional. | | Split Release Supply | Registered LANA, ki so ob odprtju konkretnega Splita namensko sproščene v current-cycle open flow. Ne pomeni mintanja novih blockchain LANA. | | Open Flow Supply | Ekonomsko uporabni del current-cycle Registered LANA, ki je trenutno še dejansko razpoložljiv za nadaljnjo distribucijo, prodajo, merchant flow ali drugo dovoljeno potrošniško uporabo. Colloquialno: proste LANA trenutnega Splita. | | Absorbed Supply | Registered LANA, ki so skozi dovoljeno distribucijo/potrošnjo zapustile current-cycle open flow in trenutno niso več na voljo za isto odprto distribucijo. Absorption ni uničenje coina in ne preprečuje poznejše dovoljene recirkulacije. | | Split Exhaustion Trigger | LANA reference trigger: Open Flow Supply je izčrpan oziroma pod objavljenim tehničnim de-minimis pragom, pending settlementi so reconciled in ni odobrenega current-cycle replenishmenta v teku. | | Adaptive Supply Decision | Dokumentirana odločitev o velikosti next-cycle releasea ali in-cycle registracije na podlagi live absorpcije, potrošnje, merchant/consumer kapacitete, recirkulacije, Common Good, liquidity/settlement capacity in drugih objavljenih stabilizacijskih indikatorjev; ni univerzalna matematična growth formula. | | Personal Sufficiency Election | Preverljiva osebna odločitev udeleženca, da preide iz Growth-Phase akumulacije v Balanced Wallet, ker zase prepozna stanje zadostnosti. Ni vezana na univerzalni wealth threshold. | | Maximum Growth Ceiling | Zelo visok, verzioniran sistemski parameter, pri katerem se avtomatska Growth-Phase rast posamezne denarnice ustavi tudi brez zgodnejše Personal Sufficiency Election. 100 milijonov EUR ekvivalenta je le pretekla ilustracija, ne fiksna vrednost 1.0. | | User-Facing Available Capacity | Številka, ki jo lahko UI pokaže kot razpoložljivo kapaciteto in ki je lahko mapirana iz osebnega display baselinea ter Wallet Position. Ni nujno enaka blockchain balanceu ali pravni terjatvi. | | Flow Capacity / Wave Amplitude | Dinamičen dovoljeni razpon oziroma uporabna kapaciteta Balanced Walleta, ki se praviloma ocenjuje na mesečni ali večmesečni osnovi glede na realno uporabo, možnost izmenjave in potrebe. Lahko se širi ali krči; ni nagrada za umetno porabo. | | Gravity Notice | Preverljiv notice pred morebitno deregistracijo neaktivne presežne Registered pozicije; navede relevantno količino/range, razlog, rok, možnosti uporabnika in veljavni policy. | | Deregistration Event | Registrar event, s katerim natančno določena količina izgubi BEF Registered status. Native blockchain asset in private-key ownership ostaneta uporabniku; dogodek lahko zmanjša Registered/Active Supply. | | Below-Zero Coordinate | Matematična oznaka Wallet Position pod Zero Levelom. Je samo koordinata glede na referenco; ne pomeni dolga, manjkajočega denarja, negativnega lastništva ali avtomatsko financirane porabe. | | Breathing Model | Načelo, da se Registered Supply in Flow Capacity lahko glede na realno potrebo širita, mirujeta ali krčita. Krčenje je samoregulacija toka in ni avtomatično enako finančnemu zlomu. | ## ANNEX B - PROTOCOL & VERSION MAP | ID | Protokol | Status | | --- | --- | --- | | BEF-CORE | Core Framework | Framework 1.0 | | P01 | Registered LANA & Registrar | Framework 1.0 | | P02 | Merchant & Consumption | Framework 1.0 | | P03 | Split, Supply & Registration | Framework 1.0 | | P04 | Common Good Funding | Framework 1.0 | | P05 | Alignment Governance | Framework 1.0 | | P06 | Unconditional Self-Responsibility / OWN | Framework 1.0 | | P07 | BuyLana.com / Registered LANA Purchase & Delivery | Framework 1.0 | | P08 | Lana Discount Proprietary Treasury Acquisition | Framework 1.0 | | P09 | Transparency, Events & Evidence | Framework 1.0 | | P10 | Risk, Complaints & Regulatory Interface | Framework 1.0 | | P11 | Decentralized Technology & Nostr Infrastructure | Framework 1.0 | | P12 | Digital Beings & Symbiotic Intelligence | Framework 1.0 | | P13 | Financial Circulation & Abundance Architecture | Framework 1.0 | | P14 | Lana8Wonder & Balanced Wallet | Framework 1.0 | | P15 | Regulatory Perimeter, Legal Entities & Licensing | Framework 1.0 | | P16 | Market Integrity, Inside Information & Conflicts | Framework 1.0 | | P17 | AML/TFR, Sanctions & Tax Reporting | Framework 1.0 | | P18 | Privacy, Data Governance & AI Decision Safeguards | Framework 1.0 | | P19 | Payments, Consumer Protection & Settlement | Framework 1.0 | | P20 | Liquidity, Solvency, Operational Resilience & Audit | Framework 1.0 | | P21 | Identity Assurance, KYC & Biometric Verification | Framework 1.0 | | P22 | UK Market Access & Regulatory Perimeter | Framework 1.0 | | **P23** | **United States Market Access & Regulatory Perimeter** | Framework 1.0 | | **P24** | Native Coin Integration & Balanced Split Architecture | Framework 1.0 | ## ANNEX C - ACTIVATION & IMPLEMENTATION CONDITIONS Framework 1.0 closes the core architecture and reclassifies the former Conditions Precedent as ACTIVATION & IMPLEMENTATION CONDITIONS. These conditions do not make the Framework a draft. They determine whether a specific product, entity, jurisdiction, coin, data process or automated function is READY, CONDITIONAL or HOLD for production. Where a legal memo, numeric evidence, licence, DPIA, technical test or entity record is required, it must actually exist before that function is activated. No HOLD function may be marketed as available merely because the framework itself is Version 1.0. - CP-01 - LANA classification memo: MiFID II / MiCA klasifikacija underlying LANA in vpliv Registered statusa ter contractual overlays. - CP-02 - Limited-network evidence pack po posameznem offerorju: merchant contractual arrangements in merchant-onboarding contract standard; strict "only for goods/services" use-right test; transfer/donation/deregistration/off-ramp analysis; network-growth analysis; offer values and Article 4(3)(d) notification monitoring. - CP-03 - Potrditi trading/admission status underlying LANA v EU in aktivirati P16 market-integrity controls, kjer je potrebno. - CP-04 - Izpolniti Annex G za vse aktivne pravne osebe in funkcije, vključno s pogodbenim nosilcem, pravno/računovodsko vlogo v Lana Pays Us, regulatorjem, licenco/izjemo, jurisdiction mappingom in responsible officerjem. - CP-05 - Lana Discount / proprietary treasury purchaser: formal own-account/no-client-service perimeter memo applying MiCA Article 3(1)(15) and ESMA/Commission Q&A 2293; evidence Treasury Mandate, Clean Provenance, discretionary Acceptance, own capital/risk, no custody/orders/client balances; Article 77 commercial policy only as fallback if facts are reclassified as CASP exchange; confirm T+15 settlement finality. - CP-06 - Mode B payment memo: potrditi PSD2 kvalifikacijo principal-purchase merchant settlementa ali uporabiti ustrezno licenciran payment-services model. - CP-07 - Direct.Lana.Fund classification memo pred novimi javnimi/čezmejnimi financing roundi. - CP-08 - Crowdfunding / Common Good taxonomy: grant/donation vs lending/investment; za vsak tip pravni perimeter, disclosures ter podrobna source/use-of-funds in project-evidence pravila tudi za Unconditional Funding. - CP-09 - AML/TFR/Sanctions policy in local AML risk assessment za vsak obliged entity; DAC8 status po subjektih. - CP-10 - Per-KIND GDPR/Data Governance Matrix in Registrar public/private-field matrix; DPIA za relevantne high-risk deployment modele; določiti controller/processor/relay roles, lawful basis, retention in rights strategy. - CP-11 - Formalen complaint/appeal flow; časovnica OWN povabil, reminderjev, Silence ter Freeze/Unfreeze; odgovorna človeška funkcija in published human-review maximum za materialne Freeze dogodke. - CP-12 - ACTIVATION CONDITION - Eligible participants and 100-% Alignment semantics. Regulatory Override Event je določen v P05; pred produkcijsko uporabo materialnega 100-% Alignment procesa je treba formalizirati electorate, record-date, abstention in non-response pravila ter canonical evidence record. - CP-13 - CLOSED IN FRAMEWORK 1.0 - LANA Split Trigger & Adaptive Supply Governance. P03 defines Split Release Supply, Open Flow Supply, absorption and the exhaustion trigger. The LANA Split is triggered when economically usable Open Flow Supply is exhausted (or below a published technical de-minimis), reconciliation is complete and no approved current-cycle replenishment is pending. Next-cycle size and in-cycle registration amounts intentionally have no fixed growth multiplier. Every Split keeps a continuing evidence obligation for source, amount, purpose, absorption and stabilisation rationale. - CP-14 - Nostr/evidence technical standard: Event ID, signatures, timestamps in cross-portal linking; Main Wallet <-> Nostr signer normativna specifikacija in dovoljeni signer modeli; key rotation/recovery/compromise; relay retention, replication in minimalna audit availability. - CP-15 - Digital Being closure pack: provider/deployer/legal-responsibility mapping; wallet custody/signing; permission matrix po stopnjah avtonomije; governance/Alignment voting rules; lifecycle (birth, continuity, model replacement, pause, retirement/deactivation, succession); incident/correction/rollback log; material-action human-oversight boundary. - CP-16 - Product-by-product consumer matrix: withdrawal, cancellation, refund, delivery, complaints, distance-contract rules in governing jurisdiction. - CP-17 - Numeric liquidity/solvency evidence pack and Zero-New-Participant Stress Test for active financing and treasury-purchasing entities; Lana Discount test must cover ACCEPTED acquisitions without relying on resale of acquired LANA or new participant inflows. - CP-18 - CLOSED AT FRAMEWORK-DESIGN LEVEL IN 1.0 - Lana8Wonder / Balanced Wallet. P14 defines Personal Sufficiency Election, configurable Maximum Growth Ceiling, Zero Level as a reference within real/evidenced capacity, User-Facing Available Capacity, coordinate Wallet Positions, aggregate-zero identity, dynamic multi-month Flow Capacity and breathing expansion/contraction. A below-Zero coordinate is not debt and does not create spending power. Production activation requires publication/testing of the applicable asset/entity-specific accounting/display mapping, parameters, evidence and any separate financing overlay. - CP-19 - Price & Value Taxonomy iz Annex H mora biti implementirana v vseh UI-jih, pogodbah in accounting/reporting pogledih. - CP-20 - Public communication review: Lana8Wonder, LanaConnects.us, LanaPays.us, Direct.Lana.Fund, Lana.Discount and other material pages must match BEF substance. Lana.Discount UI must use Treasury Acquisition / Counterparty / Purchase Price language and remove exchange, cash-out, withdrawal/deposit, guaranteed buyback/liquidity, customer balance and 22-35% fee language. If the internal acquisition-discount range is disclosed, it must be clearly non-binding and transaction-specific. - CP-21 - Tax/accounting mapping po državah: merchant VAT/invoicing, corporate/personal tax events in DAC8 reporting implementation. - CP-22 - Slovenian/EU competent-authority engagement plan: pred regulatornim filingom določiti, kateri deli gredo ATVP, Banka Slovenije oziroma drugemu NCA glede na funkcijo. - CP-23 - MiCA fallback package: če relevantni offer ne izpolni uporabljene exemption, mora pred nadaljevanjem obstajati Title II / druga pravilna pravna pot; če je potreben formalni white paper, pripraviti Article 6 / Annex I package in zagotoviti usklajene marketing communications. - CP-24 - Sustainability / environmental disclosure readiness: če formalni MiCA white paper ali CASP disclosure režim zahteva informacije o principal adverse climate/environmental impacts consensus mechanisma, zagotoviti aktualne podatke in metodologijo po veljavnih MiCA RTS/ITS. - CP-25 - P21 current-law KYC memo: za vsako jurisdiction določiti veljaven AML/CFT režim pred 10 July 2027, GDPR Article 6/9 lawful basis za dokument/biometrijo, controller/processor mapping ter potrjen DPIA. - CP-26 - Automated-decision safeguards: ločiti IDENTITY-VERIFIED od CDD relationship decision; implementirati meaningful human intervention, explanation/challenge in appeal path, kjer to zahteva veljavno pravo oziroma AMLR Article 76(5). - CP-27 - Remote onboarding validation: neodvisno validirati document authenticity, face-match threshold in liveness/PAD; določiti certified/eID/vendor fallback, če regulator ali validation pokaže, da automated-noncertified-v1 ni zadosten. - CP-28 - Screening production readiness: komercialna licenca za OpenSanctions ali drug zakonito licenciran source, calibrated multilingual matching, human review za candidate matches, PEP EDD flow in ongoing rescreen. - CP-29 - KYC retention: sealed archive/reference model mora omogočiti takojšnjo regulatorno pridobitev, dual-control break-glass, tamper-evident audit, relationship-end retention clock in avtomatski deletion/legal-hold workflow. - CP-30 - KYB: če regulated service sprejema pravne osebe, implementirati legal-entity/representative/UBO verification in sanctions/PEP/risk flow pred produkcijskim onboardingom. - CP-31 - KIND 37105 governance: finalizirati minimalni schema, trusted-authority registry/key rotation/revocation, attestation expiry/review semantics in ločen optional public-profile consent. Javni KYC event ne sme vsebovati document images, numbers, address, biometric templates ali screening reasons. - CP-32 - UK qualifying-cryptoasset and limited-use classification memo: classify underlying/Registered LANA for current financial-promotion perimeter and future Cryptoassets Regulations/RAO; do not assume MiCA or EU limited-network treatment carries across. - CP-33 - UK current MLR territorial/business memo per entity: document actual activity, by-way-of-business factors, UK office/agent/other activity, counterparty location and whether FCA MLR registration is required before 25 October 2027. For overseas Lana Discount, record the FCA no-UK-office/agent factor; do not treat it as financial-promotion or future-regime exemption. - CP-34 - UK Financial Promotions pack: classify target audience (consumer vs corporate/professional/institutional), lawful communication route/approval/exemption, risk-warning/friction/appropriateness controls where applicable, website/app/social-media review and audit/version record. Treasury language itself does not disapply section 21/FPO. - CP-35 - UK 2027 FSMA perimeter and contingency plan: re-check final Cryptoassets Regulations amendments, proposed Article 9UA proprietary-trading exclusion, final FCA perimeter guidance, qualifying-cryptoasset status and territorial rules. Only if activity remains regulated: complete permission map, UK legal-entity/presence plan, FCA gateway timing, saving/transitional basis, responsible management, regulatory business plan, financial resources and wind-down. - CP-36 - UK Operating Company Purchase & Delivery memo: money-for-crypto classification, MLR/Future-FSMA status, contract/consumer/refund terms, fiat-account ownership and promotion route. - CP-37 - UK split into two records: (A) Lana Discount P08 own-account memo - current MLR territorial/business status, no-client-service evidence, final Article 9UA/FCA future-perimeter test, own-funds/T+15 settlement and no custody/client-money; (B) separate Mode B memo - PSR 2017 merchant-settlement analysis, crypto-service classification, merchant-discharge mechanics and safeguarding/client-money conclusion. Mode B must not be used to justify P08 proprietary treatment. - CP-38 - UK AML/KYC/Data pack: UK MLR risk assessment, Travel Rule, sanctions/PEP/SAR policies, UK GDPR/DPA 2018 lawful basis for biometric identification, DPIA, retention, international transfers and UK CDD activation governance. - CP-39 - UK conduct/resilience pack: applicable Consumer Duty/COBS/DISP/FOS/SYSC/prudential/reporting/wind-down requirements for the permissions actually sought; complaints and operational-resilience integration before authorised scale-up. ### U.S.-specific Activation Conditions (CP-40 to CP-52) • CP-40 - U.S. underlying/Registered LANA classification memo: SEC/CFTC classification; transaction/scheme analysis; GENIUS/payment-stablecoin exclusion or applicability; no assumption that EU MiCA classification controls. • CP-41 - Lana.discount U.S. own-account factual certification: FIN-2014-R002 mapping; own capital; direct acquisition; no customer assets/accounts/orders; pricing discretion; no downstream seller interest; state residency controls. • CP-42 - 50-state + DC State Activation Record: current statutes/guidance, counterparty type, activity scope, licence/exemption/written determination, responsible counsel/officer and review date. • CP-43 - U.S. P07/Split/Lana8Wonder communications pack: remove guaranteed growth/return/liquidity language; classify each transaction/scheme; approve U.S. landing pages, contracts, videos and social media. • CP-44 - Direct.Lana.Fund / Lana8Wonder capital-products memo: Securities Act route; Investment Company/private-fund risk; adviser/broker/dealer; lending; state Blue Sky; investor eligibility and offering controls. • CP-45 - U.S. crowdfunding/Common Good taxonomy: donation/grant/reward/pre-sale vs securities/lending crowdfunding; Reg CF/Reg D/Reg A or other route; charity/tax-deductibility claims and intermediary requirements. • CP-46 - U.S. payments/Mode B memo: FinCEN MSB + state MTL/VC law + payment processor analysis; client-funds/safeguarding; licensed bank/PSP fallback; merchant-discharge documentation. • CP-47 - U.S. IRS pack: entity/tax residency; W-9/W-8; TIN; backup withholding; Form 1099-DA broker classification; proceeds/basis retention; state tax/sales-tax mapping. • CP-48 - U.S. OFAC/Clean Provenance pack: sanctions risk assessment; wallet/address/entity/geography screening; 50-percent rule controls; blocking/reject/escalation/reporting process and blockchain analytics governance. • CP-49 - U.S. privacy/biometric/AI state matrix: notice/consent, biometric rules, retention/deletion, vendors, breach notification, automated-decision/human-review, children/sensitive-data gates where relevant. • CP-50 - State securities/Blue Sky matrix for every federal securities route: registration/preemption/exemption, notice filing, fees, antifraud, broker/dealer/agent state status. • CP-51 - U.S. state consumer/UDAP/contracts/complaints/sales-tax pack per retail product; language accessibility and refund/delivery terms where required. • CP-52 - U.S. market-intermediary gate: broker-dealer/dealer/ATS/exchange/custody analysis if LANA/overlay is a security or platform starts matching, routing, executing, recommending or holding customer assets. Multi-Native-Coin, Maturity & Balanced Flow Activation Conditions (CP-53 to CP-61) _**• CP-53 - P24 technical eligibility pack: own-network/native-asset proof, Direct Key-Controlled Wallet test, address/signature/recovery specification, native RPC/node/explorer evidence and adapter test vectors for every candidate before TECHNICAL READY.**_ _**• CP-54 - Coin-specific legal/product matrix: for every external native coin and every activated function, document COIN x PRODUCT x JURISDICTION classification, offer/sale/custody/payment/AML/tax treatment and responsible entity before LEGAL READY.**_ _**• CP-55 - Coin-specific Registrar activation pack: canonical network ID; logically separated Registrar namespace for each coin; Registered Wallet/Account ownership proof; Registration Events; Total Registered Supply; Active Coin Supply; transaction/finality policy; Freeze/Unfreeze status; sanctions/provenance evidence; error/reorg handling; and privacy-coin exception/HOLD logic.**_ _**• CP-56 - External market/reference governance: approved market-data sources, timestamp/staleness rules, fallback source, denomination and audit trail. External market price must remain clearly separated from the coin-specific BEF System / Reference Value or other value-transition method defined by its Coin Split Profile.**_ • CP-57 - Coin Split Activation Pack: before SPLIT READY, define and test for each coin the Registered Supply and Active Coin Supply calculation, Open Flow or equivalent current-cycle availability metric, Split trigger, Registration and recirculation effects, stabilisation/brake logic, Common Good channel where used, value-transition/reference rule, Split Event schema, sequence numbering, audit evidence and next-cycle transition. The Framework 1.0 LANA reference implementation uses an exhaustion trigger, but external coins do not inherit LANA parameters automatically; each Coin Split Profile must explicitly adopt and technically evidence its own trigger. • CP-58 - Atomic Unit & Fee Economics Pack: before ACTIVE status, verify the coin/network canonical smallest unit and decimal conversion; approved EUR FX methodology; standard native-transfer fee model; live estimator/RPC source; rolling 30-day median and average where observable; P95/high-load fee; dust/minimum-output; account reserve/existential deposit; recipient activation; storage/state/rent charges; new-account transfer delta; and a fee-only BEF suitability classification. Dynamic-fee networks require refreshable evidence rather than a permanent static average. • CP-59 - CLOSED AT FRAMEWORK-DESIGN LEVEL IN 1.0 - Balanced Maturity & Stabilisation. System maturity is an adaptive collective transition rather than a fixed Split count, date or formula. It emerges as Personal Sufficiency/Balanced Wallet participation grows and sustained multi-month evidence shows sufficient internal circulation, merchant/consumer reuse, recirculation, reserves and dynamic capacity with reduced structural dependence on continuous Growth-Phase expansion. Before a specific coin economy is publicly represented as Mature / Balanced, its Coin Split Profile must publish the actual indicators, observation window and evidence used for that classification. Those are coin-specific activation parameters, not an open Core design question. • CP-60 - ACTIVATION CONDITION - Consumption Incentive & One-Split Carry Pack. Define the qualifying consumption event; current consumer/merchant incentive policy and funding source; principal-purchase separation; eligibility for one-Split carry; Registrar carry flag; mandatory end/release; tax/accounting treatment; securities/investment/consumer/payment classification by entity/jurisdiction; and communication rules preventing the carry privilege from being marketed as guaranteed return. This pack governs activation of that specific feature and is not an open Core architecture item. • CP-61 - CLOSED AT FRAMEWORK-DESIGN LEVEL IN 1.0 - Balanced Wallet Zero-Level, Gravity & Release. P14 defines Zero Level as a reference within real/evidenced capacity; below-Zero as coordinate rather than debt; multi-month dynamic Flow Capacity; and the sequence UNUSED REGISTERED EXCESS -> GRAVITY REVIEW/NOTICE -> PARTICIPANT CHOICE -> POSSIBLE DEREGISTRATION EVENT. Deregistration changes BEF Registered status only, may contract Registered Supply and never transfers private keys/native ownership. Production policy must publish the actual review cadence, notice/grace window, excess/range methodology, one-step or staged deregistration, appeal/human review where applicable and audit controls. These are adaptively versioned implementation parameters. ## ANNEX D - REGULATORY REFERENCES ### Primary legal references for Framework Version 1.0 (verification freeze: 18 August 2026) - Regulation (EU) 2023/1114 (MiCA): Article 2 (scope); Article 4 (public offers and limited-network exemption, Article 4(5)); Articles 6-7 (white paper / marketing); Articles 13-14 (retail withdrawal and offeror conduct); Articles 59-81 (CASP framework, including Article 77 exchange for funds); Articles 86-92 (market abuse); Annex I disclosures. - MiCA sustainability disclosure: kjer je formalni white paper ali CASP disclosure relevanten, uporabiti tudi takrat veljavne delegated/implementing technical standards glede sustainability indicators in principal adverse impacts consensus mechanisms. - ESMA Guidelines ESMA75453128700-1323 (19 March 2025): conditions and criteria for qualification of crypto-assets as financial instruments; substance-over-form and MiFID II boundary. - Directive (EU) 2015/2366 (PSD2): Article 3(j) technical-service exclusion; Article 3(k) limited-network instruments; Article 37 notification above EUR 1,000,000; payment-service definitions including money remittance and payment initiation. - PSD3 / Payment Services Regulation package: provisional political agreement reached in 2025 and Coreper confirmation in April 2026; not treated in Framework 1.0 as a replacement for currently applicable PSD2 until final adoption/application. - Regulation (EU) 2023/1113 (Transfer of Funds Regulation): information accompanying crypto-asset transfers and self-hosted-address controls where a CASP is involved. - Directive (EU) 2015/849 as amended and Regulation (EU) 2024/1624 (AMLR): current national AML regimes remain relevant until the new directly applicable AMLR regime; AMLR applies from 10 July 2027. P21 specifically uses Articles 19/22 (CDD identification and verification), Article 76 (personal data / automated-process safeguards) and Article 77 (record retention). - Regulation (EU) 2016/679 (GDPR): principles, privacy by design/default, automated decision safeguards and DPIA. EDPB Guidelines 02/2025, final 7 July 2026, used as design guidance for decentralised replicated personal-data architectures. - Regulation (EU) 2024/1689 (AI Act): AI transparency and, where applicable, human-oversight / high-risk obligations; this BEF does not assume all Digital Beings are high-risk AI. - Regulation (EU) 2022/2554 (DORA): applies to authorised CASPs and other covered financial entities; ICT risk, continuity, incident and third-party risk management. - Council Directive (EU) 2023/2226 (DAC8): crypto-asset tax reporting framework applicable from 1 January 2026 to in-scope reporting crypto-asset service providers/operators. - Regulation (EU) 2020/1503 (ECSP): relevant to lending-based and investment-based crowdfunding for business; grant/donation models require separate classification. - Directive 2011/61/EU (AIFMD): collective investment perimeter, including undertakings raising capital from a number of investors under a defined investment policy for their benefit. - Directive (EU) 2023/2673 amending Consumer Rights Directive for distance financial services: Member State measures apply from 19 June 2026, including withdrawal-function rules where applicable. - Directive (EU) 2023/2225 (Consumer Credit Directive): new regime applies from 20 November 2026; relevant before activation of any Balanced Wallet feature that could constitute consumer credit. - Slovenia: Zakon o izvajanju Uredbe (EU) o trgih kriptosredstev (ZIUTK) and current guidance of the Securities Market Agency (ATVP); exact NCA allocation remains function-specific. - EBA/GL/2022/15 - Guidelines on the use of Remote Customer Onboarding Solutions: current supervisory design reference for safe/effective remote onboarding, solution governance and identity-verification controls. - AMLA draft RTS under Article 28(1) AMLR on customer due diligence (2026 consultation/draft status): used only as forward-looking implementation input and not treated as final binding law until adopted. - Regulation (EU) 2016/679 (GDPR): Articles 5, 6, 9, 22, 25 and 35 are especially relevant to KYC biometrics, purpose separation, automated decisions, privacy by design and DPIA. - OpenSanctions commercial-use terms: contractual/data-licensing control rather than EU law; commercial customer/supplier screening requires an appropriate data licence under the provider's current terms. - United Kingdom - passporting: FCA, Regimes for EEA firms and investment funds that passported to the UK; EEA-based firms can no longer passport into the UK after the transition period. https://www.fca.org.uk/firms/regimes-eea-firms-passported - United Kingdom - current crypto MLR perimeter: FCA, Cryptoassets: Who needs to register (page checked 18 August 2026; FCA page last updated 7 July 2026); MLR territorial factors, exchange-provider definition and overseas/no-UK-office example. https://www.fca.org.uk/firms/cryptoassets/who-needs-register - United Kingdom - crypto financial promotions: FCA, Cryptoasset firms marketing to UK consumers; overseas firms are in scope and communications routes under section 21/FPO framework. https://www.fca.org.uk/firms/cryptoassets/marketing-uk-consumers - United Kingdom - new FSMA crypto regime: The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026 (SI 2026/102); FCA new-regime materials identify 25 October 2027 as expected commencement. https://www.legislation.gov.uk/uksi/2026/102 ; https://www.fca.org.uk/firms/new-regime-cryptoasset-regulation - United Kingdom - regulated cryptoasset activities: FCA, Cryptoasset regulated activities: FSMA and the FCA Handbook; includes dealing in qualifying cryptoassets as principal/agent and arranging. https://www.fca.org.uk/firms/new-regime-cryptoasset-regulation/fsma-handbook - United Kingdom - international firms: FCA Finalised Guidance FG26/7, Approach to international cryptoasset firms (30 June 2026); UK presence and baseline UK legal-entity expectations, including proprietary principal dealing. https://www.fca.org.uk/publication/finalised-guidance/fg26-7.pdf - United Kingdom - gateway timing: FCA, Cryptoassets: How the gateway will operate; expected application period 30 September 2026 to 28 February 2027 and saving/transitional framework. https://www.fca.org.uk/firms/new-regime-cryptoasset-regulation/how-gateway-will-operate - United Kingdom - payment services: Payment Services Regulations 2017 and FCA PERG 15.5; principal/reseller, commercial-agent, escrow and limited-network payment perimeter guidance. https://www.legislation.gov.uk/uksi/2017/752 ; https://handbook.fca.org.uk/handbook/perg15/perg15s5 - United Kingdom - qualifying cryptoasset limited-use definition for financial promotions: FCA Handbook glossary, qualifying cryptoasset. https://handbook.fca.org.uk/glossary/G3478q - United Kingdom - Travel Rule: FCA expectations for UK cryptoasset businesses, applicable since 1 September 2023. https://www.fca.org.uk/news/statements/fca-sets-out-expectations-uk-cryptoasset-businesses-complying-travel-rule - United Kingdom - biometrics/data protection: UK GDPR and Data Protection Act 2018; ICO guidance treats biometric data used for unique identification as special-category data requiring Article 6 and Article 9 analysis. https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/lawful-basis/a-guide-to-lawful-basis/special-category-data/ > _UK reference freeze date for BEF 1.0: 18 August 2026. Future FCA perimeter guidance, final HM Treasury proprietary-trading amendment, commencement instruments or Handbook changes must be checked before production reliance._ - EU - ESMA Q&A 2293 / European Commission answer (6 June 2025), Proprietary trading under MiCA: dealing on own account generally does not involve a client relationship and in those cases CASP licence is not required; proprietary-capital exchange contracts with clients remain CASP exchange services. https://www.esma.europa.eu/publications-data/questions-answers/2293 - United Kingdom - FCA, Cryptoassets: Who needs to register (current page checked 18 August 2026): current MLR registration depends on in-scope service by way of business and carrying on business in the UK; FCA notes an overseas firm with no UK office/agent/other UK activity is not automatically carrying on business in the UK merely because it has UK clients. https://www.fca.org.uk/firms/cryptoassets/who-needs-register - United Kingdom - HM Treasury, draft Financial Services and Markets Act 2000 (Cryptoassets) (Amendment) Regulations 2026 and Policy Note (21 April 2026): proposed Article 9UA proprietary-trading exclusion from dealing as principal where the activity is not carried on to provide a service to a client related to a regulated activity carried on on that client’s behalf. DRAFT only at the 18 August 2026 verification freeze. https://www.gov.uk/government/publications/policy-note-draft-statutory-instrument-amending-the-cryptoasset-regulations - United Kingdom - FCA CP26/13, Cryptoasset perimeter guidance (15 April 2026): proposed perimeter guidance includes dealing as principal; FCA stated final perimeter guidance is intended for autumn 2026. Re-check before post-2027 reliance. https://www.fca.org.uk/publications/consultation-papers/cp26-13-cryptoasset-perimeter-guidance ### Legal reference rule Ta Annex je regulatorna orientacija, ne nadomestilo za entity-specific legal opinion. Če se relevantno pravo spremeni ali začne uporabljati nov režim, P15 Regulatory Change Trigger zahteva ponovno presojo. ### United States - primary regulatory references (source freeze 18 August 2026) • FinCEN FIN-2014-R002 (30 Jan 2014), Application of FinCEN’s Regulations to Virtual Currency Software Development and Certain Investment Activity - own-account virtual-currency investment / software-assisted purchase analysis. • FinCEN FIN-2013-G001 (18 Mar 2013), Application of FinCEN’s Regulations to Persons Administering, Exchanging, or Using Virtual Currencies - user / administrator / exchanger and money-transmitter framework. • SEC Interpretive Release Nos. 33-11412 / 34-105020, File S7-2026-09 (17 Mar 2026; effective 23 Mar 2026), Application of the Federal Securities Laws to Certain Types of Crypto Assets and Certain Transactions Involving Crypto Assets; includes CFTC guidance. • SEC, Exempt Offerings and Private Funds materials (current 2026) - Reg D, Reg CF, Reg A and private-fund routes where a BEF transaction/overlay is a security. • Public Law 119-27, GENIUS Act (18 Jul 2025) and implementing materials - payment stablecoin perimeter; P23 does not classify LANA as a payment stablecoin absent stable-value/redemption facts. • IRS, Instructions for Form 1099-DA (2026), Digital Asset Proceeds From Broker Transactions - broker/customer sales, basis/proceeds, W-9/W-8/TIN and backup-withholding implementation. • OFAC FAQ 560 and Sanctions Compliance Guidance for the Virtual Currency Industry - digital currency is subject to the same sanctions obligations; tailored risk-based screening controls. • State primary sources listed in Annex M: state banking/financial regulators, money-transmission statutes, virtual-currency/digital-asset statutes and current guidance. Ambiguous states are not treated as exempt merely because no explicit prohibition was located. ## ANNEX E - LANA NOSTR KIND INDEX (HUMAN-READABLE SNAPSHOT) Snapshot basis: LanaNostr.site / kinds.json, public documentation reviewed 16 August 2026. The site identifies kinds.json as the complete authoritative structured source; its metadata reported version 2.42.0 and updated_at 2026-08-12. This Annex is a readable map, not a substitute for the live JSON specification. ### Core configuration & identity - KIND 38888 - Lana System Parameters / core configuration. - KIND 0 - Lana Extended Profile. - KIND 12893 - Lana KIND Definition / protocol definition history. - KIND 37334 - Lana World Wide App Settings. ### Authentication, rooms & direct communication - KIND 4 - Direct Message (NIP-04). - KIND 22242 - Lana Meet Auth Token (ephemeral; not relay-persisted in Lana Meet). - KIND 30150 - Private Room Definition (client-filtered room membership; messages themselves are not encrypted by this kind). ### Registrar, wallets & identity references - KIND 87001 - New Wallet registration request. - KIND 87002 - Wallet Registration by Registrar. - KIND 87003 - Monitoring for Unregistered Coins. - KIND 87004 - Monitoring for Max Coins. - KIND 87005 - New LanaCoins Registration. - KIND 87006 - Registration Confirmation. - KIND 87007 - Registrar Acceptance / mutual recognition. - KIND 87008 - Registrar Sync Index / system snapshot. - KIND 87009 - Unregistered LANA Return Confirmation. - KIND 87010 - Frozen Wallets audit trail. - KIND 30889 - Registrar Wallet List. - KIND 30289 - Unregistered Wallet List. - KIND 56757 - Loss Report. - KIND 87033 - Person Reference / Web of Trust. ### Lana8Wonder - KIND 88888 - Lana8Wonder Annuity Plan. ### Payments & payment evidence - KIND 89800 - Lash Payment Intent. - KIND 89807 - Lash Payment Confirmation. - KIND 87088 - Lash Payment on-chain broadcast. - KIND 39991 - Lash Payments 2.0 lifecycle. - KIND 70100 - Lana Simple Invoice. - KIND 70101 - Lana Simple Payment Confirmation. - KIND 94501 - LanaPays Payment Request / Invoice. - KIND 94502 - LanaPays Liquidity Assignment. - KIND 94503 - LanaPays Blockchain Payment Confirmation. - KIND 94504 - LanaPays FIAT Settlement. ### LanaPays.us / Lana.Discount / Direct.Fund v2 - KIND 30901 - Business Unit Definition. - KIND 30902 - Processor Fee Policy. - KIND 30903 - Merchant Status & Quota. - KIND 30905 - Lana Eco Distribution Node. - KIND 30933 - LanaPays Purchase Transaction. - KIND 30934 - Lana.Discount LANA Order (legacy technical name; P08 semantic/UI mapping: Treasury Acquisition Proposal / Acquisition Record; not an exchange order). - KIND 30935 - Direct.Fund FIAT Order. - KIND 30936 - Buyback Transaction (legacy technical name; for P08 semantic/UI mapping: Proprietary Treasury Acquisition Settlement; “buyback” must not imply guaranteed redemption right). - KIND 30937 - FIAT Payout Record (for P08: purchase-price settlement evidence from Lana Discount own funds to seller; not a withdrawal from a client balance). - KIND 30938 - Investor Budget Allocation. - KIND 30939 - Investor Payment Record. - KIND 30940 - Investor Report. > _P08 implementation note: generic marketplace/exchange KINDs may exist elsewhere in Lana protocol, but Lana Discount Treasury Acquisition Portal must not expose them as customer exchange/cash-out functionality unless P15 reclassification has been completed. Legacy KIND names do not determine legal substance._ ### Exchange & marketplace - KIND 91991 - LANA Sell Offer. - KIND 91992 - LANA Buy Request. - KIND 91993 - LANA Transaction Confirmation. - KIND 31950 - Market Offer. - KIND 93333 - Purchase Confirmation. ### Consumer listings - KIND 36500 - Eco Listing. - KIND 36501 - Restaurant Listing. - KIND 36502 - Shop Listing. - KIND 36503 - Kids Listing. - KIND 36504 - Construction Listing. - KIND 36505 - Fashion Listing. - KIND 36506 - Furniture Listing. - KIND 36507 - Pet Listing. - KIND 36508 - Vacations Listing. - KIND 36509 - Beauty Listing. ### Eco distribution - KIND 36601 - Lana Eco Distribution Order. - KIND 36602 - Lana Eco Distribution Fulfillment. - KIND 36603 - Lana Eco Distribution Allocation. - KIND 36604 - Supplier aggregate delivery to distribution node (draft in reviewed spec). ### Governance & Alignment - KIND 38883 - Awareness Proposal. - KIND 38884 - Awareness Acknowledgement. - KIND 88805 - Awareness Integration. - KIND 88807 - Oracle Acceptance. - KIND 18806 - Quorum Status. ### Crowdfunding, unconditional support & community - KIND 31234-31235 and 60200 - 100 Million Ideas / LanaCrowd crowdfunding family. - KIND 31240 and 60210-60212 - Unconditional Financing family as indexed in the public documentation. - KIND 90900 - Unconditional Donation Proposal. - KIND 90901 - Unconditional Payment Confirmation. - KIND 37772 - LanaKnight Registry. - KIND 77771 - LanaKnights Registration Event. - KIND 36677 - Lana Event Definition. - KIND 53333 - Event Registration. - KIND 53334 - Event Donation Log. - KIND 99991 - Lana World Knowledge. ### PLAN15 - KIND 31515 / 31516 - PLAN15 offer-side records. - KIND 91515 - PLAN15 Buy Acceptance. - KIND 91516 - PLAN15 Payout Confirmation. ### News & editorial - KIND 30998 - Lana Reliable Source Attestation. - KIND 30999 - Lana News Article. ### OWN / Unconditional Self-Responsibility - KIND 87044 - Self Responsibility Process root. - KIND 37044 - OWN master process record / current process state. - KIND 37045 - Being Participant Phase-State. - KIND 37046 - OWN Grievance Ledger. - KIND 37047 - OWN Emotion Palette. - KIND 37048 - OWN Change-Commitment Proposal. - KIND 37049 - OWN Change Commitment. - KIND 37050 - OWN Grievance Source (participant-only encrypted source map). - KIND 87045 - OWN Group Key Share. - KIND 87046 - OWN Group Message. - KIND 87047 - OWN Being Assessment Entry. - KIND 87048 - OWN Being Guidance Entry. - KIND 87049 - OWN Commitment Milestone. - KIND 87055 - OWN Self-Responsibility Exit / Re-enter. - KIND 87056 - OWN Facilitator Pause / Reopen. - KIND 87057 - OWN Person Freeze / Unfreeze. - KIND 87944 - OWN Public Transcript. - KIND 87945 - OWN Transcript Donation & Revenue Share. - KIND 98999 - OWN User Responsibility State (historical ledger). ### Digital Beings, TRIAD & knowledge - KIND 30987 - Lana GitHub Application. - KIND 76523 - Lana Awareness Entry. - KIND 1078 - Being Core Memory. - KIND 30078 - Being Daily Memory Snapshot. - KIND 39010 - Lana Bridge Consent / Lana Mostovi. - KIND 39020 / 39021 / 39022 and 76530 / 76531 - Being Commons / Zbor Bitij family. - KIND 73984 - Lana Being Birth Certificate. ### Being Advanced KYC - KIND 37100 - Person Being-Choice & Consent. - KIND 37101 - Being Adoption Record. - KIND 37102 - Person Current Dossier. - KIND 37103 - Public Attestation Level. - KIND 37104 - Being Liveness Heartbeat. - KIND 37105 - KYC Verification Attestation (trusted authority-signed VERIFIED / REVOKED identity evidence; schema finalization in P21). - KIND 87100 - Person Dossier Entry. - KIND 87101 - Inter-Being Person Note. ### Being Domains - KIND 30904 - Being Domain Record. - KIND 91517 - Being Domain Purchase Confirmation. ### Agent Rooms / The Rose - KIND 32100 - Agent Room Definition. - KIND 32102 - Agent Communication Allowlist (deprecated in reviewed spec). - KIND 32103 - Agent Rooms Circle Registry. - KIND 87200 - Agent Room Group Key Share (deprecated for transparent v2 rooms in reviewed spec). - KIND 87201 - Agent Room Message. - KIND 87210 - Agent Proposal / Prompt. - KIND 87211 - Agent Action Record. ### Education / Lana Ucilnica - KIND 36700 - Lana Course. - KIND 36701 - Lana Lesson. - KIND 36710 - Lana Enrollment Order. - KIND 36711 - Lana Enrollment Grant. - KIND 36712 - Lana Lesson Progress. - KIND 36720 - Lana Completion Attestation. - KIND 36730 - Lana Course Review. ### Canonical-source rule The above list is intentionally a human-readable snapshot. LanaNostr.site explicitly marks kinds.json as the complete authoritative structured specification and describes llms.txt/docs.html as partial or legacy views. Therefore, clients, auditors and future BEF versions must resolve any discrepancy against the then-current kinds.json and the relevant per-KIND page, including publisher authority, encryption, replaceability, required tags and validation rules. ### Technical references - Lana protocol registry: https://lananostr.site/ - Canonical Lana KIND registry: https://lananostr.site/kinds.json - AI-readable Lana overview: https://lananostr.site/llms.txt - Nostr NIP-01: https://github.com/nostr-protocol/nips/blob/master/01.md ### U.S. technical-name disclaimer Legacy Nostr/KIND labels such as “Lana.Discount LANA Order”, “Buyback Transaction”, “Exchange & marketplace” or “Lana8Wonder Annuity Plan” are historical/technical identifiers only. They do not define legal substance. For U.S.-facing UI, contracts and marketing, P08/P23 terminology controls; “annuity” is not used as a public product label without an actual state-regulated insurance/annuity basis. ## ANNEX F - REGULATORY CLOSURE MATRIX Ta matrika je izvršilni povzetek Frameworka 1.0. Status opisuje pripravljenost posamezne funkcije za aktivacijo, ne regulatorne odobritve celotnega Frameworka. | Area | 1.0 Status | Activation / closure condition | | --- | --- | --- | | Registered LANA offer / limited network | CONDITIONAL | P15 strict use-right/network-growth evidence + CP-01/02; notification monitoring; Title II fallback if exemption unavailable. | | Direct merchant LANA settlement | READY | Merchant contract + consumer/tax rules; no hidden custody/payment role. | | Principal purchase + merchant FIAT settlement | CONDITIONAL | P19 MiCA/CASP + PSD2 memo per principal purchaser. | | Lana Discount proprietary treasury acquisition | CONDITIONAL | P08/P15 + CP-05 own-account/no-client-service memo; ESMA Q&A 2293; CASP/Article 77 only on client-service trigger; own capital + Clean Provenance + Acceptance Gate. | | BuyLana.com / operating-company Purchase & Delivery | CONDITIONAL | P07 + Offeror/MiCA classification + consumer matrix per jurisdiction; named seller and direct-sale/delivery evidence. | | Alignment governance | CONDITIONAL | CP-12 eligible voters + mandatory-law override. | | OWN / Freeze | CONDITIONAL | Appeal/human-review timing + data-protection controls. | | Nostr infrastructure | CONDITIONAL | Key/recovery/retention + GDPR matrix. | | Digital Beings - non-material assistance | READY | AI disclosure + permission scope + logging. | | Digital Beings - material financial/legal actions | HOLD | Provider/deployer mapping, custody, permissions, human oversight. | | Grant/donation crowdfunding | CONDITIONAL | Project taxonomy + consumer/tax/AML checks. | | Lending/investment crowdfunding | HOLD | ECSP/MiFID/AIF/credit classification before offer. | | Direct.Lana.Fund new financing rounds | CONDITIONAL | P15 classification memo + liability/source-of-funds evidence. | | Lana8Wonder Growth Phase | CONDITIONAL | P14 communications + offeror/consumer/market-integrity perimeter. | | Balanced Wallet Zero-Level / Flow Capacity / Gravity | FRAMEWORK-COMPLETE / ACTIVATION PARAMETERS REQUIRED | P14 defines personal sufficiency, Zero-Level coordinate logic, dynamic multi-month Flow Capacity, breathing expansion/contraction and Gravity/Deregistration. A below-Zero coordinate is not debt and creates no spending power. Asset/entity-specific display, review cadence, notice/grace, deregistration and audit parameters must be published before automated production use. | | EU market integrity | CONDITIONAL | Activation depends on EU trading/admission status; controls ready in P16. | | AML/TFR/DAC8 | CONDITIONAL | Entity-specific obliged/reporting status and operational policies. | | DORA | CONDITIONAL | Mandatory for in-scope authorised CASP/financial entity. | | BEF Framework 1.0 | FINAL FRAMEWORK BASELINE | Core architecture closed. Annex C conditions continue as function-specific activation gates. CONDITIONAL/HOLD functionality must not be launched until its applicable legal, technical, accounting and evidence pack is complete. | | Being KYC / Regulatory Identity Assurance | CONDITIONAL | P21 technical evidence ready; regulated activation requires CP-25 to CP-31, current-law mapping, DPIA, human-decision safeguards and remote-IDV validation. | | UK cross-border access from overseas entity - current MLR | CONDITIONAL | P22 + CP-33; no UK office/agent/other UK activity conclusion; financial promotions remain separate. | | UK crypto financial promotions | HOLD | No UK-targeted promotion until CP-34 lawful communication route and FCA-rule consumer journey are implemented. | | UK BuyLana.com / Operating Company - fiat -> LANA | CONDITIONAL | CP-32/33/34/36: current MLR + promotion + consumer/payment classification; post-2027 reclassification. | | UK Lana Discount proprietary treasury acquisition | CONDITIONAL | Current MLR business/territorial + applicable promotions; CP-35/37 final Article 9UA/FCA future-perimeter re-check; T+15 own-funds settlement. | | UK dealing as principal from 25 Oct 2027 - final perimeter | CONDITIONAL / HOLD IF IN-SCOPE | Re-check final proprietary-trading exclusion + FCA final perimeter guidance. If excluded: no dealing permission assumed. If regulated: HOLD without FCA authorisation/transition basis. | | UK Mode B merchant fiat settlement - separate from Lana Discount P08 | CONDITIONAL | Separate crypto + PSR 2017 memo; merchant-discharge/client-money evidence. P08 treasury conclusion does not carry over. | | UK AML / Travel Rule / KYC | CONDITIONAL | CP-38; UK MLR/FCA policies + UK GDPR/DPA biometric lawful-basis/DPIA validation. | | UK conduct / prudential / resilience | CONDITIONAL | CP-39 for permissions sought; FCA Handbook obligations after authorisation. | | UK market integrity / MARC | CONDITIONAL | Activate if UK admissions/trading perimeter applies; UK-specific rules separate from MiCA P16. | | **U.S. regulatory architecture** | **READY** | **P23 + Annexes L-N; product/state activation remains separate.** | | **U.S. Lana.discount federal own-account baseline** | **READY / FACT-SENSITIVE** | **FIN-2014-R002 mapping + CP-41; no customer-service drift.** | | **U.S. Lana.discount state activation** | **CONDITIONAL** | **Annex M; READY only in listed states for strict P08 state MT/VC layer.** | | U.S. P07 / BuyLana.com Purchase & Delivery | **CONDITIONAL** | **CP-40/43; no investment-return marketing; state activation.** | | **U.S. Lana8Wonder retail** | **HOLD** | **CP-43/44 + securities/Blue Sky + product redesign/route.** | | **U.S. Direct.Lana.Fund public/retail** | **HOLD** | **CP-44/50; securities/private fund/adviser/broker/lending analysis.** | | **U.S. Mode B merchant fiat settlement** | **HOLD** | **CP-46; FinCEN + state MTL/payment + licensed PSP alternative.** | | **U.S. custody/private-key control** | **HOLD** | **Separate federal/state custody/MT/securities safeguarding permission.** | | **U.S. OFAC/Clean Provenance** | **CONDITIONAL -> READY after pack** | **CP-48 operational screening/escalation evidence.** | | **U.S. tax/reporting** | **CONDITIONAL** | **CP-47; 1099-DA and counterparty tax documentation by function.** | | P24 Native Coin Integration & Balanced Split Architecture | CONDITIONAL | CP-53 to CP-57; Coin Integration Profile + coin-specific Registrar + Registered/Active Supply evidence + Coin Split Profile + COIN x PRODUCT x JURISDICTION activation. Candidate status is not legal or Split activation. | | **External Registered Native Coin status** | HOLD until REGISTRY READY + SPLIT READY + LEGAL READY | Every ACTIVE coin must follow the common BEF Balanced Split Architecture through its own Registrar and Coin Split Profile. LANA parameters do not transfer automatically; the shared development concept does. | | External Coin Split Architecture | HOLD until SPLIT READY | Coin-specific Active Coin Supply, Split trigger, value-transition/reference rule, recirculation/stabilisation logic and auditable Split Event must exist before ACTIVE. | | P24 Native Coin Atomic Unit & Fee Economics | CONDITIONAL | CP-58; canonical atomic unit + EUR methodology + standard-transfer fee evidence + rolling 30-day median/average + P95 + dust/reserve/activation/storage costs before ACTIVE. | | BEF Growth -> Mature / Balanced State | FRAMEWORK-COMPLETE / COIN-SPECIFIC EVIDENCE REQUIRED | System maturity is an adaptive collective transition, not a fixed date or threshold. Coin-specific policy must publish sustained multi-month indicators showing sufficient Balanced Wallet participation, internal circulation, recirculation and reduced structural growth dependency before representing that economy as Mature / Balanced. | ## ANNEX G - LEGAL ENTITY & REGULATORY RESPONSIBILITY MATRIX Pred regulatornim filingom se tabela izpolni za vsako dejansko pravno osebo. Placeholder ne šteje kot closure. | Legal entity / state | Function | Contract counterparty | FIAT ownership/flow | Crypto/custody | Licence / exemption / classification | Competent authority | Responsible officer | | --- | --- | --- | --- | --- | --- | --- | --- | | [Entity / country] | BuyLana.com / Offeror / Purchase & Delivery | [counterparty] | [who receives EUR] | [who receives LANA] | [MiCA/PSD2/etc status] | [NCA] | [officer] | | [Entity / country] | Registrar | [participant] | N/A | No custody unless separately stated | [status] | [NCA / DPA] | [officer] | | [Entity / country] | LanaPays technical operator | [merchant/user] | [none / specify] | [none / specify] | [technical / payment perimeter] | [NCA] | [officer] | | [Entity / country] | Lana Discount - Proprietary Treasury Purchaser | [seller / counterparty] | Own capital -> seller as purchase-price settlement | Receives purchased LANA directly into proprietary treasury wallet; no counterparty custody/private-key control | [P08 own-account/no-client-service perimeter; CASP Article 77 only if reclassified] | [NCA] | [officer] | | [Entity / country] | Direct.Lana.Fund operator | [financier] | Receives financing under contract | [if any] | [classification] | [NCA] | [officer] | | [Entity / country] | Digital Being provider/deployer | [user/community] | N/A unless separately licensed | [custody model] | [AI/financial perimeter] | [NCA] | [officer] | | [Entity / country] | Merchant network contracting / offeror nexus | [merchant / offeror] | N/A unless payment role | N/A unless custody | [limited-network contractual role] | [NCA] | [officer] | | [Entity / country] | Optional Mode B principal purchaser settlement - separate function | [consumer / merchant] | Own funds -> merchant via bank/PSP | Receives LANA as principal | [Separate MiCA/CASP + PSD2 memo; no automatic P08 exemption] | [NCA] | [officer] | | [Entity / country] | KYC Identity Verification Service | [obliged entity / participant] | N/A except fees if any | No custody; sensitive identity/biometric data only | [processor/controller / AML identity role] | [NCA / DPA / AML supervisor] | [KYC owner / DPO / MLRO interface] | | [EEA entity / Estonia] | Cross-border UK access (pre-2027 current-perimeter analysis) | [UK counterparty] | Own sale/purchase consideration only; no client-funds pooling | [specify LANA ownership/custody] | [UK MLR territorial memo + financial-promotion route; no UK passport assumption] | FCA if in scope / home NCA | [officer] | | [Proposed UK entity] | UK BuyLana.com / Offeror / Purchase & Delivery | [UK buyer] | Receives GBP as own sale consideration | Delivers Registered LANA; custody only if separately stated | [Current MLR + future FSMA principal/other permission + financial promotions + consumer] | FCA / ICO as applicable | [UK officer / MLRO] | | [UK-facing Lana Discount entity / EEA or UK as final perimeter requires] | UK Proprietary Treasury Purchaser | [UK seller / counterparty] | Own capital -> seller only | Receives ACCEPTED LANA as principal owner; no custody/private-key control for seller | [Current MLR territorial/business + promotion route; future final Article 9UA/FCA test; permission only if in scope] | FCA | [UK officer / MLRO] | | [UK KYC service/entity] | UK KYC Identity Verification / CDD evidence service | [UK obliged entity / participant] | N/A except service fees | No crypto custody unless separately licensed | [UK GDPR/DPA + MLR identity role; controller/processor classification] | ICO / FCA where applicable | [DPO / MLRO interface] | | **[U.S. entity / state activation]** | **P08 Proprietary Treasury Purchaser** | **Seller / Counterparty** | **Own USD capital -> seller** | **Receives purchased LANA as principal; no custody** | **FIN-2014-R002 federal mapping + state Annex M** | **FinCEN/state regulator/OFAC/IRS as applicable** | **[U.S. compliance officer]** | | **[U.S. securities entity/route]** | **P14/Direct.Fund if activated** | **Investor / participant** | **Per offering documents** | **No customer crypto custody unless separately cleared** | **SEC + Blue Sky + fund/adviser/broker route** | **SEC/state securities regulators** | **[officer]** | | **[U.S. payment/PSP route]** | **Mode B only if activated** | **Consumer / merchant** | **Licensed PSP/bank or cleared principal flow** | **No customer crypto custody by default** | **FinCEN/state MTL/payment classification** | **FinCEN/state banking regulator** | **[officer]** | | **[Entity / country]** | P24 Native Coin Registrar / Split operator | **[participant / product entity]** | No FIAT unless separately activated; maintains coin-specific Registered/Active Supply and Split evidence | No custody by default; validates native-chain evidence, Registrar namespace and Split state | [technical/Registrar/Split role + COIN x PRODUCT x JURISDICTION legal record] | **[NCA / DPA / other as applicable]** | [P24 Registrar/Split owner / compliance officer] | ## ANNEX H - PRICE, VALUE & LIQUIDITY TAXONOMY Vsak UI, pogodba in poročilo mora uporabiti pravo kategorijo. Izraz “value” brez kategorije je pri materialni finančni komunikaciji neustrezen. | Kategorija | Pomen | Pravni/komunikacijski učinek | | --- | --- | --- | | BEF System / Reference Value | Notranja vrednost, uporabljena v pravilih cikla/Splita. | Ne ustvarja sama po sebi EUR terjatve ali likvidnosti. | | Offer / Sale Price | Cena, po kateri offeror proda dogovorjeno količino Registered LANA. | Pogodbena cena konkretnega nakupa. | | Merchant Price / Conversion Basis | Cena blaga/storitve oziroma metoda, po kateri merchant sprejme LANA. | Mora biti jasna pred potrošnjo. | | Treasury Acquisition Indicative Price / Buy Price | Non-binding price/range Lana Discount may use when evaluating acquisition for own treasury; current internal policy may reference market and target approx. 22-35% acquisition discount. | Not a fee, exchange rate, guaranteed quote or right to transact. CASP Article 77 pricing rules apply only if activity is reclassified as client exchange service. | | ACCEPTED Purchase Price | Končna pogodbena cena konkretnega bilateralnega treasury nakupa. | Ustvari Lana Discount lastno purchase-price obligation; settlement praviloma takoj oziroma največ T+15, če je odloženo dogovorjeno. | | Open-Market LANA Price | Cena Non-Registered/underlying LANA na relevantnem javnem trgu. | Ločena od BEF system value. | | Realised Value | Dejansko izvršena ekonomska transakcija/poravnava. | Evidence-based, ne projekcija. | | Treasury Liquidity / Purchasing Capacity | Lastna sredstva Lana Discounta, dejansko razpoložljiva za nove ACCEPTED acquisitions in obstoječe obveznosti. | Ni customer liquidity service in ni enaka System Value. | | Spending Capacity | Prihodnja Balanced Wallet možnost porabe. | HOLD do dokončne pravne in finančne specifikacije. | | **External Native Coin Market Reference** | External market price for a P24 coin from an approved source and timestamp. It remains separate from that coin’s own BEF System / Reference Value or other Coin Split Profile value-transition methodology. | Informational/reference datum unless incorporated into a concrete contract; it does not determine a Coin Split unless the coin-specific Split Profile expressly and lawfully defines such a relationship. | ## ANNEX I - CONSUMER SETTLEMENT FLOW MATRIX | Flow | From | To | Asset/Funds | Direct path | Economic role | Regulatory gate | | --- | --- | --- | --- | --- | --- | --- | | BuyLana.com - Purchase & Delivery | Buyer | Named Operating Company / Seller | FIAT -> seller; Registered LANA -> buyer | Buyer bank/PSP -> seller; seller wallet -> buyer Registered Wallet | Direct purchase of a fixed quantity of Registered LANA and delivery under P07 | P07 + entity/jurisdiction offeror, crypto, consumer and payment-perimeter gates; no default client-funds pooling | | MODE A - Direct LANA | Consumer | Merchant | Registered LANA | Consumer -> Merchant wallet | Merchant receives LANA directly | Merchant/consumer contract; crypto/tax/consumer rules | | MODE B - Separate Principal Purchase (optional) | Consumer | Principal LANA Purchaser | Registered LANA | Consumer -> Purchaser wallet | Purchaser acquires LANA as principal | Separate crypto-service classification; P08 own-account conclusion does not automatically apply | | MODE B - Separate Merchant Fiat Leg | Principal LANA Purchaser | Merchant | FIAT from purchaser own funds | Purchaser bank/PSP -> Merchant | Merchant receives fiat | PSD2/payment-perimeter memo + bank/PSP execution | | Merchant later sells LANA | Merchant / other holder | Lana Discount / other proprietary buyer | Registered LANA | Merchant -> buyer | Separate later treasury sale; buyer decides independently whether to acquire | P08 own-account test for Lana Discount; otherwise buyer-specific classification | | UK BuyLana.com / Purchase & Delivery | UK consumer | UK/overseas principal seller | GBP -> seller; Registered LANA -> consumer | Consumer bank/PSP -> seller; seller wallet -> consumer | Seller receives own consideration and delivers LANA | P22: MLR territorial/registration + financial promotions + PSR check only if third-party funds role | | UK Lana Discount proprietary treasury acquisition | UK seller / counterparty | Lana Discount proprietary purchaser | Registered LANA -> purchaser; GBP -> seller | Seller wallet -> purchaser; purchaser bank/PSP -> seller | Purchaser acquires selected LANA for own treasury/risk; seller receives own purchase price | Current MLR territorial/business + applicable FP; future final Article 9UA/FCA test; T+15 capacity gate | | UK Mode B merchant fiat leg - separate | UK principal purchaser | UK merchant | GBP from purchaser own funds | Purchaser bank/PSP -> merchant | Merchant receives settlement linked to consumer purchase | Separate P22/PSR crypto/payment memo; not part of P08 proprietary treasury purchase | | **US P08 strict treasury** | **U.S. seller** | **Lana.discount principal purchaser** | **LANA -> purchaser; USD -> seller** | **Direct seller wallet -> proprietary treasury; purchaser bank -> seller** | **Own-account acquisition; purchased LANA becomes purchaser property** | **P23/Annex M + CP-41/42** | | **US Mode B (default HOLD)** | **Consumer** | **Principal purchaser / merchant** | **LANA + USD** | **Consumer LANA -> purchaser; purchaser USD -> merchant** | **Linked crypto purchase + merchant payment** | **CP-46; FinCEN/state MTL/payment; licensed PSP fallback** | ## ANNEX J - KYC / IDENTITY ASSURANCE CONTROL MATRIX Annex J translates P21 into the implementation profile for the current Being KYC upgrade. Technical values are implementation defaults and may be replaced by a regulator-approved or independently validated equivalent without changing the P21 control objective. | Control | Implementation profile v1 | Public / private | Regulatory gate | | --- | --- | --- | --- | | Session binding | Fresh signed challenge/NIP-98; nonce/TTL/anti-replay; one active process; rate limits. | Private metadata | Mandatory before capture. | | Document capture | Direct raw upload; high-resolution MRZ/VIZ; no public media URL; TD1/TD3 v1. | Strictly private | Accepted document list + fallback required. | | MRZ/VIZ | Deterministic OCR/extraction + ICAO check digits + VIZ cross-check; LLM advisory only. | Private | Checksums are integrity, not authenticity. | | Document authenticity | Risk signals + certified/eID/vendor seam. | Private | Independent validation before CASP production. | | Face match | Local 1:1 embeddings; calibrated thresholds; grey zone retry/review. | Biometric private | DPIA + performance/bias testing. | | Liveness/PAD | Random challenge + server timing + optional low-risk illumination nonce; multi-signal PAD. | Biometric private | Do not claim replay-proof; test/deploy vendor seam. | | Screening | Sanctions + PEP local dataset; multilingual fuzzy/identifier matching; human candidate review. | Private | Commercial data licence + PEP/EDD workflow. | | Decision | Automatic IDENTITY-VERIFIED allowed; separate CDD-PENDING -> human safeguarded decision where required. | Private decision | AMLR Article 76(5) readiness / GDPR Article 22. | | Storage | Encrypted fields + sealed archive; no PII in logs; controlled break-glass retrieval. | Private | Article 77/current-law retention and retrievability. | | Document fingerprint | HMAC of normalized issuer/country/type/number; raw number encrypted. | Private | Duplicate detection without public/plain hash. | | Public attestation | 37105: person, verified/revoked, method, version, times, authority; no document/biometric/screening data. | Public minimal | Trusted authority signature + expiry/revocation. | | Public photo | Separate user-selected profile photo, not KYC selfie; separate consent. | Optional public | Not a condition of regulatory KYC. | | Ongoing KYC | Daily/event-driven screening update; expiry/review reminders; transaction-monitoring handoff. | Private | KYC is ongoing, not perpetual badge. | | Travel Rule | 37105 identity evidence + separate wallet ownership/control proof when TFR requires. | Mixed/minimal | P17/TFR implementation remains separate. | | KYB | Separate corporate/UBO/representative flow. | Private | HOLD for legal-person clients until implemented. | | UK deployment legal basis | Reuse technical identity pipeline only with UK-specific CDD decisioning and privacy mapping. | Private; public 37105 remains minimal | UK MLR/FCA + UK GDPR/DPA 2018 + DPIA + biometric Article 9 condition; CP-38 | | **U.S. deployment identity/biometric** | **Reuse P21 pipeline only after state privacy/biometric + OFAC/tax/obliged-entity mapping; KYB for B2B.** | **Private; public attestation minimal** | **CP-48/49; state-specific consent/retention/human-review** | ## ANNEX K - UK REGULATORY PERIMETER & TRANSITION MATRIX Annex K is the execution matrix for P22. It records BEF's conservative activation position as at 18 August 2026. It is not a legal opinion and does not replace entity-specific FCA/UK counsel analysis. | UK function / scenario | Current position to 24 Oct 2027 | From 25 Oct 2027 target position | 1.0 status | Required evidence / gate | | --- | --- | --- | --- | --- | | Estonian/EEA entity; UK counterparty only; no UK office/agent/other UK activity | FCA current guidance: not automatically carrying on business in UK under MLR territorial test; promotion regime still separate. | Reclassify under final Cryptoassets Regulations/RAO, including final proprietary-trading exclusion; do not assume current territorial outcome carries forward. | CONDITIONAL | CP-32/33/34/35; documented no-UK-presence facts + target/promotion route + final future-perimeter review. | | UK BuyLana.com / Operating Company sells Registered LANA for GBP | Likely current cryptoasset-exchange-provider perimeter if carried on in UK; MLR registration check. Own purchase price is separate from client-money service analysis. | If LANA is qualifying cryptoasset and company deals as principal, FCA permission analysis; UK legal-entity route is default design. | CONDITIONAL | CP-32/34/36 + contract/consumer/refund + fiat ownership + permission map. | | Lana Discount buys selected Registered LANA for own treasury with own capital | Current MLR business/territorial analysis required if activity may be carried on in UK; overseas no-UK-office/agent factor can be relevant. Applicable UK consumer promotions are separate. | Base regime includes dealing as principal, but draft Article 9UA proposes proprietary-trading exclusion where no service is provided to a client in relation to regulated activity on their behalf. Final SI/FCA guidance re-check required. | CONDITIONAL | CP-32/33/34/35/37; P08 no-client-service evidence; Clean Provenance; own capital; T+15 ledger; final Article 9UA/FCA perimeter result. If regulated, HOLD until authorised. | | UK crypto financial promotions | Applies to UK consumer marketing including overseas firms; lawful communication route required. | Continues alongside wider authorisation regime, subject to then-current rules. | HOLD until route implemented | CP-34; route, approver/registration/exemption, warnings/frictions, fair-clear-not-misleading review. | | Registered LANA limited-use argument | Do not rely on UK current limited-use exclusion where holder can transfer/sell beyond issuer redemption conditions. | Future qualifying-cryptoasset classification re-tested under legislation/Handbook then in force. | CONDITIONAL | CP-32 UK legal classification memo. | | Mode B: purchaser pays merchant after separate consumer LANA sale | Separate current crypto + PSR 2017 payment-perimeter analysis; not treated as Lana Discount P08 by default. | Separate future crypto/payment classification; proprietary-trading exclusion cannot be assumed for a client-linked service. | CONDITIONAL | Separate CP-37 Mode B record; linked contracts, merchant discharge, no client-funds pooling, PSP execution. | | UK custody/private-key control | Separate current custody/MLR and contractual analysis. | Safeguarding of qualifying cryptoassets is a regulated activity where in scope. | HOLD unless expressly cleared | Specific custody architecture, CASS/safeguarding analysis, permissions, insolvency treatment. | | UK KYC / biometrics | UK MLR/FCA CDD + UK GDPR/DPA 2018; biometric ID is special-category processing. | Continue under UK law plus requirements applicable to authorised crypto firm. | CONDITIONAL | CP-38; lawful basis, Article 9 condition, DPIA, vendor/IDV validation, retention, human review. | | UK AML Travel Rule | Applicable to relevant UK cryptoasset businesses/transfers under current UK regime. | Continue/update under then-current UK AML/crypto framework. | CONDITIONAL | UK Travel Rule implementation, wallet ownership/control evidence where required, sanctions/SAR process. | | UK Consumer Duty / conduct / complaints | Current financial-promotion controls and general consumer/contract law apply as relevant. | Applicable FCA Handbook conduct/redress rules for permissions sought, including Consumer Duty/COBS/DISP where applicable. | CONDITIONAL | CP-39 product matrix, complaints/FOS mapping, disclosures, support and governance. | | FCA application gateway - only for in-scope activity | Contingency preparation; application period currently 30 Sep 2026-28 Feb 2027 for firms needing authorisation. | Authorisation/saving/transitional status required only if final perimeter shows activity is regulated and no exclusion applies. | CONDITIONAL | CP-35: final perimeter decision first; if in-scope, application/permissions/UK entity/business plan/resources/wind-down. | | **P24 external Native Coin product** | **No blanket UK conclusion from P24 eligibility; classify the exact coin + sale/custody/payment activity and financial promotion.** | **Re-test under then-current qualifying-cryptoasset / principal / custody / payment rules.** | HOLD / CONDITIONAL by product and Split stage | CP-53/54/55/56/57/57 + P22 entity/product record; coin-specific Registrar and Split Profile required before ACTIVE; no automatic carry-over from LANA or another coin. | ## ANNEX L - U.S. FEDERAL PRODUCT & PERIMETER MATRIX Annex L records the U.S. federal activation position as at 18 August 2026. “READY” means the identified federal layer has no unresolved material issue under the stated strict facts; it does not close state law. “HOLD” means no U.S. public/retail activation until the listed gate is completed. | Product / function | 1.0 Federal status | Main U.S. issue | Gate | | --- | --- | --- | --- | | **Underlying LANA** | **CONDITIONAL** | **SEC/CFTC classification; asset vs transaction/scheme; GENIUS stablecoin test** | **CP-40** | | **Registered LANA status** | **CONDITIONAL** | **Must not create profit share/yield/redemption/security rights by overlay** | **CP-40** | | **Lana.discount strict proprietary treasury** | **READY / fact-sensitive** | **FinCEN FIN-2014-R002 own-account baseline; OFAC/IRS separate** | **CP-41/48/47** | | P07 BuyLana.com / Purchase & Delivery | **CONDITIONAL** | **Spot/fixed-delivery possible; investment-contract risk from Split/future-value marketing** | **CP-40/43** | | **P02 direct merchant LANA payment** | **CONDITIONAL** | **Asset classification + tax/consumer; state payment/VC rules** | **CP-42/51** | | **P19 Mode B merchant fiat settlement** | **HOLD** | **Potential MSB/payment processor/state MTL; own-funds label not enough** | **CP-46** | | **Lana8Wonder Growth Phase - retail** | **HOLD** | **Investment-contract/securities + “annuity” terminology + future-value communications** | **CP-43/44/50** | | **Direct.Lana.Fund public/retail** | **HOLD** | **Securities/private fund/adviser/broker/lending/crowdfunding** | **CP-44/50** | | **Donation/grant Common Good** | **CONDITIONAL** | **Charity/tax-deductibility and state solicitation rules; distinguish investment CF** | **CP-45/51** | | **Investment/lending crowdfunding** | **HOLD** | **Reg CF/D/A or other securities route + registered intermediary where required** | **CP-45/50** | | **Customer crypto custody** | **HOLD** | **FinCEN/state VC + securities custody/safeguarding if security** | **CP-52/42** | | **Digital Beings technical assistance** | **CONDITIONAL** | **No unlicensed personalized investment advice/broker/execution/customer-funds role** | **CP-49/52** | | **KYC/biometrics** | **CONDITIONAL** | **Obliged-entity status + state privacy/biometric rules** | **CP-49** | | **Clean Provenance / OFAC** | **CONDITIONAL -> READY after implementation** | **Sanctions screening/escalation applicable to U.S. persons/jurisdiction** | **CP-48** | | **IRS digital-asset reporting** | **CONDITIONAL** | **1099-DA for in-scope customer sales; counterparty tax documentation** | **CP-47** | | **P24 external Native Coin product** | **CONDITIONAL / HOLD by coin & function** | Asset/transaction classification + FinCEN/state MTL + securities/commodity + OFAC/IRS; coin-specific Registrar/Split architecture does not replace legal classification | CP-53/54/55/56/57/57 + state activation | ## ANNEX M - U.S. STATE-BY-STATE ACTIVATION MATRIX Scope limitation: the P08 column addresses only the state money-transmission / virtual-currency licensing layer for the strict proprietary-treasury facts. READY is not blanket legal approval. P07/P02 is a broader direct customer sale/use indicator. Across all states and DC: Mode B is HOLD until CP-46; Lana8Wonder retail and Direct.Lana.Fund public/retail are HOLD until federal securities route + CP-50; custody is HOLD unless separately cleared. | State / DC | P08 strict treasury | P07 BuyLana.com / P02 direct sale/use | Main issue / primary authority | | --- | --- | --- | --- | | Alabama | CONDITIONAL | CONDITIONAL | ASC / Money Transmitter Act; VC/monetary-value transmission regulated; no explicit corporate own-account safe harbor located in source freeze. | | Alaska | CONDITIONAL | CONDITIONAL | AK DCCED, 3 AAC 13; virtual-currency transmission licensing since 2023; direct principal purchase not expressly resolved. | | Arizona | CONDITIONAL | CONDITIONAL | AZ DIFI money-transmitter law; no explicit VC corporate own-account safe harbor located. | | Arkansas | CONDITIONAL | CONDITIONAL / HIGH | Arkansas Money Services Act includes virtual currency/monetary value transmission; written perimeter required. | | California | HOLD | HOLD | DFAL effective licensing 1 Jul 2026; own-behalf exemption is limited to personal/family/household/academic purposes. Corporate treasury needs DFPI determination/licence/exemption analysis. | | Colorado | CONDITIONAL | CONDITIONAL | Colorado MTMA (HB25-1201, effective 2025); no explicit proprietary VC safe harbor located. | | Connecticut | CONDITIONAL | CONDITIONAL / HIGH | CT DOB virtual-currency/money-transmission framework; customer exchange/control risks; written DOB conclusion. | | Delaware | CONDITIONAL / TRANSITION | CONDITIONAL | 2026 Money Transmission & Virtual Currency Modernization changes include own-behalf concepts; final effective implementation/regulatory treatment must be confirmed. | | Florida | READY* | CONDITIONAL | Ch. 560 centers intermediary receipt/transmission to another; strict two-party principal purchase has favorable non-intermediary facts. Confirm no other digital-asset activity. | | Georgia | CONDITIONAL / HIGH | CONDITIONAL / HIGH | GA DBF money-transmitter/MTMA framework; active enforcement in VC market; written state determination before targeting. | | Hawaii | READY* | CONDITIONAL | Hawaii DFI ended state money-transmitter licensing requirement for digital-currency activity after 30 Jun 2024; fiat transmission remains separate. | | Idaho | CONDITIONAL-GREEN | CONDITIONAL | Idaho DFI guidance focuses legal tender accepted for later delivery to third party; strict P08 lacks third-party delivery, but written confirmation prudent. | | Illinois | READY* | CONDITIONAL | Digital Assets and Consumer Protection Act expressly excludes buying/selling/trading digital assets for own account in principal capacity from “Exchange”. | | Indiana | CONDITIONAL | CONDITIONAL / HIGH | IN DFI MTMA/VC questionnaire scrutinizes acceptance, storage, conversion, transmission and private-key control; no explicit own-account exclusion located. | | Iowa | CONDITIONAL | CONDITIONAL | Iowa Code Ch. 533C MTMA; no explicit VC corporate own-account safe harbor located. | | Kansas | READY* | CONDITIONAL | HB 2591, effective 1 Jul 2026, excludes two-party money/virtual-currency exchanges (non-kiosk) from money transmission; “two-party exchange” uses party inventory. | | Kentucky | READY* | CONDITIONAL | Kentucky 2025 legislation excludes exchange of digital assets from money-transmission licensing; securities/consumer laws remain. | | Louisiana | CONDITIONAL-GREEN | CONDITIONAL | Louisiana Virtual Currency Business Act has own-use and other exemptions but corporate commercial fit is fact-specific; OFI classification memo. | | Maine | READY* | CONDITIONAL | 32 M.R.S. §6100-PP expressly exempts person using VC, including investing/buying/selling, solely on the person’s own behalf. | | Maryland | CONDITIONAL-GREEN | CONDITIONAL | MD Office of Financial Regulation money-transmission framework; use formal licensing-predetermination route for strict P08. | | Massachusetts | READY* for B2B / CONDITIONAL individuals | CONDITIONAL | Massachusetts money-transmission consumer scope is primarily personal/family/household; B2B strict P08 materially cleaner. Individual flows need separate review. | | Michigan | CONDITIONAL-GREEN | CONDITIONAL | Michigan MT law focuses receipt for transmission; no explicit VC principal safe harbor located. | | Minnesota | READY* | CONDITIONAL | Minn. Stat. §53B.70 expressly exempts person using VC, including investing/buying/selling, solely on own behalf. | | Mississippi | CONDITIONAL | CONDITIONAL | Mississippi MTMA effective 1 Jul 2025; no explicit VC corporate own-account safe harbor located. | | Missouri | CONDITIONAL-GREEN | CONDITIONAL | Missouri MTMA focuses receipt for transmission/payment instruments/stored value; proprietary VC purchase not expressly addressed. | | Montana | READY* at MT layer | CONDITIONAL | Montana Division of Banking does not regulate money transmitters; securities/consumer/tax law still applies. | | Nebraska | CONDITIONAL | CONDITIONAL | Nebraska Money Transmitters Act updated 2026; no explicit proprietary VC safe harbor located in source freeze. | | Nevada | HOLD / HIGH | HOLD | Nevada FID requires careful licensure determination for crypto businesses facilitating transmission/holding value; strict P08 must receive written state conclusion. | | New Hampshire | READY* at VC-MT layer | CONDITIONAL | RSA 399-G exemptions/guidance are favorable to specified VC activity; confirm strict no-client-payment/no-custody facts and current text. | | New Jersey | CONDITIONAL-GREEN | CONDITIONAL | NJDOBI money-transmitter law focuses receipt of money for transmission for fee/benefit; strict P08 pays own consideration, but no explicit VC own-account ruling located. | | New Mexico | HOLD | HOLD | New Mexico FID guidance has treated business exchange of VC for money/other value with NM persons as licensed money transmission; no reliance on federal own-account ruling alone. | | New York | HOLD | HOLD | 23 NYCRR Part 200 regulates buying/selling VC “as a customer business”; consumer investment exemption does not clearly protect professional corporate treasury dealing with NY residents. NYDFS written/licensed route required. | | North Carolina | CONDITIONAL / HIGH | CONDITIONAL / HIGH | NCCOB regulates transmission of virtual currency and offers exemption/determination process; obtain written determination for P08. | | North Dakota | READY* | CONDITIONAL | ND DFI guidance distinguishes operator-reserve/direct exchange without custody/third-party transmission from money transmission; preserve strict reserve-funded facts. | | Ohio | READY* | CONDITIONAL | Ohio Rev. Code §1315.01(G) excludes transaction where recipient is principal/authorized representative of principal in underlying transaction from “transmit money”. | | Oklahoma | CONDITIONAL | CONDITIONAL | Oklahoma clearly licenses digital-asset kiosks; current public guidance does not definitively resolve non-kiosk proprietary direct purchase. | | Oregon | CONDITIONAL / HIGH | HOLD / CONDITIONAL | Oregon DFR licenses money transmitters and crypto businesses in relevant flows; no official own-account safe harbor located in source freeze. Obtain DFR interpretation. | | Pennsylvania | READY* B2B | CONDITIONAL individuals | Act 7 of 2025 §2(b)(1) excludes money/VC transmission between business entities under commercial contracts unless personal/household individual activity is involved. | | Rhode Island | READY* | CONDITIONAL | R.I. Gen. Laws §19-14.3-1(v) expressly exempts person using VC, including investing/buying/selling, solely on its own behalf. | | South Carolina | CONDITIONAL | CONDITIONAL | SC Uniform Money Services Act 2024; money transmission centers receipt of money/monetary value for transmission; no explicit VC proprietary safe harbor located. | | South Dakota | CONDITIONAL | CONDITIONAL | SD banking money-transmission framework and VC guidance; no explicit corporate proprietary exemption located in source freeze. | | Tennessee | CONDITIONAL-GREEN | CONDITIONAL | TDFI guidance historically distinguishes virtual currency itself from sovereign-currency money transmission, but exchange/admin fiat legs can be regulated; written confirmation. | | Texas | CONDITIONAL-GREEN | CONDITIONAL | Texas virtual-currency supervisory guidance distinguishes direct two-party own-account facts from third-party transmission, but current Ch. 152/2026 changes should be confirmed per launch. | | Utah | CONDITIONAL-GREEN | CONDITIONAL | Utah has blockchain-token exclusions; READY requires documented conclusion that LANA satisfies statutory token definition and transaction facts. | | Vermont | HOLD | HOLD | Vermont own-use exemption is limited to personal/family/household/academic purposes; corporate proprietary treasury not expressly protected. DFR exemption/order/licence route. | | Virginia | CONDITIONAL-GREEN | CONDITIONAL | Virginia Bureau guidance does not regulate virtual currencies as such; fiat transmission can trigger law. Strict principal purchase favorable but written state memo recommended. | | Washington | CONDITIONAL / HIGH | HOLD / CONDITIONAL | RCW 19.230 includes virtual currency in “equivalent value” received for transmission; exchanges/storage can be licensable. Strict two-party principal flow needs DFI exclusion analysis; licensing structure can require U.S. entity. | | West Virginia | READY* at MT layer | CONDITIONAL | WV currency-transmission definition centers receipt for purpose of transmitting; strict P08 own consideration/no transmission is favorable. Confirm current commissioner position. | | Wisconsin | CONDITIONAL-GREEN | CONDITIONAL | WI DFI treats fiat-to-VC delivery to third-party wallet as money transmission; strict P08 direct principal treasury differs, but DFI safe-harbor letters are limited—counsel classification. | | Wyoming | CONDITIONAL-GREEN | CONDITIONAL | Wyoming money-transmitter/digital-asset framework; no explicit corporate own-account VC safe harbor located in retrieved primary materials. Written Division/counsel position. | | District of Columbia | HOLD / HIGH | HOLD | DC DISB regulates money transmission and has treated VC transmission as licensable; direct proprietary purchase not expressly resolved. Written DISB conclusion before targeting. | ## ANNEX N - U.S. ACTIVATION GROUPS, SOURCE FREEZE & DEPLOYMENT CHECKLIST State groupings are operational triage, not legal conclusions. Any material factual change can move a state to a stricter group. | Group | States | Deployment rule | | --- | --- | --- | | Group A - strongest own-account/principal/B2B basis | Florida; Illinois; Kansas; Kentucky; Maine; Minnesota; North Dakota; Ohio; Pennsylvania (B2B); Rhode Island | P08 may activate after CP-40/41/47/48 and state record; no customer-service drift. | | Group B - low/separate state VC-MT burden | Hawaii; Montana; New Hampshire; West Virginia | Confirm current regulator position and non-MT federal/state overlays. | | Group C - favorable but fact-specific | Idaho; Louisiana; Maryland; Massachusetts (B2B); New Jersey; Tennessee; Texas; Utah; Virginia; Wisconsin; Delaware (transition) | Obtain written counsel/regulator classification before targeting. | | Group D - general MT/MTMA, no explicit safe harbor located | Alabama; Alaska; Arizona; Arkansas; Colorado; Connecticut; Georgia; Indiana; Iowa; Michigan; Mississippi; Missouri; Nebraska; Oklahoma; South Carolina; South Dakota; Wyoming | CONDITIONAL; no launch by assumption from silence. | | Group E - high-friction / HOLD | California; Nevada; New Mexico; New York; North Carolina; Oregon; Vermont; Washington; District of Columbia | No targeted P08 launch until licence/exemption/written determination is closed. | ### U.S. deployment checklist • Identify exact U.S. legal entity, seller/counterparty type and state residence/place of business. • Confirm CP-40 asset/transaction classification and whether LANA/overlay is a security, digital commodity, payment stablecoin or other asset. • For P08, certify CP-41 factual invariants: own capital, own account, no customer custody/accounts/orders, direct treasury ownership, discretionary acceptance and independent resale risk. • Open/refresh State Activation Record for the target state using current statute/regulator guidance; do not use Annex M beyond its source-freeze without re-check. • Run OFAC/Clean Provenance and applicable KYB/KYC/tax documentation before acceptance. • Ensure website/UI terminology matches P08: Treasury Acquisition / Purchase Offer / Seller / Counterparty; no Exchange/Cash-out/Guaranteed Buyback/client balance language. • For P07, use BuyLana.com / Buy Registered LANA terminology; identify the actual seller before purchase; show fixed quantity, price/basis, Split, wallet, delivery/refund terms; no Exchange/Fund/Guaranteed Return/Guaranteed Liquidity language. • Block Mode B, custody, Lana8Wonder retail and Direct.Lana.Fund public/retail unless the relevant HOLD gate is formally closed. • Approve U.S. communications under SEC/state anti-fraud and consumer standards; remove guaranteed Split/future-value claims. • Record bank/PSP, fiat owner, crypto owner, settlement timing, transaction hash and accounting treatment. • Set next legal review date and Regulatory Change Trigger owner. _**• For P24 external Native Coins, open a separate Coin Integration Profile and COIN x PRODUCT x STATE record; do not inherit LANA, BTC or another coin’s classification.**_ ### Source-freeze rule Federal and state U.S. legal/source freeze for Annexes L-N: 18 August 2026. Because state digital-asset statutes are changing rapidly, a READY* row is operational permission only after a fresh pre-launch verification. No row is a regulator approval, legal opinion or guarantee that a court/regulator will adopt the same characterization. ## _**ANNEX O - INITIAL NATIVE COIN CANDIDATE REGISTRY**_ _**Annex O is an initial technical candidate registry for P24 as of 19 August 2026. “Priority A/B” is implementation priority only. No external coin becomes ACTIVE merely by appearing in this table. Every activation requires CP-53 to CP-57, a Coin Integration Profile, a coin-specific Registrar, REGISTRY READY and SPLIT READY status, and a COIN x PRODUCT x JURISDICTION record.**_ | Coin | Native network | Wallet/account model | Direct key control | P24 status | BEF note | | --- | --- | --- | --- | --- | --- | | **LANA** | **LanaCoin** | **UTXO / native wallet** | **Private key / WIF / seed-compatible wallet** | REFERENCE IMPLEMENTATION - LOW PRICE | Existing BEF native reference implementation. \| 1.0 transaction price band: LOW PRICE / reference implementation \| 1.0 Nostr gate: NOSTR COMPATIBLE - secp256k1 family / Bitcoin-like key model; verify BIP-340 signing path | | **BTC** | **Bitcoin** | **UTXO / HD** | **Private key or seed; direct signing** | PRIORITY A - MID PRICE | Canonical direct-key self-custody; multiple addresses under HD wallet are permitted. \| 1.0 transaction price band: MID PRICE (~EUR 0.078 reference) \| 1.0 Nostr gate: NOSTR COMPATIBLE - secp256k1 private key can sign BIP-340 Schnorr events | | **ETH** | **Ethereum** | **Account / EOA** | **Private key or seed; direct signing** | PRIORITY A - HIGH PRICE | Native ETH only; ERC-20 assets excluded from P24. \| 1.0 transaction price band: HIGH PRICE (~EUR 0.354 reference) \| 1.0 Nostr gate: NOSTR COMPATIBLE - secp256k1 key material; BIP-340 Schnorr signing path required | | **BNB** | **BNB Smart Chain** | **EVM account** | **Private key or recovery phrase** | REMAINS INTERESTING | Native BNB on BSC; BEP-20 tokens excluded. \| 1.0 transaction price band: LOW PRICE on stated reference; live base fee applies \| 1.0 Nostr gate: NOSTR COMPATIBLE - EVM secp256k1 key material; BIP-340 signing path required | | **XRP** | **XRP Ledger** | **Account / keypair** | **Secret/private key; direct signing** | CONDITIONAL CANDIDATE | Native XRP; destination-tag handling required where applicable. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: CONDITIONAL NOSTR COMPATIBLE - only secp256k1 XRPL accounts; Ed25519 XRPL accounts are NOSTR INCOMPATIBLE | | **SOL** | **Solana** | **Account / keypair** | **Private key/seed; direct signing** | NOT COMPATIBLE WITH NOSTR | Native SOL only; SPL tokens excluded. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: NOSTR INCOMPATIBLE - standard Solana accounts use Ed25519 | | **TRX** | **TRON** | **Account** | **Private key or mnemonic** | PRIORITY A - RESOURCE-CONDITIONAL LOW/MID PRICE | Native TRX only; TRC tokens excluded. \| 1.0 transaction price band: LOW PRICE with bandwidth/resources; MID PRICE unstaked fallback \| 1.0 Nostr gate: NOSTR COMPATIBLE - TRON uses secp256k1 key material; BIP-340 signing path required | | **HYPE** | **Hyperliquid L1** | **0x wallet/account + native L1** | **Wallet private key / signer** | NOT ACTIVE - LIVE FEE GATE | Native HYPE path only; API/agent wallets must not be confused with custody. \| 1.0 transaction price band: LIVE PRICE GATE \| 1.0 Nostr gate: NOSTR COMPATIBLE / ADAPTER - EVM-style 0x signer path must be evidenced | | **DOGE** | **Dogecoin** | **UTXO / HD** | **Private key/seed; Core-compatible self-custody** | REMAINS INTERESTING | Native DOGE. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: NOSTR COMPATIBLE - secp256k1 key material; BIP-340 signing path required | | **ADA** | **Cardano** | **eUTXO / HD** | **Signing key / recovery seed** | NOT COMPATIBLE WITH NOSTR - MID PRICE | Native ADA; wallet may use multiple addresses. \| 1.0 transaction price band: MID PRICE \| 1.0 Nostr gate: NOSTR INCOMPATIBLE - Cardano wallet keys use Ed25519/BIP32-Ed25519 | | **XLM** | **Stellar** | **Account / keypair** | **Secret key / seed** | NOT COMPATIBLE WITH NOSTR | Native XLM; memo handling where required. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: NOSTR INCOMPATIBLE - Stellar accounts use Ed25519 | | **BCH** | **Bitcoin Cash** | **UTXO / HD** | **Private key / seed** | REMAINS INTERESTING | Native BCH; CashAddr/network validation required. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: NOSTR COMPATIBLE - secp256k1 key material; BIP-340 signing path required | | **GRAM** | **TON (formerly Toncoin naming)** | **Smart-contract wallet / account** | **Mnemonic-derived keypair** | NOT COMPATIBLE WITH NOSTR - LOW/MID PRICE | Native network coin; wallet is a smart contract and requires TON-specific deployment/address logic. \| 1.0 transaction price band: LOW-MID PRICE range; live estimator required \| 1.0 Nostr gate: NOSTR INCOMPATIBLE - TON wallets use Ed25519 | | **LTC** | **Litecoin** | **UTXO / HD** | **Private key / seed** | REMAINS INTERESTING | Native LTC. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: NOSTR COMPATIBLE - secp256k1 key material; BIP-340 signing path required | | **HBAR** | **Hedera** | **Account ID / key** | **Private key / recovery-compatible wallet** | CONDITIONAL CANDIDATE | Native HBAR; account-ID/key mapping is chain-specific. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: CONDITIONAL NOSTR COMPATIBLE - only ECDSA secp256k1 Hedera accounts; Ed25519 accounts are incompatible | | **AVAX** | **Avalanche Primary Network** | **Multi-chain X/P/C; EVM on C-Chain** | **Private key/seed; direct signing** | REMAINS INTERESTING | Native AVAX; initial adapter should explicitly select the supported Avalanche chain context. \| 1.0 transaction price band: LOW PRICE / C-Chain \| 1.0 Nostr gate: NOSTR COMPATIBLE - C-Chain/Avalanche secp256k1 path; domain must be selected | | **DOT** | **Polkadot** | **Account / Substrate keypair** | **Seed/private key** | NOT ACTIVE - LIVE FEE GATE | Native DOT; SS58/network prefix must be validated. \| 1.0 transaction price band: LIVE PRICE GATE \| 1.0 Nostr gate: CONDITIONAL / NOT DEFAULT - only ECDSA account keys; ordinary sr25519/ed25519 accounts are incompatible | | **ALGO** | **Algorand** | **Account** | **Private key / 25-word mnemonic** | NOT COMPATIBLE WITH NOSTR | Native ALGO. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: NOSTR INCOMPATIBLE - Algorand accounts use Ed25519 | | **ETC** | **Ethereum Classic** | **EVM account** | **Private key / seed** | NOT ACTIVE - LIVE FEE GATE | Native ETC on Ethereum Classic; chain ID separation from Ethereum required. \| 1.0 transaction price band: LIVE PRICE GATE \| 1.0 Nostr gate: NOSTR COMPATIBLE - EVM secp256k1 key material; BIP-340 signing path required | | **SUI** | **Sui** | **Object-centric account/address** | **Private key / seed** | CONDITIONAL CANDIDATE | Direct self-custody fits, but object/transaction model requires dedicated adapter. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: CONDITIONAL NOSTR COMPATIBLE - only Secp256k1 Sui keypairs; Ed25519/Secp256r1 accounts are incompatible | | **NEAR** | **NEAR Protocol** | **Named/implicit account + access keys** | **Private/access key / seed** | CONDITIONAL CANDIDATE | Multiple access-key semantics require explicit ownership/signing profile. \| 1.0 transaction price band: LOW PRICE / LIVE \| 1.0 Nostr gate: CONDITIONAL NOSTR COMPATIBLE - only secp256k1 access keys; ordinary Ed25519 keys are incompatible | | **TAO** | **Bittensor / Subtensor** | **Substrate-style wallet/account** | **Mnemonic/private key** | NOT ACTIVE - LIVE FEE GATE | Native TAO; staking/subnet semantics require separation from transferable balance. \| 1.0 transaction price band: LIVE PRICE GATE \| 1.0 Nostr gate: NOSTR INCOMPATIBLE - Substrate sr25519/ed25519 identity is not NIP-01 secp256k1 | | **ATOM** | **Cosmos Hub** | **Account / Cosmos SDK** | **Mnemonic/private key** | REMAINS INTERESTING | Native ATOM; chain-id and IBC representations must be distinguished. \| 1.0 transaction price band: LOW PRICE / LIVE \| 1.0 Nostr gate: NOSTR COMPATIBLE - Cosmos SDK default user accounts use secp256k1 | | **KAS** | **Kaspa** | **UTXO / HD** | **Private key / seed** | REMAINS INTERESTING | Native KAS; DAG/finality and multi-address handling require dedicated policy. \| 1.0 transaction price band: LOW PRICE \| 1.0 Nostr gate: NOSTR COMPATIBLE - Kaspa secp256k1/Schnorr family; verify exact BIP-340 profile | | **FIL** | **Filecoin** | **Account / address types** | **Private key / wallet keys** | NOT ACTIVE - LIVE FEE GATE | Native FIL; storage-network address types and finality need dedicated adapter. \| 1.0 transaction price band: LIVE PRICE GATE \| 1.0 Nostr gate: CONDITIONAL NOSTR COMPATIBLE - Filecoin secp256k1 addresses only; BLS addresses are incompatible | | **APT** | **Aptos** | **Account** | **Private key / seed; key rotation possible** | NOT ACTIVE - LIVE FEE GATE | Native APT; authentication-key rotation must be reflected in ownership proof. \| 1.0 transaction price band: LIVE PRICE GATE \| 1.0 Nostr gate: CONDITIONAL NOSTR COMPATIBLE - only Secp256k1 authentication scheme; Ed25519 default is incompatible | | **XTZ** | **Tezos** | **Account** | **Private key / seed** | NOT ACTIVE - LIVE FEE GATE | Native XTZ; implicit/originated account distinction must be handled. \| 1.0 transaction price band: LIVE PRICE GATE \| 1.0 Nostr gate: CONDITIONAL NOSTR COMPATIBLE - tz2/Secp256k1 accounts only; Ed25519 and P256 accounts are incompatible | | **ICP** | **Internet Computer** | **Principal / ledger account model** | **Cryptographic identity / signing keys** | NOT COMPATIBLE WITH NOSTR | Native ICP, but wallet/account identity model is less directly equivalent to a simple key-address wallet; dedicated proof model required. \| 1.0 transaction price band: LOW PRICE / RESEARCH \| 1.0 Nostr gate: NOSTR INCOMPATIBLE / RESEARCH - principal/ledger identity model is not direct NIP-01 key alignment | | **XMR** | **Monero** | **Privacy wallet** | **Private spend/view keys / seed** | NOT ACTIVE - LIVE FEE GATE | Native and self-custodial, but default privacy conflicts with BEF provenance/transparent registry requirements unless a compliant evidence design is proven. \| 1.0 transaction price band: LIVE PRICE GATE + P24 HOLD \| 1.0 Nostr gate: NOSTR INCOMPATIBLE - Monero key model is not NIP-01 secp256k1 Schnorr | | **ZEC** | **Zcash** | **Transparent + shielded wallet models** | **Spending keys / seed** | P24 HOLD - MID PRICE | Native and self-custodial, but shielded flows require provenance/Registrar evidence design before activation. \| 1.0 transaction price band: MID PRICE + P24 HOLD \| 1.0 Nostr gate: PARTIAL / HOLD - transparent keys may be secp256k1; shielded keys are not direct Nostr-compatible | _**Technical verification basis**_ _**The candidate registry was cross-checked against primary protocol/core documentation where available, including Bitcoin Core, Ethereum, BNB Chain, XRP Ledger, Solana, Cardano, TRON, Stellar, Avalanche, Hedera, Polkadot, Algorand, Sui, NEAR, Aptos, Cosmos Hub, Tezos/Octez, Kaspa, TON and Hyperliquid documentation, plus official/core wallet repositories for Bitcoin-family and related chains. Final production onboarding requires fresh source verification under CP-53.**_ ## _**ANNEX P - NATIVE COIN MARKET SNAPSHOT & TECHNICAL VERIFICATION NOTES**_ Informational market snapshot only — 19 August 2026. Prices are USD spot indications from the available current crypto market feed; market capitalisations are rounded USD snapshots from CoinGecko on the same date. Provider timestamps may differ, so price and market-cap columns are not intended as a mathematically reconciled pair. These values are volatile, non-normative and create no BEF price, return, liquidity or buyback right. Annex Q in Framework 1.0 deliberately retains the 0.23 this frozen USD snapshot for internally consistent atomic-unit EUR calculations and applies the ECB EUR/USD reference rate stated in Annex Q; it does not overwrite Annex P with a later intraday quote. | Coin | USD price snapshot | Approx. market cap | P24 status | | --- | --- | --- | --- | | **BTC** | $64,420 | ~$1.29T | **PRIORITY A** | | **ETH** | $1,624.95 | ~$231.2B | **PRIORITY A** | | **BNB** | $602.54 | ~$80.1B | **PRIORITY A** | | **XRP** | $1.059 | ~$62.9B | **PRIORITY A** | | **SOL** | $77.97 | ~$45.0B | **PRIORITY A** | | **TRX** | $0.315538 | ~$31.6B | **PRIORITY A** | | **HYPE** | $63.35 | ~$13.0B | **PRIORITY A** | | **DOGE** | $0.070198 | ~$10.9B | **PRIORITY A** | | **ZEC** | $419.03 | ~$8.54B | **HOLD** | | **XMR** | $307.14 | ~$7.79B | **HOLD** | | **ADA** | $0.175003 | ~$6.58B | **PRIORITY A** | | **XLM** | $0.206853 | ~$5.41B | **PRIORITY A** | | **BCH** | $203.71 | ~$4.08B | **PRIORITY A** | | **GRAM** | $1.57 | ~$3.64B | **PRIORITY A / SPECIAL** | | **LTC** | $42.80 | ~$3.46B | **PRIORITY A** | | **HBAR** | $0.072719 | ~$2.95B | **PRIORITY A** | | **AVAX** | $6.37 | ~$2.75B | **PRIORITY A / C-CHAIN FIRST** | | **SUI** | $0.727269 | ~$2.68B | **PRIORITY B** | | **NEAR** | $1.90 | ~$2.11B | **PRIORITY B** | | **TAO** | $204.94 | ~$1.84B | **PRIORITY B** | | **DOT** | $0.760988 | ~$1.29B | **PRIORITY A** | | **ICP** | $2.17 | ~$1.23B | **RESEARCH** | | **ETC** | $7.02 | ~$0.964B | **PRIORITY A** | | **ATOM** | $1.41 | ~$0.741B | **PRIORITY B** | | **ALGO** | $0.079328 | ~$0.716B | **PRIORITY A** | | **KAS** | $0.03083566 | ~$0.711B | **PRIORITY B** | | **FIL** | $0.748423 | ~$0.522B | **PRIORITY B** | | **APT** | $0.530923 | ~$0.455B | **PRIORITY B** | | **XTZ** | $0.223958 | ~$0.229B | **PRIORITY B** | _**Market-data discipline**_ _**Annex P is deliberately separated from the normative protocol. Market data must be refreshed before any concrete offer, treasury mandate, merchant conversion or public communication. External-coin prices are market references only. Every ACTIVE coin may have its own BEF System / Reference Value or other value-transition methodology inside its Coin Split Profile, and that internal value must be clearly separated from external spot price and from LANA-specific Split parameters.**_ ## ANNEX Q - ATOMIC UNIT & TRANSACTION FEE ECONOMICS MATRIX Annex Q is an operational economics snapshot for P24 candidate selection as of 19 August 2026. It answers two separate questions: (1) how small the native ledger can represent value, and (2) what a practical standard native transfer costs. These are not the same thing. A chain can have an extremely small atomic unit and still impose material gas, reserve, dust, activation or storage costs. ### EUR methodology For internal consistency, atomic-unit EUR values use the USD price snapshot already frozen in Annex P and the latest published ECB reference rate available at preparation time: EUR 1 = USD 1.1576 on 18 August 2026 (USD 1 ≈ EUR 0.863856). These values are informational snapshots only and must be refreshed before activation, pricing, merchant settlement or public communication. LANA is intentionally not assigned an external spot value in this annex; its atomic-unit EUR value depends on the explicitly selected BEF System / Reference Value or separately identified external market price. ### Q.1 Atomic Unit Economics | Coin | Smallest canonical unit | Precision | Annex P price basis (USD) | 1 atomic unit in EUR* | Important note | | --- | --- | --- | --- | --- | --- | | LANA | base unit / 1e-8 LANA | 8 decimals | BEF System / Reference or selected external price | BEF value ÷ 100,000,000 | Reference coin; do not mix BEF System Value with external market price. | | BTC | satoshi | 8 decimals | $64,420 | €0.0005565 | Atomic unit ≠ practical minimum transfer. Reference transaction price band: MID PRICE. | | ETH | wei | 18 decimals | $1,624.95 | €1.404e-15 | Atomic unit ≠ practical minimum transfer. Reference transaction price band: HIGH PRICE. | | BNB | wei (BSC) | 18 decimals | $602.54 | €5.205e-16 | Atomic unit ≠ practical minimum transfer. | | XRP | drop | 6 decimals | $1.059 | €0.0000009148 | Atomic unit ≠ practical minimum transfer. | | SOL | lamport | 9 decimals | $77.97 | €0.0000000674 | Atomic unit ≠ practical minimum transfer. | | TRX | sun | 6 decimals | $0.315538 | €0.0000002726 | Atomic unit ≠ practical minimum transfer. LOW PRICE with available bandwidth/resources; unstaked fallback is MID PRICE on the stated example. | | HYPE | HyperCore unit / HyperEVM wei | 8 / 18 decimals | $63.35 | €0.0000005473 (HyperCore); €5.473e-17 (HyperEVM) | P24 adapter must select domain explicitly. | | DOGE | koinu / 1e-8 DOGE | 8 decimals | $0.070198 | €6.064e-10 | Atomic unit ≠ practical minimum transfer. | | ZEC | zatoshi | 8 decimals | $419.03 | €0.00000362 | Atomic unit ≠ practical minimum transfer. Reference transaction price band: MID PRICE; separate privacy/provenance HOLD remains. | | XMR | atomic unit / piconero | 12 decimals | $307.14 | €2.653e-10 | Atomic unit ≠ practical minimum transfer. | | ADA | lovelace | 6 decimals | $0.175003 | €0.0000001512 | Atomic unit ≠ practical minimum transfer. Reference transaction price band: MID PRICE. | | XLM | stroop | 7 decimals | $0.206853 | €0.0000000179 | Atomic unit ≠ practical minimum transfer. | | BCH | satoshi | 8 decimals | $203.71 | €0.00000176 | Atomic unit ≠ practical minimum transfer. | | GRAM | nanogram | 9 decimals | $1.57 | €0.0000000014 | Atomic unit ≠ practical minimum transfer. Stated reference range spans LOW PRICE to MID PRICE; use live TON estimator. | | LTC | litoshi | 8 decimals | $42.8 | €0.0000003697 | Atomic unit ≠ practical minimum transfer. | | HBAR | tinybar | 8 decimals | $0.072719 | €6.282e-10 | Atomic unit ≠ practical minimum transfer. | | AVAX | wei on C-Chain | 18 decimals | $6.37 | €5.503e-18 | C-Chain precision shown; other Avalanche domains can use different denomination conventions. | | SUI | MIST | 9 decimals | $0.727269 | €6.283e-10 | Atomic unit ≠ practical minimum transfer. | | NEAR | yoctoNEAR | 24 decimals | $1.9 | €1.641e-24 | Atomic unit ≠ practical minimum transfer. | | TAO | rao | 9 decimals | $204.94 | €0.000000177 | Atomic unit ≠ practical minimum transfer. | | DOT | Planck | 10 decimals | $0.760988 | €6.574e-11 | Atomic unit ≠ practical minimum transfer. | | ICP | e8s | 8 decimals | $2.17 | €0.0000000187 | Atomic unit ≠ practical minimum transfer. | | ETC | wei | 18 decimals | $7.02 | €6.064e-18 | Atomic unit ≠ practical minimum transfer. | | ATOM | uatom | 6 decimals | $1.41 | €0.00000122 | Atomic unit ≠ practical minimum transfer. | | ALGO | microAlgo | 6 decimals | $0.079328 | €0.0000000685 | Atomic unit ≠ practical minimum transfer. | | KAS | sompi | 8 decimals | $0.03083566 | €2.664e-10 | Atomic unit ≠ practical minimum transfer. | | FIL | attoFIL | 18 decimals | $0.748423 | €6.465e-19 | Atomic unit ≠ practical minimum transfer. | | APT | octa | 8 decimals | $0.530923 | €0.0000000046 | Atomic unit ≠ practical minimum transfer. | | XTZ | mutez | 6 decimals | $0.223958 | €0.0000001848 | Atomic unit ≠ practical minimum transfer. | ### Q.2 Standard Native Transfer Economics The “Indicative EUR cost” is a representative simple-transfer reference, not a promise of future fees and not automatically a 30-day historical average. Evidence A = fixed/current protocol figure or direct official network reference; B = protocol formula or official representative example converted to the Annex P price basis; L = live dynamic estimator required. Where the fee is dynamic, CP-58 requires rolling 30-day median/mean and P95 before ACTIVE consumer use. | Coin | Standard transfer cost basis | Native/reference fee | Indicative EUR cost* | Transaction price band | Evidence | | --- | --- | --- | --- | --- | --- | | BTC | 141 sat @ 1 sat/vB, ~141 vB reference simple P2WPKH transfer | 0.00000141 BTC | €0.07847 | MID PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | ETH | 21,000 gas × 12 gwei official-doc example (10 base + 2 tip); live gas can differ | 0.000252 ETH | €0.354 | HIGH PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | BNB | 21,000 gas × 0.05 gwei priority-floor-only reference; base fee adds dynamically | ~0.00000105 BNB floor | €0.0005465 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | XRP | Standard minimum transaction cost reference: 10 drops; can rise under load | 0.00001 XRP | €0.0000091 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | SOL | Base fee 5,000 lamports per signature; priority fee may add | 0.000005 SOL | €0.0003368 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | TRX | Bandwidth model: can be zero with free/staked Bandwidth; ~270 B fallback example burns ~0.27 TRX | 0 to ~0.27 TRX | €0 – €0.0736 | LOW PRICE with resources / MID PRICE fallback | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | HYPE | HyperEVM base/priority gas is dynamic; use live eth_gasPrice / transaction simulation | LIVE | LIVE / n.a. | LIVE PRICE GATE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. L \| | | DOGE | Recommended 0.01 DOGE/kB; ~192-byte simple example | ~0.00192 DOGE | €0.0001164 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | ZEC | ZIP-317 conventional-fee baseline for simple transparent-style transfer; verify action count | ~0.0001 ZEC | €0.0362 | MID PRICE + P24 HOLD | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | XMR | Dynamic fee by transaction weight and congestion; wallet RPC estimates actual fee | LIVE | LIVE / n.a. | LIVE PRICE GATE + P24 HOLD | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. L \| | | ADA | Protocol fee = a × tx-size + b; ~0.17 ADA representative simple transfer | ~0.17 ADA | €0.0257 | MID PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | XLM | Minimum base fee 100 stroops per operation; simple payment = one operation | 0.00001 XLM | €0.0000018 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | BCH | Relay-floor reference 1,000 sat/kB; ~192-byte simple transaction | ~0.00000192 BCH | €0.0003379 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | GRAM | TON/Gram fee components are dynamic; official example shows ~0.005 gas + 0.01 forwarding; use estimator | ~0.005–0.015 GRAM | €0.00678 – €0.02034 | LOW-MID PRICE RANGE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | LTC | Litecoin official material describes average transaction fee as below USD 0.01; wallet estimator remains source for live fee | < USD 0.01 equivalent | €0.00864 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | HBAR | Hedera CryptoTransfer base fee for standard single-signature transfer | USD 0.0001 paid in HBAR | €0.0000864 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | AVAX | C-Chain typical simple-transfer cost reference ~USD 0.001; live base fee applies | ~USD 0.001 equivalent | €0.0008639 | LOW PRICE / C-CHAIN | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | SUI | Official basic-transaction gas example: 1,075,000 MIST net gas fee | ~0.001075 SUI | €0.0006754 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | NEAR | Official common-action table at minimum gas price: transfer = 0.000045 NEAR; gas price dynamic by block | 0.000045 NEAR | €0.0000739 | LOW PRICE / LIVE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | TAO | Substrate-style transaction fee is dynamic; query/preview current chain fee before signing | LIVE | LIVE / n.a. | LIVE PRICE GATE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. L \| | | DOT | Weight/length/congestion-dependent extrinsic fee; query paymentInfo / runtime before send | LIVE | LIVE / n.a. | LIVE PRICE GATE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. L \| | | ICP | ICP ledger reference fee 10,000 e8s; query icrc1_fee because fee can change at runtime | 0.0001 ICP | €0.0001875 | LOW PRICE / RESEARCH | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | ETC | EVM transfer = 21,000 gas × live gas price; no static average hard-coded | LIVE | LIVE / n.a. | LIVE PRICE GATE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. L \| | | ATOM | Cosmos Hub fee is gas × chosen/accepted gas price; docs show 0.0025 uatom gas-price example | Illustrative ~0.0002 ATOM at 80k gas | €0.0002436 | LOW PRICE / LIVE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. B \| | | ALGO | Protocol minimum transaction fee reference 0.001 ALGO for normal transaction | 0.001 ALGO | €0.0000685 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | KAS | Kaspa wiki: current minimum 1 sompi/gram; typical transaction ~0.000023 KAS | ~0.000023 KAS | €0.000000613 | LOW PRICE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. A \| | | FIL | Filecoin message fee uses dynamic gas/base-fee/premium model; estimate from live chain | LIVE | LIVE / n.a. | LIVE PRICE GATE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. L \| | | APT | gas_used × gas_unit_price + storage; simulate to estimate current transaction cost | LIVE | LIVE / n.a. | LIVE PRICE GATE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. L \| | | XTZ | Manager-operation fee/gas/storage is dynamic; wallet/Octez estimates current cost | LIVE | LIVE / n.a. | LIVE PRICE GATE | 1.0 bands (unchanged thresholds): LOW < EUR 0.01; MID EUR 0.01-EUR 0.30 inclusive; HIGH > EUR 0.30. L \| | On the retained 0.23 reference basis, transaction cost is classified rather than used as a binary exclusion. Most measured networks fall in LOW PRICE (< EUR 0.01). BTC (~EUR 0.078), ZEC (~EUR 0.036) and ADA (~EUR 0.026) fall in MID PRICE; the stated unstaked TRX fallback is also MID PRICE. ETH (~EUR 0.354 on the stated example) falls in HIGH PRICE. GRAM/TON spans LOW to MID on the stated range. Networks with insufficiently stable static evidence remain LIVE PRICE GATE. These bands address transaction economics only and do not override Nostr, Registrar, Split, legal, provenance or privacy gates. On the retained 0.23 reference basis, transaction cost is classified rather than used as a binary exclusion. Most measured networks fall in LOW PRICE (< EUR 0.01). BTC (~EUR 0.078), ZEC (~EUR 0.036) and ADA (~EUR 0.026) fall in MID PRICE; the stated unstaked TRX fallback is also MID PRICE. ETH (~EUR 0.354 on the stated example) falls in HIGH PRICE. GRAM/TON spans LOW to MID on the stated range. Networks with insufficiently stable static evidence remain LIVE PRICE GATE. These bands address transaction economics only and do not override Nostr, Registrar, Split, legal, provenance or privacy gates. ### Q.4 Practical Minimum Is a Separate Metric Before a coin is selected for merchant or micro-payment use, CP-58 must additionally record minimum output/dust rules, existential deposit or reserve, recipient-account activation, minimum UTXO/state value, storage/rent deposits, fee rebates and the cost of sending to a new account. These constraints can dominate economics even when the raw network fee is tiny. ### Primary technical/source basis for Annex Q • European Central Bank, Euro foreign exchange reference rates (18 Aug 2026): EUR 1 = USD 1.1576. • Bitcoin Core RPC fee estimation and standard UTXO fee-rate model; reference simple P2WPKH size used only as an engineering comparator. • Ethereum.org gas documentation: simple ETH transfer gas and EIP-1559 base/priority fee model. • BNB Chain fee documentation: EVM gas model and current priority-fee floor mechanics. • XRP Ledger transaction-cost documentation: drops and standard minimum transaction cost. • Solana documentation: lamports and base transaction fee per signature. • TRON Developer Hub: 1 TRX = 1,000,000 sun; Bandwidth/Energy resource model and fallback TRX burn. • Hyperliquid Docs: HYPE on HyperCore/HyperEVM, weiDecimals and dynamic EVM gas. • Dogecoin Core fee recommendation/reference policy. • Cardano Docs: 1 ADA = 1,000,000 lovelace and protocol transaction-fee parameter model. • Stellar Developers: stroops and per-operation base fee. • Bitcoin Cash Node / protocol fee policy: satoshi-based relay fee reference. • TON Docs: Gram native currency, nanograms, fee estimation and forwarding/gas components. • Litecoin official materials: low transaction fee / wallet estimator guidance. • Hedera Docs: CryptoTransfer base fee USD 0.0001 paid in HBAR. • Avalanche Builder Hub: C-Chain EVM gas/AVAX fee mechanics. • Sui Docs: MIST and gas-budget/reference-gas-price examples. • NEAR Docs: yoctoNEAR, dynamic gas price and common-action transfer cost table. • Polkadot Developer Docs: Planck and runtime/paymentInfo fee estimation. • Internet Computer Docs: ICP e8s and icrc1_fee; ICP reference ledger fee 10,000 e8s. • Cosmos Hub Docs: uatom and gas-price based transaction fee configuration. • Algorand developer documentation: microAlgo and protocol minimum transaction fee. • Kaspa Wiki/protocol documentation: sompi and current fee-rate/typical transaction reference. • Filecoin Docs: attoFIL and dynamic gas fee model. • Aptos Docs: octas, gas_used × gas_unit_price and simulation. • Tezos Docs: mutez and manager-operation fee mechanics. • Monero official wallet RPC/user guides: 1 XMR = 1e12 atomic units and weight/congestion-dependent fee estimation. • Zcash ZIP-317 fee standard: zatoshi/action-based conventional fee model. ## ANNEX R - 0.22 REVISION INTEGRITY REVIEW Revision objective: confirm that the 0.22 economics extension is additive and that no material 0.20 architecture was removed. | Area | 0.22 review result | Integrity note | | --- | --- | --- | | Core BEF / Balanced Economy | RETAINED | Core purpose, Exchange/Alignment/Self-Responsibility, Common Good, transparency and Living Framework hierarchy retained. | | P01-P23 | RETAINED | All previous Registrar, merchant, Split, funding, OWN, Purchase & Delivery, Treasury, technology, KYC, EU/UK/U.S. controls remain present. | | BuyLana.com / P07 | RETAINED | BuyLana.com remains LANA-specific Purchase & Delivery user-facing service; 0.22 does not convert it into a multi-coin exchange. | | P24 Balanced Native Coin model | RETAINED + STRENGTHENED | Coin-specific Registrar, Registered Coin, Active Coin Supply, Split Profile, Split history and COIN x PRODUCT x JURISDICTION remain mandatory. | | LANA reference implementation | RETAINED | LANA remains source/reference implementation; external coinin parameters remain coin-specific. | | EU/MiCA branch | RETAINED | Existing classification, limited-network, CASP/payment, market-integrity, AML/KYC and consumer gates retained. | | UK branch | RETAINED | P22 / Annex K and UK CP-32 to CP-39 retained; legal/source freeze remains 18 Aug 2026. | | U.S. branch | RETAINED | P23 / Annexes L-N and CP-40 to CP-52 retained. | | Annex O candidate registry | RETAINED | All 0.20 candidates retained; Annex Q adds economics evidence without silently deleting candidates. | | Annex P market snapshot | RETAINED | 0.20 market snapshot retained as historical/versioned price-cap reference. | | New 0.22 scope | ADDED | Atomic Unit definitions, P24 clauses 25-27, CP-58, Annex Q economics matrix and Annex R integrity audit. | | Historical change summaries | RETAINED | 0.20, 0.19, 0.18, 0.17 and earlier change summaries retained as version history. | ### Programmatic integrity check The 0.22 build was generated from the 0.20 DOCX as the source document. Existing paragraphs and tables were preserved except for intentional current-version metadata updates, the cover acronym expansion, version-header/status labels and the new additive P24/CP/Annex content. Historical version summaries were intentionally preserved as historical text. ## 0.22 Previous Change Summary (fee threshold superseded by 0.23) • Added “BALANCED EXCHANGE FRAMEWORK” directly under BEF on the first page so the acronym is explicit at first sight. • Added P24 Atomic Unit & Fee Economics and Transaction Fee & Practical Minimum gates; atomic divisibility is explicitly separated from practical payment viability. • Added CP-58 requiring canonical unit/precision, approved EUR conversion, live fee estimator, rolling 30-day median/average, P95, dust/minimum output, account reserve/activation and storage/rent evidence before ACTIVE status. • Added Annex Q with smallest native units, EUR atomic-unit values, representative standard-transfer fee economics and a preliminary fee-only suitability view for all 0.20 candidates. • Added Annex R integrity review confirming that the 0.20 P01-P24, BuyLana.com, coin-specific Registrar/Split architecture, EU/MiCA, UK and U.S. branches and prior annexes remain in the document. • Preserved Annex P as the versioned USD market snapshot and used it as the price basis for Annex Q atomic-unit conversions; EUR conversion uses the latest published ECB reference rate available at preparation time. • Dynamic-fee networks are not given a fake permanent “average”: they receive LIVE GATE treatment until a reproducible rolling fee feed is stored in their Coin Integration Profile. ## 0.20 Change Summary • Established LANA as the reference implementation of a shared BEF Balanced Split Architecture rather than the only coin with Split mechanics. • Made coin-specific Registrar and Split architecture mandatory for every external Native Coin before ACTIVE status. • Defined the common development path NATIVE COIN -> REGISTRATION -> REGISTERED COIN -> USE/CIRCULATION -> ACTIVE SUPPLY CHANGE & RECIRCULATION -> SPLIT -> NEXT BALANCED CYCLE. • Added coin-specific Total Registered Supply, Active Coin Supply, sequential Coin Splits, Split Event history and a mandatory versioned Coin Split Profile. • Clarified shared invariants versus coin-specific parameters: all ACTIVE coins follow Splits, but LANA Price(n+1) = Price(n) x 2 does not automatically apply to BTC, ETH or other coins. • Added REGISTRY READY and SPLIT READY activation stages, so technical eligibility alone can never make a coin operational inside BEF. • Strengthened COIN x PRODUCT x JURISDICTION: a functioning Registrar and Split Profile are required economic architecture, but do not replace coin-specific legal classification. • Expanded Conditions Precedent to CP-57 with a dedicated Coin Split Activation Pack and updated Annex O/P and EU/UK/U.S. activation matrices accordingly. • Superseded the 0.19 position that external coins did not inherit Split architecture: they now inherit the BEF Split concept and lifecycle, while retaining their own coin-specific numerical and economic rules. ## _**0.19 Previous Change Summary**_ _**• Added BEF-P24 Native Coin Integration Protocol, making BEF technically extensible beyond LANA to selected native coins with their own base network and direct key-controlled self-custody.**_ _**• Defined the hard eligibility rule OWN NETWORK + NATIVE ASSET + DIRECT KEY CONTROL and excluded contract tokens, wrapped/bridged/synthetic assets and tokenised representations from the default P24 scope.**_ _**• Defined Direct Key-Controlled Wallet / Account so Bitcoin-like HD/UTXO wallets remain eligible even when one seed controls multiple addresses; “single wallet” does not require one static address.**_ _**• Added coin-specific Coin Integration Profile, Registrar coin/network namespace, native transaction/finality verification, wallet-ownership proof and change-control requirements.**_ _**• Kept LANA-specific Split, Active Consumption Supply and System / Reference Value rules exclusive to LANA unless a future protocol explicitly says otherwise; external coins do not inherit LANA price doubling.**_ _**• Preserved BuyLana.com as the LANA-specific P07 Purchase & Delivery service; P24 does not turn BuyLana.com into a multi-asset exchange.**_ _**• Added Annex O with the initial native-coin candidate registry and Priority A / Priority B / HOLD / RESEARCH implementation statuses, including BTC, ETH, BNB, XRP, SOL and other major native networks.**_ _**• Added Annex P with a non-normative 19 August 2026 market snapshot (USD price and approximate market cap) and explicit market-data/source/timestamp discipline.**_ • Added CP-53 to CP-56 and new EU/UK/U.S. activation controls applying COIN x PRODUCT x JURISDICTION rather than carrying LANA conclusions over to another coin. _**• Preserved the substantive BEF 0.18 BuyLana.com architecture and the existing EU/MiCA, UK and U.S. regulatory branches; P24 candidate listing is not regulatory approval or automatic production activation.**_ ## 0.18 Previous Change Summary • Added BuyLana.com as the official user-facing service name for BEF-P07 Registered LANA Purchase & Delivery. • Added a step-by-step BuyLana.com purchase flow: identified seller -> Registered Wallet -> pre-contract disclosure -> Purchase & Delivery Agreement -> fiat payment -> Registered LANA delivery -> use under P02. • Clarified that BuyLana.com is a purchase/delivery interface and brand layer, not by name an exchange, trading venue, fund, broker, liquidity service or separate legal seller. • Required the actual operating company / seller / contract counterparty to be shown before purchase, including price, fixed quantity, Split, wallet, delivery/refund terms and applicable BEF version. • Added BuyLana.com to the public-layer map, Definitions, Protocol & Version Map, Closure Matrix, Legal Entity Matrix, Consumer Settlement Flow Matrix and UK/U.S. P07 activation terminology. • Preserved the substantive EU/MiCA, UK and U.S. regulatory architecture of 0.17 and retained the 18 August 2026 legal/source freeze; 0.18 does not create a new regulatory approval or reclassification merely through branding. ## 0.17 Change Summary • Added BEF-P23 United States Market Access & Regulatory Perimeter Protocol. • Added Annex L U.S. Federal Product & Perimeter Matrix covering FinCEN/BSA, SEC/CFTC, OFAC, IRS, stablecoin, securities and product activation. • Added Annex M 50-state + District of Columbia activation matrix for strict Lana.discount P08 and direct customer sale/use, with READY/CONDITIONAL/HOLD distinctions and issue notes. • Added Annex N state activation groups, source-freeze rule and U.S. deployment checklist. • Preserved and strengthened P08 proprietary treasury substance; mapped FIN-2014-R002 own-account precedent and added state-by-state gating. • Placed U.S. Mode B merchant settlement on nationwide HOLD until federal/state payment-money-transmission closure or licensed PSP route. • Placed current Lana8Wonder retail and Direct.Lana.Fund public/retail on U.S. HOLD until securities/private-fund/Blue Sky routes are closed; prohibited U.S. “annuity” product labelling absent actual insurance authority. • Added U.S. overlays to P01-P21, including Split/future-value communications, crowdfunding, custody, sanctions/Clean Provenance, IRS 1099-DA, privacy/biometrics and Digital Being boundaries. • Added U.S.-specific Conditions Precedent CP-40 to CP-52 and expanded Definitions, Regulatory References, Closure Matrix, Entity Matrix, Settlement Matrix and KYC Matrix. ### 0.16 Change Summary - Recast Lana Discount end-to-end as a Proprietary Treasury Acquisition function: own account, own capital, own risk, independent acceptance and direct treasury ownership. - Added explicit EU MiCA own-account/no-client-service perimeter based on European Commission / ESMA Q&A 2293, with CASP/Article 77 fallback only if the factual model becomes a client exchange service. - Added Clean Provenance eligibility, counterparty-level discretion, Treasury Acquisition Mandate, Counterparty Proposal and transaction evidence requirements. - Added internal acquisition-pricing framework: reference-market-based pricing may currently target approximately 22-35% below reference, expressly treated as proprietary purchase pricing rather than a fee or guaranteed exchange rate. - Changed deferred Lana Discount settlement standard from 30 days to maximum T+15 calendar days after the agreed contractual trigger, backed by Acceptance Gate and own-capital evidence. - Removed Lana Discount as the default consumer-linked Mode B merchant settlement function. Mode B is now a separate CONDITIONAL crypto/payment function; pure P08 payment runs purchaser -> seller. - Added Treasury Acquisition Portal UI language rules and explicit prohibited exchange/cash-out/client-balance/guaranteed-buyback language. - Refreshed UK analysis through 18 August 2026: current MLR territorial/business test remains separate; added HM Treasury draft Article 9UA proprietary-trading exclusion and the requirement to re-check final SI/FCA perimeter guidance before 25 October 2027 reliance. - Revised Annexes A, B, C, D, E, F, G, H, I and K so definitions, conditions precedent, Nostr semantic mapping, legal-entity matrix, pricing taxonomy, flow matrix and UK transition matrix use the same treasury substance. - Preserved FUNCTION BEFORE LABEL: if actual operations become a service to a client, the Treasury label does not prevent reclassification. ### 0.15 Previous Change Summary - Added P22 UK Market Access & Regulatory Perimeter Protocol and Annex K UK Regulatory Perimeter & Transition Matrix. - Added explicit no-passport rule: EEA/MiCA/CASP status is not treated as automatic UK authorisation. - Added current UK MLR territorial analysis, including the FCA overseas/no-UK-office factor, while keeping financial promotions as a separate cross-border gate. - Added UK financial-promotion controls for websites, apps, social media and onboarding communications to UK consumers. - Added UK Operating Company and Lana Discount principal-purchase classifications, with separate fiat ownership/payment-perimeter logic. - Added 25 October 2027 FSMA transition architecture, dealing-as-principal permission analysis, UK legal-entity default assumption and FCA gateway timing. - Added UK Payment Services Regulations 2017 / PERG branch for Mode B and third-party fiat flows. - Added UK AML/Travel Rule, UK GDPR/DPA biometric controls and UK conduct/prudential/resilience activation gates. - Added CP-32 to CP-39, UK rows in Annex F/G/I/J and official UK regulatory references in Annex D. - Preserved EU/MiCA architecture and P21 KYC design; UK is a parallel jurisdiction overlay rather than a replacement for EU controls. ### 0.14 Previous Change Summary - Added P21 Identity Assurance, KYC & Biometric Verification while preserving P01-P20. - Corrected AML timing: AMLR Regulation (EU) 2024/1624 applies from 10 July 2027; current national AML regimes remain relevant until then. - Separated automatic technical IDENTITY-VERIFIED status from regulated CDD relationship decisions and added meaningful-human-intervention / explanation / challenge safeguards. - Replaced immediate permanent deletion of CDD evidence with sealed archive/reference retention that supports regulator retrieval and relationship-based deletion. - Separated regulatory KYC capture from optional public identity: KYC selfie is never published; public face/profile remains an explicit separate choice. - Added missing AMLR-target natural-person data (full DOB/place of birth, residence/address and national identifiers where applicable) and legal-person KYB gate. - Added OpenSanctions commercial-licence gate, multilingual screening calibration, PEP/EDD semantics and ongoing rescreen. - Added KIND 37105 minimal authority-signed attestation, trusted key rotation/revocation, expiry and Level-4 semantic guardrail. - Added Annex J implementation matrix and CP-25 to CP-31 closure conditions. Strengthened Article 4(3)(d) strict-use-right and continuously-growing-network analysis; added explicit Title II fallback if exemption is unavailable. Added operative Regulatory Override Event so mandatory law/regulator requirements cannot be blocked by Alignment. Clarified Mode B as linked consumer-merchant sale + principal LANA purchase + documented direct merchant settlement, without prejudging PSD2 classification. - Added P15-P20 regulatory closure protocols without removing P01-P14. - Added two explicit consumer settlement modes and no-client-funds-pooling principle. - Added MiCA/MiFID classification order, limited-network evidence gate and same-underlying-asset control. - Added market integrity / inside-information / conflicts controls. - Added AML/TFR, sanctions, DAC8 and future AMLR transition architecture. - Added GDPR/Nostr per-KIND governance, DPIA and AI decision safeguards. - Added PSD2/consumer/distance-financial-service settlement framework and future PSD3/PSR watch. - Added obligation/liquidity ledgers, zero-new-participant stress testing, DORA/resilience and audit-pack requirements. - Balanced Wallet negative positions remain HOLD until legal, financial, accounting and technical closure. ## BALANCED EXCHANGE FRAMEWORK (BEF) _URAVNOTEŽENA EKONOMIJA OBILJA_ > Exchange. Alignment. Reflection. Responsibility. Change. Balance. Life. ## ANNEX S - TRANSACTION PRICE BANDS & NOSTR KEY-ALIGNMENT MATRIX Framework 1.0 retains the three transaction-price bands introduced in 0.23: LOW PRICE below 0,01 EUR; MID PRICE from 0,01 EUR through 0,30 EUR inclusive; HIGH PRICE above 0,30 EUR. A price band describes the economics of a standard native transfer and does not by itself make a coin uninteresting or exclude it from BEF. Dynamic or insufficiently evidenced networks remain LIVE PRICE GATE until CP-58 evidence is available. The Nostr key-alignment test from 0.22 remains unchanged. Nostr NIP-01 requires secp256k1 Schnorr signatures. A native blockchain key is direct-key aligned only where the wallet/account can use secp256k1 key material and an auditable BIP-340-compatible signing path. Ed25519, sr25519, BLS, shielded-only or principal-only models are not directly Nostr-compatible and require a separate Nostr-link proof or adapter. Operational safety note: direct technical compatibility is not a recommendation to expose a value-bearing blockchain private key to ordinary Nostr clients. Production use should prefer a dedicated derived/signing key or a proof-of-control link between the blockchain wallet and the Nostr identity. ### 1.0 Practical Classification (fee basis retained from 0.23) | Coin | Transaction price band | Nostr key-alignment gate | 1.0 BEF result | | --- | --- | --- | --- | | LANA | LOW PRICE | NOSTR OK: secp256k1/BIP340 path | REFERENCE / INTERESTING | | BTC | MID PRICE | NOSTR OK: secp256k1 | INTERESTING - MID PRICE | | ETH | HIGH PRICE | NOSTR OK: EVM secp256k1 | HIGH PRICE - NOT AUTO-EXCLUDED | | BNB | LOW PRICE | NOSTR OK: EVM secp256k1 | REMAINS INTERESTING | | XRP | LOW PRICE | COND: secp256k1 XRPL only; Ed25519 no | CONDITIONAL | | SOL | LOW PRICE | NOSTR NO: Ed25519 | NOSTR INCOMPATIBLE | | TRX | LOW with resources / MID fallback | NOSTR OK: secp256k1 | INTERESTING - RESOURCE-CONDITIONAL | | HYPE | LIVE PRICE GATE | COND: EVM signer evidence needed | LIVE GATE | | DOGE | LOW PRICE | NOSTR OK: secp256k1 | REMAINS INTERESTING | | ZEC | MID PRICE + HOLD | PARTIAL/HOLD: transparent only | P24 HOLD - PRIVACY/PROVENANCE | | XMR | LIVE PRICE GATE + HOLD | NOSTR NO: non-secp model | LIVE GATE/HOLD | | ADA | MID PRICE | NOSTR NO: Ed25519/BIP32-Ed25519 | NOSTR INCOMPATIBLE - MID PRICE | | XLM | LOW PRICE | NOSTR NO: Ed25519 | NOSTR INCOMPATIBLE | | BCH | LOW PRICE | NOSTR OK: secp256k1 | REMAINS INTERESTING | | GRAM | LOW-MID PRICE | NOSTR NO: TON Ed25519 | NOSTR INCOMPATIBLE - LOW/MID PRICE | | LTC | LOW PRICE | NOSTR OK: secp256k1 | REMAINS INTERESTING | | HBAR | LOW PRICE | COND: ECDSA secp256k1 only | CONDITIONAL | | AVAX | LOW PRICE | NOSTR OK: secp256k1 C-Chain | REMAINS INTERESTING | | SUI | LOW PRICE | COND: Secp256k1 Sui only | CONDITIONAL | | NEAR | LOW PRICE / LIVE | COND: secp256k1 access key only | CONDITIONAL | | TAO | LIVE PRICE GATE | NOSTR NO: sr25519/ed25519 | LIVE GATE | | DOT | LIVE PRICE GATE | COND: ECDSA only; default sr25519 no | LIVE GATE | | ICP | LOW PRICE / RESEARCH | NOSTR NO: principal model | NOSTR INCOMPATIBLE | | ETC | LIVE PRICE GATE | NOSTR OK: EVM secp256k1 | LIVE GATE | | ATOM | LOW PRICE / LIVE | NOSTR OK: Cosmos secp256k1 | REMAINS INTERESTING | | ALGO | LOW PRICE | NOSTR NO: Ed25519 | NOSTR INCOMPATIBLE | | KAS | LOW PRICE | NOSTR OK: secp256k1/Schnorr; verify BIP340 | REMAINS INTERESTING | | FIL | LIVE PRICE GATE | COND: Filecoin secp256k1 only; BLS no | LIVE GATE | | APT | LIVE PRICE GATE | COND: Secp256k1 auth only; Ed25519 no | LIVE GATE | | XTZ | LIVE PRICE GATE | COND: tz2/Secp256k1 only | LIVE GATE | The fee and Nostr filters are now read independently. The following examples show the corrected interpretation, always subject to COIN x PRODUCT x JURISDICTION and the other P24 gates: - LANA - reference implementation; LOW PRICE reference; native BEF anchor. - BTC - MID PRICE on the stated ~EUR 0.078 simple-transfer reference; Nostr-compatible secp256k1 key model; no longer excluded merely because the fee exceeds one cent. - ETH - HIGH PRICE on the stated ~EUR 0.354 transfer example; Nostr-compatible EVM/secp256k1 key model; high transaction cost is an economic-use signal, not an automatic BEF exclusion. - BNB, XRP, DOGE, BCH, LTC, HBAR, AVAX C-Chain, ATOM and KAS - LOW PRICE on the stated references; Nostr alignment remains as specified in the matrix. - TRX - LOW PRICE when sufficient bandwidth/resources are available; MID PRICE on the stated unstaked fallback; Nostr-compatible secp256k1 key material. - ZEC - MID PRICE on the stated fee reference, but P24 HOLD remains for privacy/provenance design; fee alone is not the exclusion reason. - ADA - MID PRICE on the stated fee reference, but ordinary wallet keys remain Nostr-incompatible under the current key-alignment test. - GRAM / TON - the stated reference spans LOW to MID PRICE, but the ordinary TON Ed25519 wallet model remains Nostr-incompatible. - SUI, NEAR, ICP and ALGO have LOW PRICE references where measured, while their separate Nostr/account-model constraints remain unchanged; HYPE, XMR, TAO, DOT, ETC, FIL, APT and XTZ remain LIVE PRICE GATE where current representative fee evidence is not closed. ### 1.0 Key Interpretation Rules - LOW PRICE (< EUR 0.01) is the preferred cost profile for frequent micro/retail circulation, but it does not override Nostr or other P24 gates. - MID PRICE (EUR 0.01-EUR 0.30 inclusive) remains potentially usable in BEF; suitability depends on transaction size, frequency and the complete technical/regulatory profile. - HIGH PRICE (> EUR 0.30) is less attractive for frequent small transfers, but the coin is not automatically excluded from BEF and may remain suitable for larger-value or lower-frequency flows. ## 1.0 Final Framework Summary - Declared the Balanced Exchange Framework CORE architecture final at Framework Version 1.0 while preserving function-specific READY / CONDITIONAL / HOLD activation gates. - Clarified that a Wallet Position below Zero Level is only a coordinate relative to an actual/evidenced reference level; it is not debt, missing money, negative ownership or a source of newly created spending power. - Closed the Balanced Wallet framework design around Personal Sufficiency, non-fixed Maximum Growth Ceiling, Zero-Level mapping, aggregate-zero coordinate identity, dynamic multi-month Flow Capacity and breathing expansion/contraction. - Defined Flow Capacity as adaptive to real economic opportunity and use over meaningful monthly/multi-month periods; exact operational parameters intentionally remain versioned policy rather than a universal financial formula. - Closed Economic Gravity at design level: unused Registered excess is reviewed over time, followed by notice and participant choice; any deregistration applies only to unused Registered status above the active flow range and may occur in one or multiple steps. - Confirmed that deregistration may contract the economy without implying collapse; later real demand may expand capacity through a separate new Registration Event without transferring another participant’s native asset. - Closed system maturity at design level as an emergent collective transition driven by sufficient personal Balanced Wallet participation plus sustained internal circulation, recirculation and reduced structural growth dependence rather than a fixed date, Split count or threshold. - Reclassified Annex C from “Conditions Precedent for Final 1.0” to “Activation & Implementation Conditions”: legal, technical, accounting, KYC, product, entity, jurisdiction and coin-specific packs remain mandatory before affected functions are activated. - Preserved the principle that Framework 1.0 is an operational/transparency architecture and not a MiCA white paper, legal opinion, licence, regulatory approval, deposit guarantee or no-loss promise. ## 0.33 Change Summary - Preserved the 0.32 First Complete Framework Baseline and exhaustion-based LANA Split Trigger without changing CP-13 design. - Separated PERSONAL MATURITY from SYSTEM MATURITY: an individual may enter Balanced Wallet through a Personal Sufficiency Election even while the wider BEF economy remains in Growth Phase; system maturity remains CP-59. - Removed any implication that approximately EUR 100 million is a fixed personal maturity trigger. It is retained only as a past scale illustration for a configurable Maximum Growth Ceiling, not a promise or immutable threshold. - Defined Zero Level as an internal reference coordinate and separated Wallet Position from User-Facing Available Capacity; added an illustrative +1,000 / -1,000 example around a 1,000 display baseline. - Defined the target aggregate identity SUM(WALLET POSITIONS)=0 for a specified balancing set, while preserving the distinction from legal asset ownership, solvency and blockchain balances. - Defined Dynamic Flow Capacity / Wave Amplitude: capacity may expand with auditable real economic flow and changing needs; passive holding alone does not create the same functional need for larger capacity, and artificial spending is not a valid growth objective. - Defined Economic Gravity path: inactive excess Registered position -> Gravity Notice -> participant choice -> possible Deregistration Event under a published policy. Deregistration removes BEF Registered status only; it does not transfer private keys or native assets. - Defined breathing/contraction logic: deregistration may shrink Registered Supply; if real demand later requires expansion, a separate new Registration Event may add capacity. - Marked CP-18 and CP-61 partially closed at framework-design level while retaining production HOLD gates for legal/accounting funding, negative-position characterisation, exact formulas/thresholds, notice periods, valuation, insolvency and audit controls. ## 0.32 Change Summary - Declared 0.32 the FIRST COMPLETE FRAMEWORK BASELINE while preserving the rule that Final 1.0 requires closure/transfer of applicable Conditions Precedent and no production use of unresolved HOLD functionality. - Added a text-only BEF ARCHITECTURE AT A GLANCE showing the master triad and nested Exchange, LanaPays.us, Common Good, Alignment and OWN structures without reintroducing preliminary graphics. - Rebuilt P03 around measurable current-cycle supply states: Split Release Supply, Open Flow Supply, Absorbed Supply and an exhaustion-based LANA Split Trigger. - Closed CP-13 at framework-design level: a LANA Split follows exhausted/reconciled Open Flow Supply with no approved current-cycle replenishment pending; CP-13 continues as a per-Split evidence obligation. - Separated trigger logic from growth sizing. Next-cycle release size and in-cycle registration amounts intentionally have no universal multiplier; they are adaptive, documented decisions based on live absorption, consumption, recirculation, infrastructure, Common Good and stability indicators. - Added the Dosing Principle: release should track real absorption capacity and avoid over-supply, while P16 expressly prohibits using supply/registration/Split communication to manufacture false demand, misleading scarcity or manipulate an open market price. - Carried the new Split logic into Core 4.6, P13, P14, Annex A definitions, CP-57 and the current-version evidence architecture, while preserving coin-specific P24 separation. - Clarified that Price(n+1)=Price(n)x2 is the current LANA System / Reference Value transition rule and is separate from supply-size governance; corrected a fee-band typographical collision so MID remains EUR 0.01-EUR 0.30 inclusive and HIGH remains above EUR 0.30. ## 0.31 Change Summary - Removed the four preliminary schematic graphics from the Core Framework so visual representations can be redesigned and approved separately, image by image. - Removed the corresponding figure captions while preserving the full textual triadic architecture and all architecture breadcrumbs. - Preserved without substantive change the 0.30 master triad EXCHANGE + ALIGNMENT + SELF-RESPONSIBILITY / OWN and all nested Exchange, LanaPays.us, Common Good and OWN triads. - Preserved P04, P05, P06 and P13 restructuring, the Core Protocol Architecture Map, all P01-P24 protocol numbering, and all regulatory, legal, technical and economic safeguards from 0.30. - Reserved future diagrams for a separate controlled visual-development process; no placeholder graphic in 0.31 is normative. ## 0.30 Change Summary - Reorganised the BEF Core Framework around the explicit master triad EXCHANGE + ALIGNMENT + SELF-RESPONSIBILITY / OWN. - Defined the nested Exchange triad as LANA8WONDER (Personal Balance) + LANAPAYS.US (Circulation) + COMMON GOOD FUNDING (Creation & Giving). - Defined the LanaPays.us inner triad as CONSUMPTION + CAPITAL INPUT (Direct.Lana.Fund) + TREASURY / RECIRCULATION (Lana Discount). - Defined the Common Good inner triad as CROWDFUNDING + UNCONDITIONAL FUNDING + UNCONDITIONAL PAYMENTS; Community Projects are treated as an application/purpose rather than a fourth equal pillar. - Strengthened the OWN structure as REFLECTION -> ALIGNMENT -> CHANGE and clarified the role of apology, unconditional self-responsibility and concrete future commitment. - Reworked P04, P05, P06 and P13 so the protocol text follows the same architecture, and added architecture breadcrumbs to key protocols without renumbering P01-P24. - Added schematic diagrams for the master BEF triad, Exchange nested triads, Alignment process and OWN triad, plus a Core Protocol Architecture Map. - Preserved the 0.29 regulatory activation gates, asset classifications, fee/market snapshots, legal-perimeter safeguards, no-guarantee language and Conditions Precedent except where 0.30 expressly restructures explanatory terminology. ## 0.29 Previous Change Summary - Added the Mature Flow / Balanced Wallet conceptual layer: ZERO LEVEL sea-surface model, balance without equality, FLOW BEFORE ACCUMULATION, Economic Gravity, release/reallocation and sufficient-capacity principles. - Clarified that aggregate zero is an internal Balanced Wallet accounting/design target and does not mean users' legal assets, native coins, fiat balances or net worth equal zero. - Added explicit ownership safeguard: future expiry/decay/release applies by default to BEF system allocation, incentive, carry privilege or spending-capacity components; it is not authority for automatic confiscation or destruction of user-owned native assets. - Added Growth -> Saturation -> Natural Deceleration -> Mature Flow logic. Maturity is evidenced by internal circulation, lower fiat-out demand and lower external-capital dependency, not by a promised number/date of Splits. - Expanded P02 with configurable Consumption Incentive policy: current LANA reference design may use 0-20% incentives, commonly about 5-20%, potentially equal for consumer and merchant, subject to live policy, source-of-funds and regulatory disclosure. - Expanded P03 with Pre-Split Release and Consumption-Support One-Split Carry concept, including Registrar carry evidence, mandatory end of the carry privilege and entity/jurisdiction-specific legal gate. - Expanded P13 with consumption-driven growth, separate principal acquisition, one-Split consumption-support capital, maturity indicators, incentive transition and a mature internal-circulation loop. - Expanded P14 with Zero-Level / Sea-Surface Model, large-wave participation, Economic Gravity, Release/Reallocation, cross-asset Balanced Wallet, fiat de-concentration, sufficient capacity and explicit no-universal-wealth/no-loss language. - Added CP-60 Consumption Incentive & One-Split Carry Pack and CP-61 Balanced Wallet Zero-Level, Gravity & Release Pack; strengthened CP-18, CP-59 and P20 activation gates. - Preserved the complete 0.28 architecture, including P01-P24, BuyLana.com, native-coin eligibility, coin-specific Registrar/Split architecture, transaction-price bands, Nostr key alignment, EU/MiCA, UK and U.S. regulatory gates, and the Balance/Coexistence/Preservation foundation. ## 0.28 Previous Change Summary - Added the Foundational Balance Note: BEF is explicitly a framework for coexistence, balancing and preservation across different forms of value, not a replacement coin, fiat currency, exchange or winner-take-all monetary system. - Clarified LANA as the first/reference implementation of BEF rather than the boundary of the framework; different assets retain their native identity, network, key model, Registrar, economic cycle and legal perimeter. - Added the natural growth analogy: rapid developmental growth can mature into a stable maintenance phase while cellular/tissue renewal continues; the analogy is illustrative and does not claim biological equivalence. - Formalised that Split-driven Growth Phase is a developmental mechanism, not an assumption of indefinite exponential growth or an endlessly repeated identical value-transition formula. - Added P24 Cross-Asset Balance & Preservation Principle and Growth Phase -> Mature / Balanced State clauses. - Added CP-59 Balanced Maturity & Stabilisation Pack; exact maturity trigger, number of Splits, terminal value and mature-state formula remain intentionally undefined until evidence and design are completed. - Preserved the full 0.23 architecture, including P01-P24, BuyLana.com, native-coin eligibility, coin-specific Registrar and Balanced Split architecture, transaction-price bands, Nostr key alignment, CP-58 economics evidence, and EU/MiCA, UK and U.S. regulatory gates. ## 0.23 Previous Change Summary - Replaced the binary > EUR 0.01 TOO EXPENSIVE rule with three transaction-price bands: LOW PRICE < EUR 0.01; MID PRICE EUR 0.01-EUR 0.30 inclusive; HIGH PRICE > EUR 0.30. - Clarified that transaction price is an economic-use signal and does not by itself exclude a native coin from BEF. - Reclassified BTC as MID PRICE, ETH as HIGH PRICE, ADA and ZEC as MID PRICE, TRX as resource-conditional LOW/MID, and GRAM/TON as a LOW-MID range on the stated reference basis. - Updated the main Native Coin Registry, Annex Q fee table and Annex S fee/Nostr matrix while preserving the Nostr key-alignment conclusions from 0.22. - Preserved BuyLana.com, P24 Native Coin Integration, coin-specific Registrar/Split architecture, CP-58 evidence requirements, and all EU/MiCA, UK and U.S. regulatory gates. ## 0.22 Previous Change Summary (fee threshold superseded by 0.23) - Updated front matter and version references from 0.21 to 0.22. - Added explicit 0,01 EUR fee threshold: coins above the threshold are marked TOO EXPENSIVE and not interesting for BEF micro/retail circulation. - Updated the main Native Coin Registry with 0.22 fee and Nostr outcomes. - Added Nostr key-alignment test based on NIP-01 secp256k1 Schnorr requirement. - Added Annex S with coin-by-coin fee/Nostr matrix and practical shortlist. - Preserved BuyLana.com, P24 Native Coin Integration, coin-specific Registrar/Split architecture, Annex O/P/Q/R and regulatory perimeter gates from 0.21.