Anatomie van een wallet

EN-bronmaster · P09-L01 · 45 minuten geschat · needs_review

Een walletpagina kan een adres, meerdere tokenaccounts, contractaanroepen en providerlabels op één scherm combineren. Dat gemak maakt ze niet tot één registerobject of één persoon. Bepaal vóór het lezen van de historie wat de pagina daadwerkelijk vertegenwoordigt.

Je brengt accountrollen in kaart en sluit aangeleverd bezit aan zonder identiteit toe te schrijven. Dit is de basisvaardigheid van het programma: elke latere bewering over financiering, leeftijd en relaties hangt af van de juiste waarnemingseenheid.

Scheid de interface van het object

Een walletapplicatie is een interface, terwijl een account een registerobject is; Ethereum-documentatie maakt dit onderscheid expliciet [S09-ETHACCOUNTS]. Eén interface kan meerdere accounts en netwerken tonen. Eén account kan via meerdere interfaces toegankelijk zijn. Geen van beide relaties identificeert een unieke mens.

Gebruik netwerk plus volledig adres als beginidentificator. Een verkort label bewijst geen gelijkheid. Dezelfde weergegeven tekst op verschillende ketens is geen gezamenlijk boekhoudobject. De “wallet”-groepering van een provider kan afgeleide relaties bevatten; inspecteer de definitie voordat je haar als eigenaarstotaal behandelt.

Valideer bij werkelijk onderzoek de adrescodering en leg het gekozen netwerk vast. De oefening gebruikt opzettelijk ongeldige labels: vergelijkingen zijn alleen educatief en geen transactie kan deze identificatoren als bestemming hebben.

Identificeer de rol van het account

Solana-accounts bewaren toestand op adressen en hebben een veld voor programma-eigendom [S09-ACCOUNTS]. Dat veld is geen menselijke identiteit. Een tokenaccount legt afzonderlijk zijn mint en eigenaarautoriteit vast [S09-TOKENS]. Lees het basiseigendom van het Token Program niet alsof dat programma de begunstigde van elk tokensaldo is.

Een autoriteit kan meerdere tokenaccounts voor één mint bezitten. Aggregeer alleen dezelfde exacte mint, overeenkomende context en onderbouwde autoriteitsvelden. Een native saldo en een tokensaldo zijn verschillende eenheden. Tel ze nooit als één activum op en converteer niet naar dollars zonder expliciete waarderingsbron.

Leg vast of een adres een programma, tokenaccount, mint of ander toestandsaccount aanduidt. Dezelfde relatiegraaf kan al deze knooptypen bevatten. Een graaf met vijf knopen toont geen vijf wallets, laat staan vijf mensen.

Begrijp activiteit onder programma-aansturing

Solana-adressen afgeleid van programma’s (PDA’s) worden afgeleid uit een programma-ID en seeds en hebben geen private sleutel; het afleidende programma kan via het runtimemechanisme voor ze ondertekenen [S09-PDA]. Afleiding alleen beweert niet dat op dat adres al een account is gealloceerd. Verifieer zowel de adresrelatie als de relevante accounttoestand.

Programmaondertekening en menselijke ondertekening mogen niet in één veld samenvallen. Een autoriteit die via een programma handelt kan veel gebruikers bedienen. De applicatieregels bepalen welke verzoeken haar laten handelen; een PDA-label bewijst geen individuele gebruiker of onbeperkte controle.

Onderscheid op EVM-netwerken gewone sleutelcontrole, contractlogica en ondersteunde delegatiemechanismen. Een externally owned account (EOA) wordt door een private sleutel aangestuurd; ondersteunde delegatie kan bepalen welke code het uitvoert. EIP-7702 staat codedelegatie voor EOA’s toe op ondersteunende netwerken [S09-DELEGATION]. Daarom is alleen codeaanwezigheid geen universele regel “dit kan geen EOA zijn”. Inspecteer netwerkregels en accounttoestand in de gevraagde context.

Een account met code kan instructies uitvoeren zonder te bewijzen welke mens daarvan profiteert. Een multisigcontract kan meerdere ondertekenende accounts vertegenwoordigen, maar ondertekenaars tellen bewijst geen onafhankelijke mensen. Houd het controlemechanisme en menselijke toeschrijving gescheiden.

Maak een rollenkaart vóór een eigendomskaart

Gebruik knooptype, exacte identificator, netwerk, context en bewijsverwijzing. Gebruik verbindingen zoals tokenaccounteigenaar, mintverwijzing, programma-afleiding en codedelegatie. Die verbindingen hebben specifieke betekenissen. Een generieke verbinding “gerelateerd aan” verbergt waarom knopen verbonden zijn.

Maak niet van elke verbinding gezamenlijk eigendom. Een mintverwijzing verbindt alle houders van een activum zonder hen één controller te maken. Programma-afleiding verbindt een adres met een mechanisme, niet noodzakelijk met het persoonlijke bezit van de programmabeheerder.

Providerlabels horen in een aparte annotatie met herkomst en verificatiestatus. “Bewaarservice” kan een nuttige aanwijzing zijn, maar onderzoek de uitgever, bijgewerkt-datum en basis van het label. Leg het vast als providerbewering totdat het voldoende wordt bevestigd.

Sluit het aangeleverde bezit aan

De fixture geeft bij S0 een uitputtende verzameling tokenaccounts voor autoriteit W en één doelmint. Die volledigheid is een oefenaanname, geen voor Wallet Intelligence geclaimde capaciteit. Tel de twee geldige accountsaldi pas op nadat je eigenaar en mint hebt bevestigd.

Een derde account met dezelfde mint onder een autoriteit afgeleid van een programma is geen bezit van W enkel omdat het op hetzelfde applicatiescherm staat. Bezit van een andere mint kan niet in het doeltotaal worden opgenomen. Native eenheden blijven afzonderlijk.

Rapporteer bij gedeeltelijke werkelijke records een totaal van teruggegeven saldi en de dekkingsbeperking. Promoveer dit niet stilzwijgend tot “alle bezittingen”. Een mislukte query is niet-beschikbaar bewijs, geen nulvoorraad. Een aangeleverd nulbedrag is een meting binnen de opgegeven reikwijdte.

Formuleer de grenzen constructief

Een goede anatomiebevinding kan zeggen: “W is de aangeleverde autoriteit voor T1/T2 met MINT-A; P1 is een afzonderlijke autoriteit die via een programma handelt. Menselijke controle is onbekend.” Zij beantwoordt de accountvraag zonder een onbewezen identiteitsvraag op te lossen.

Laat het volgende bewijsverzoek bij de leemte passen: volledige opsomming per eigenaar/mint voor ontbrekend bezit, afleidings-/toestandsrecords voor een PDA-classificatie en applicatieautorisatie voor bemiddelde controle. Vragen naar iemands naam vervangt deze technische controles niet.

Geen accountrol produceert een BUY/SELL-signaal. Een contract, PDA of tokenaccount vertelt hoe waarnemingen zijn georganiseerd. Het bewijst geen legitimiteit, intentie of toekomstig marktgedrag.

• Adres: identificator binnen een netwerk.
• Account: toestandsobject op een adres.
• Walletinterface: applicatie die accounts toont of ermee communiceert.
• Eigenaarautoriteit: veld dat een bepaald tokenaccount bestuurt.
• PDA: adres afgeleid van een programma met runtimeondertekening.
• Delegatie: relatie voor accountuitvoering, geen persoonlijke verbondenheid.

ILLUSTRATIVE — FIX-P09-01. SIM-SOL-A bij fictieve S0; saldi zijn al genormaliseerd. Doelautoriteit W, doelmint MINT-A. T1/T2 zijn als uitputtend voor W/MINT-A opgegeven.

A 7 is een afzonderlijk netwerkvoorbeeld. Er zijn geen records over identiteit, waardering, handtekeningdrempel of applicatieautorisatie aangeleverd.

OBSERVED in de fixture: W is eigenaarautoriteit voor T1/T2; P1 is een afzonderlijke autoriteit afgeleid van een programma voor T4. De provider publiceert A 8.

INFERRED: Het aangeleverde MINT-A-bezit van W bedraagt in totaal 200 tokens. De native 2 en MINT-B50 zijn afzonderlijke hoeveelheden.

UNKNOWN: Menselijke identiteit achter W/P1/E1, regels voor applicatiecontrole en economisch eigendom.

INSUFFICIENT EVIDENCE: A 8 kan Alice’s identiteit niet bewijzen. De gedeelde mint kan W en P1 niet samenvoegen. Codedelegatie bewijst geen verbondenheid met de uitgever van LOGIC-D.

Een wallet-UI als één persoon behandelen; de basiseigenaar van het programma verwarren met de token-eigenaarautoriteit; verschillende eenheden optellen; houders van dezelfde mint samenvoegen; en verouderde code/geen-codeclassificatie toepassen zonder netwerkcontext.

Teken een getypeerde rollenkaart op basis van A 1–A 7. Bereken het doelbezit van W. Classificeer A 8 en verklaar waarom T4 buiten het totaal van W moet blijven. Identificeer twee ontbrekende controles voor activiteit onder programma-aansturing.

• Kies exact netwerk en waarnemingseenheid.
• Typeer elke knoop en relatie.
• Houd native en mintsaldi apart.
• Aggregeer alleen onderbouwde eigenaarsvelden.
• Onderscheid programma-/sleutel-/gedelegeerde controle.
• Bewaar labels als beweringen totdat ze bevestigd zijn.

Walletanatomie is een kaart van registerobjecten en controlemechanismen. Zij bepaalt wat onderzocht moet worden zonder adressen aan mensen gelijk te stellen.

Een interface is geen account of persoon. Getypeerde relaties voorkomen onjuiste aggregatie. Providerlabels en codegedrag bewijzen geen identiteit.

Teken getypeerde W,T1,T2,T3,P1,T4 en mintknopen met gelabelde autoriteits-/mint-/afleidingsverbindingen. Markeer alleen doel200. Isoleer native en MINT-B-eenheden en afzonderlijke EVM-delegatie. Plaats A 8 in een annotatie voor een ongeverifieerd label.

Illustratieve accountanatomie; graafknopen zijn geen mensen.

Gebruik deterministische SVG/HTML of grafieken met eenheden, bewijsverwijzingen en tekstalternatieven. Marineblauw/zwart met bescheiden cyaan, elektrisch blauw en violet; geen decoratieve of verzonnen explorer-screenshots. Stapel annotaties op 390px; controleer 768px, desktop en Arabisch RTL wanneer de assets zijn geïmplementeerd. Houd identificatoren LTR en de feitelijke richting van tijd/verbindingen/assen ongewijzigd. Gebruik alleen het officieel aangeleverde BlockAssay-merk. Beide visuele records blijven specificaties.

WALLET_INTELLIGENCE correspondeert met alleen-lezen inspectie van openbare adresrecords, relaties en herkomst. Controleer ondersteund netwerk, exacte identificatoren, velden en dekking vóór runtime-integratie; hier wordt geen live providercapaciteit geclaimd. Gebruik de ingebedde offline oefening als gegevens of betaalde toegang ontbreken. Geen walletverbinding, inloggegevens, private sleutel, handtekening of live handel is vereist. Ontbrekende gegevens blijven onbekend. Academy-voortgang, creatorstatus, betalingen en verwijzingen veranderen nooit Radar-bewijs.

• Solana-accounts — Geadresseerde toestand en veld voor programma-eigendom. Gecontroleerd op 2026-09-30.
• Solana-activa — Onderscheid tussen mint, tokenaccount en eigenaarautoriteit. Gecontroleerd op 2026-09-30.
• Solana-adressen afgeleid van programma’s — Adressen afgeleid van programma’s en programmaondertekening; geen private sleutel voor een PDA. Gecontroleerd op 2026-09-30.
• Ethereum-accounts — Onderscheid tussen account en interface en accounttypen. Gecontroleerd op 2026-09-30.
• EIP-7702: code instellen voor EOA’s — Codedelegatie voor EOA’s; de aanwezigheid van code alleen is geen universele classificatieregel voor EOA’s. Gecontroleerd op 2026-09-30.

Alle voorbeeldrecords zijn oorspronkelijke ILLUSTRATIVE fixtures, geen historische/live ketenmetingen. Documentatie verklaart mechanismen, niet verzonnen bedragen of labels. De synthetische chronologie is expliciet begrensd; observedAt=null is opzettelijk. OBSERVED in een oefening betekent een aangeleverd fixturerecord. Herbeoordeel documentatie en de geïmplementeerde decodering vóór publicatie. Providerlabels bewijzen geen identiteit; adrescontrole en menselijke toeschrijving vereisen afzonderlijk bewijs.

P09-L02 na de uitgewerkte oefening en bespreking van de vragen.