Leestijd: 17 min
Overzicht
Als actieve handelaar op Hyperliquid is een uitgebreide portefeuille-tracker onmisbaar om je posities, winst- en verliescijfers en margbenutting in realtime bij te houden. In deze handleiding leer je hoe je een krachtige portefeuille-tracker kunt bouwen die elke Hyperliquid-wallet volgt met behulp van het Hyperliquid-info-eindpunt van Quicknode. Naast het maken van een handige tradingtool, legt deze tutorial ook uit hoe HyperCore-gegevens worden opgehaald, gestructureerd en gebruikt voor het bouwen van de applicatie. De applicatie laat het volgende zien:
- Live positievolging - Real-time updates over openstaande posities met PnL
- Portefeuilleanalyse – Accountwaarde, marges en risicokengetallen
- Kluisbeheer - Houd de waarde van de kluis en de sluitingsschema’s bij
- Spot Holdings - Houd de token-saldi en de waarde in USD bij
- Zoek naar een willekeurige portemonnee - Schakel tussen verschillende handelsrekeningen
Wat je gaat doen
Bouw een complete portefeuille-tracker in 4 fasen:
- Een Quicknode-eindpunt en een Supabase-account instellen
- Je databaseschema instellen
- Een indexer maken die elke 500 ms HyperCore-gegevens ophaalt
- Een dashboard bouwen met moderne UI-bibliotheken dat realtime handelsgegevens weergeeft
Wat je nodig hebt
- Quicknode Hyperliquid-eindpunt
- Supabase-account
- Node.js v20+, npm en een code-editor
- Basisbegrippen van React/TypeScript en REST API’s
- Basisbegrippen van SQL
- Optioneel: een hypervloeibare, ononderbroken handelservaring
Quicknode biedt speciale Hyperliquid API-eindpunten, waardoor het niet meer nodig is om een eigen node te draaien:
- Vooraf geconfigureerde eindpunten waarvoor geen installatie nodig is
- Zorgt voor het beheer van verbindingen en failover
- Directe toegang tot HyperCore-gegevens zonder extra infrastructuur
Overzicht van de architectuur
De portefeuille-tracker bestaat uit drie onderdelen die via een PostgreSQL-database met elkaar communiceren. De indexer haalt gegevens op uit Hyperliquid, slaat deze op in de database, en de frontend vraagt de gegevens op uit de database om ze weer te geven.
Onderdelen van de tech stack
-
Frontend: React + TypeScript + Tailwind CSS + shadcn/ui & Radix UI
- Geeft handelsgegevens weer in een responsieve interface
- Controleer de peilingen-database om de 1000 ms op updates
- Regelt het wisselen van portemonnee via databaseverzoeken
-
Backend: Node.js-indexer met een polling-interval van 500 ms
- Haal gegevens op van 5 verschillende Hyperliquid-eindpunten
- Slaat gegevens op in PostgreSQL met de juiste precisieafhandeling
- Verwerkt verzoeken om van portemonnee te wisselen vanuit de frontend
In deze handleiding worden korte polling-intervallen gebruikt (500 ms voor de indexer, 1000 ms voor de frontend) om realtime updates te demonstreren. Je kunt deze intervallen indien nodig aanpassen:
- Frontend:
src/Dashboard.tsxregels 260-264 - Wijzig de1000waarde in:const interval = setInterval(async () => {
await fetchData(currentWallet);
}, 1000); - Indexeerder:
src/indexer/indexer.tsregels 623-630 - Wijzig de500waarde in:setInterval(async () => {
await indexer.checkForWalletSwitch();
await indexer.indexData();
}, 500);
Houd je gebruik van Quicknode en Supabase bij om de kosten te optimaliseren.
-
Database: Supabase PostgreSQL
- Slaat transactiegegevens op in 6 tabellen met financiële nauwkeurigheid (
DECIMAALsoorten) - Zorgt voor de communicatie tussen de frontend en de indexer via
verzoeken_om_van_portemonnee_te_wisselentabel - Maakt gebruik van unieke beperkingen om dubbele vermeldingen te voorkomen
- Slaat transactiegegevens op in 6 tabellen met financiële nauwkeurigheid (
-
Gegevensbron: Hyperliquid
infoeindpunt via Quicknode- Biedt accountgegevens, posities, bewaarplaatsbestanden, spot-saldi en delegaties
- Geeft gegevens weer in JSON-formaat, waarbij getallen als tekenreeks worden weergegeven om de nauwkeurigheid te waarborgen
- Toegankelijk via HTTP POST-verzoeken met de parameter ‘wallet address’
┌─────────────────┐
│ Perp Trader │
└─────────┬───────┘
│ 1. Voer het walletadres in
▼
┌─────────────────┐
│ React-dashboard │◄─────────────────┐
└─────────┬───────┘ │
│ 2. Verzoek opslaan │ 6. Gegevens lezen en weergeven
▼ │
┌─────────────────┐ │
│ Supabase │◄─────────────────┤
│ PostgreSQL │ │
└─────────┬───────┘ │
│ 3. Verzoek detecteren │ 5. Gegevens opslaan
▼ │
┌─────────────────┐ │
│ Indexer │──────────────────┘
│ (500 ms poll) │
└─────────┬───────┘
│ 4. HyperCore-gegevens ophalen
▼
┌─────────────────┐
│ Quicknode │
│ Hyperliquid │
│ Eindpunt │
└─────────────────┘
Verloop van de aanvraagprocedure
1e portemonnee-zoekactie:
- Gebruiker voert wallet in → Frontend controleert het verzoek en slaat het op in de database
- De indexer detecteert een verzoek (controleert elke 500 ms) → Schakelt over naar de nieuwe wallet
- Het verzamelen van gegevens begint → Haalt onafhankelijk gegevens op van 5 opgegeven eindpunten en slaat deze op in de database
- De frontend vraagt de database op (elke 1000 ms) → De gebruikersinterface wordt bijgewerkt met nieuwe gegevens die uit de indexer worden opgehaald
2. Het doorzoeken van portemonnees en meer:
- De gebruiker voert een nieuwe portemonnee in → De frontend roept een functie aan om alle gegevens van de vorige portemonnee te wissen en geeft de indexer de opdracht om over te schakelen naar de nieuwe portemonnee
- De indexer detecteert een nieuw verzoek → Schakelt onmiddellijk over naar de nieuwe wallet en begint met het ophalen van gegevens via het nieuwe walletadres
- Gegevens worden in realtime bijgewerkt → Het dashboard begint met het ophalen van de nieuwe posities en statistieken van de wallet
Projectopbouw
Het project is gebaseerd op een strakke, modulaire architectuur waarin de verantwoordelijkheden voor gegevensverzameling, UI-componenten en bedrijfslogica van elkaar zijn gescheiden. Deze structuur zorgt ervoor dat de codebase goed te onderhouden is en maakt het mogelijk om functies eenvoudig uit te breiden.
Overzicht van de rubrieken
├── src/
│ ├── indexer/
│ │ ├── indexer.ts # Hoofdindexering en portemonnee-beheer
│ │ └── apicalls.ts # Verzoeken aan het Hyperliquid-info-eindpunt
│ ├── components/
│ │ ├── ui/ # shadcn/ui-componenten (Button, Input, Card, enz.)
│ │ └── dashboard/ # Dashboardcomponenten (WalletHeader, PortfolioMetrics, enz.)
│ ├── shared/
│ │ ├── types.ts # TypeScript-interfaces en -typen
│ │ ├── utils.ts # Opmaak, berekeningen en hulpprogrammafuncties
│ │ ├── constants.ts # UI-constanten voor het dashboard
│ │ └── supabase.ts # Supabase-clientinstantie voor frontend-toegang
│ ├── Dashboard.tsx # Hoofdlogica van het dashboard
│ └── main.tsx
├── supabase/
│ └── schema.sql # Volledig databaseschema
├── package.json
└── .env
Het project uitvoeren
Stap 1: Kloon de repository
Kloon eerst de projectrepository en ga naar de projectmap:
git clone https://github.com/quiknode-labs/qn-guide-examples.git
cd qn-guide-examples/sample-dapps/hyperliquid-portfolio-tracker
Stap 2: Omgevingsbestand instellen
Maak je .env bestand door het volgende commando uit te voeren:
cp .env.example .env
Stap 3: Supabase-database instellen
Maak een nieuw Supabase-account aan of log in op je bestaande Supabase-account op de Supabase-website.
Maak een nieuw project aan en klik vervolgens op de knop ‘Verbinden’.
Selecteer in het gedeelte ‘App Frameworks’ de optie ‘React’ en wijzig de met behulp van veld naar Vite. Kopieer het VITE_SUPABASE_URL en VITE_SUPABASE_ANON_KEY waarden en voeg ze toe aan je .env bestand.
Ga ten slotte naar de SQL-editor in de rechterbovenhoek en plak de inhoud van de schema.sql bestand, en klik vervolgens op ‘Uitvoeren’. Hierdoor worden alle benodigde tabellen en functies aangemaakt die we nodig hebben om de gegevens voor de frontend op te slaan en op te halen.
Stap 4: Quicknode instellen
Maak je gratis proefaccount aan Quicknode-account, maak vervolgens je eerste Hyperliquid RPC-eindpunt aan en plak dit in je .env bestand.
Zorg ervoor dat je de bestaande /evm en voeg toe /info aan het einde van de URL van je Quicknode-eindpunt om toegang te krijgen tot de Hyperliquid-info-eindpunten.
Stap 5: Start de applicatie
Zodra de tabellen zijn aangemaakt en je omgeving is geconfigureerd, kun je het project starten door de volgende opdrachten uit te voeren in de hoofdmap:
npm install && npm run dev:both
Hiermee worden zowel de frontend-applicatie als de indexer gestart.
Zodra de indexer begint te draaien, wacht deze tot je een geldig walletadres invoert:
Open je frontend-pagina via de localhost-URL en klik op de knop ‘demo-portemonnee’ om een voorbeeldadres van een portemonnee te krijgen:
Nadat er naar een wallet is gezocht, begint de indexer elke 500 ms gegevens voor dat adres op te halen:
Op het dashboard worden realtime statistieken van de wallet weergegeven:
U hebt nu in realtime toegang tot uw rekeningtegoed, actieve posities en andere handelsgegevens.
Problemen oplossen
Tijdens het werken met de indexer kunt u tijdens de installatie of tijdens de uitvoering met de volgende problemen te maken krijgen:
- De indexer reageert niet meer
- Er worden geen gegevens weergegeven na het doorzoeken van de portemonnee
- De indexer per ongeluk gestopt
Oplossing:
Start de indexer opnieuw op door het volgende uit te voeren:
npm npm run dev:indexer
Probeer dan nogmaals te zoeken door een geldig walletadres in te voeren.
Een diepgaande blik op de codebase
Nu de portefeuille-tracker eenmaal draait, gaan we eens kijken hoe deze onder de motorkap werkt. In dit hoofdstuk gaan we dieper in op de drie kernonderdelen die het in realtime bijhouden van de portefeuille mogelijk maken:
De indexeerder - Ondersteunt Hyperliquid's info eindpunt via apicalls.ts, detecteert verzoeken om van wallet te wisselen en coördineert de gegevensverzameling vanuit 5 verschillende Hyperliquid-eindpunten om de 500 ms.
Het schema en de database – Toont de PostgreSQL-tabelopbouw waarin handelsgegevens met financiële nauwkeurigheid worden opgeslagen, inclusief het coördinatiemechanisme voor de communicatie tussen de frontend en de indexer.
Het dashboard (frontend) – Omvat het beheer van de React-status, het in realtime opvragen van gegevens uit de database, het valideren van walletadressen en de gebruikersinterface waarop live handelsgegevens worden weergegeven.
De indexeerder
De indexer draait als een afzonderlijk Node.js-proces dat elke 500 ms het Quicknode-eindpunt controleert. Hij haalt transactiegegevens voor het huidige walletadres op en slaat deze op in de database. De indexer wacht op verzoeken om van wallet te wisselen vanuit de frontend en zorgt voor procesisolatie met behulp van een vergrendelingsbestand.
Detectie van wisselgeld in de portemonnee
De indexeerder peilt de verzoeken_om_van_portemonnee_te_wisselen elke 500 ms de tabel controleren om wisselingen van de frontend-wallet te detecteren, waarbij statusvelden worden gebruikt om race conditions tijdens het wisselproces te voorkomen.
Hypervloeibaar info Integratie van eindpunten
De indexeerder maakt gebruik van de HyperliquidAPI les in apicalls.ts om te communiceren met het Hyperliquid-eindpunt van Quicknode. Elke API-methode volgt een consistent patroon voor het ophalen van verschillende soorten handelsgegevens:
// From apicalls.ts - Main account data fetching
async getClearinghouseState(walletAddress: string): Promise<ClearinghouseStateResponse> {
const payload = {
type: 'clearinghouseState',
user: walletAddress
};
const response = await fetch(QUICKNODE_ENDPOINT, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(payload)
});
return await response.json();
}
De getUserVaultEquities() de methode volgt dezelfde structuur, maar met type: 'userVaultEquities', waarbij wordt aangetoond dat voor elk eindpunt alleen het walletadres en het type eindpunt nodig zijn. Alle methoden beschikken over uitgebreide foutafhandeling en logboekregistratie voor het opsporen van problemen met handelsgegevens.
Een uitgebreide uitleg over de indexer
De hoofdindexeringslus roept 5 verschillende info eindpunten en slaat de resultaten op in afzonderlijke databasetabellen:
// From indexer.ts - Core data fetching and storage
const data = await hyperliquidAPI.getClearinghouseState(CURRENT_WALLET_ADDRESS);
const stateId = await this.storeClearinghouseState(data);
// Store positions with atomic replacement to prevent UI flickering
await this.storeAssetPositions(data.assetPositions, data.time);
// Fetch additional data types with error handling
try {
const rateLimitData = await hyperliquidAPI.getUserRateLimit(CURRENT_WALLET_ADDRESS);
await this.storeUserRateLimit(rateLimitData, timestamp);
} catch (error) {
console.log(`No rate limit data available for ${CURRENT_WALLET_ADDRESS}`);
}
De indexer gaat soepel om met storingen in afzonderlijke eindpunten: als één gegevensbron uitvalt, blijven de andere gewoon functioneren.
De indexer maakt gebruik van een bestandsgebaseerde vergrendeling om te voorkomen dat meerdere instanties tegelijkertijd worden uitgevoerd:
// From indexer.ts - Lock file creation and process checking
function createLock(): boolean {
if (fs.existsSync(LOCK_FILE)) {
const { pid } = JSON.parse(fs.readFileSync(LOCK_FILE, 'utf8'));
try {
process.kill(pid, 0);
console.error(`❌ Another indexer is already running (PID: ${pid})`);
return false;
} catch (e) {
fs.unlinkSync(LOCK_FILE); // Remove stale lock
}
}
fs.writeFileSync(LOCK_FILE, JSON.stringify({ pid: process.pid }));
return true;
}
De indexer maakt gebruik van een vergrendelingsbestand om te voorkomen dat er meerdere exemplaren tegelijkertijd worden uitgevoerd, waardoor de consistentie van de gegevens wordt gewaarborgd.
Het schema en de database (Supabase)
Nu we hebben gezien hoe de indexer gegevens verzamelt, gaan we eens kijken hoe die gegevens worden opgeslagen en gestructureerd. De PostgreSQL-database slaat handelsgegevens op in zes tabellen en regelt de communicatie tussen de frontend en de indexer. Elke tabel maakt gebruik van DECIMAAL velden voor financiële nauwkeurigheid en unieke beperkingen om dubbele invoer te voorkomen.
Voorbeelden van tabelstructuren
Tabel met activaposities – Slaat doorlopende handelsposities op met financiële nauwkeurigheid:
-- From schema.sql - Core trading data storage
CREATE TABLE asset_positions (
id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
wallet_address TEXT NOT NULL,
coin TEXT NOT NULL, -- Asset symbol (e.g., 'BTC', 'ETH', 'SOL')
size DECIMAL(20, 5) NOT NULL, -- Position size: 20 digits total, 5 after decimal
leverage_type TEXT NOT NULL, -- 'cross' or 'isolated' margin mode
leverage_value INTEGER NOT NULL, -- Leverage multiplier (1x, 5x, 10x, etc.)
entry_price DECIMAL(20, 5), -- Average entry price with 5 decimal precision
position_value DECIMAL(20, 5), -- Current USD value of the position
unrealized_pnl DECIMAL(20, 5), -- Profit/loss before closing position
liquidation_price DECIMAL(20, 5), -- Price at which position gets liquidated
margin_used DECIMAL(20, 5), -- Amount of margin allocated to this position
timestamp BIGINT NOT NULL, -- Unix timestamp in milliseconds from HyperCore
created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW() -- Database insertion time
);
-- Unique constraint prevents duplicate positions per wallet-coin pair
ALTER TABLE asset_positions ADD CONSTRAINT unique_position_per_wallet
UNIQUE (wallet_address, coin);
De DECIMAL(20, 5) Dit type biedt in totaal 20 cijfers, met 5 decimalen.
Tabel met verzoeken voor het wisselen van portemonnee – Coördineert de communicatie tussen de frontend en de indexer:
-- Uit schema.sql - Afstemming tussen frontend en indexer
CREATE TABLE wallet_switch_requests (
id UUID STANDAARD gen_random_uuid() PRIMARY KEY,
requested_wallet_address TEKST NIET NULL, -- Ethereum-adres (0x-formaat)
status TEKST NOT NULL STANDAARD 'in behandeling', -- Toestandsmachine: in behandeling → in verwerking → voltooid
created_at TIMESTAMP MET TIME ZONE STANDAARD NU()
);
-- Index voor efficiënte, op status gebaseerde zoekopdrachten door de indexeerder
CREATE INDEX idx_wallet_switch_requests_status ON wallet_switch_requests(status);
Deze tabel fungeert als een berichtenwachtrij tussen de React-frontend en de Node.js-indexer. Wanneer een gebruiker een nieuw walletadres invoert, voegt de frontend een 'in behandeling' verzoek. De indexeerder controleert of er 'in behandeling' verzoeken om de 500 ms, werkt de status bij naar 'verwerking' om race conditions te voorkomen, waarna de walletwissel wordt uitgevoerd. De statusprogressie zorgt ervoor dat er slechts één walletwissel tegelijk plaatsvindt, zelfs als gebruikers snel verschillende adressen opzoeken.
Het dashboard (frontend)
Nu de indexer gegevens verzamelt en de database deze opslaat, is de gebruikersinterface het laatste onderdeel. De React-frontend vraagt elke 1000 ms gegevens op uit de database om bijgewerkte handelsgegevens op te halen en geeft deze weer met behulp van modulaire componenten. Het systeem regelt het wisselen van wallet door verzoeken in de database in te voeren en de lokale status onmiddellijk te wissen.
Overzicht
De architectuur van het dashboard is gebaseerd op gecentraliseerd statusbeheer in combinatie met een modulaire opbouw van componenten:
// From Dashboard.tsx - Centralized state management
const [latestState, setLatestState] = useState<ClearinghouseState | null>(null);
const [positions, setPositions] = useState<AssetPosition[]>([]);
const [vaultEquities, setVaultEquities] = useState<UserVaultEquity[]>([]);
const [spotBalances, setSpotBalances] = useState<SpotBalance[]>([]);
const [isLoading, setIsLoading] = useState(true);
const [hasInitialData, setHasInitialData] = useState(false);
De Dashboard De component bewaart alle handelsgegevens in de React-state en geeft deze door aan onderliggende componenten als props. Dit patroon houdt het beheer van de state eenvoudig en maakt het gemakkelijk om de gegevensstroom tijdens het opsporen van fouten te volgen.
Polling met automatische verversing
De frontend vraagt de database elke 1000 ms op met behulp van een setInterval lus met de juiste opruiming:
// From Dashboard.tsx - Auto-refresh with cleanup
useEffect(() => {
if (currentWallet && hasStarted && hasInitialData) {
const interval = setInterval(async () => {
await fetchData(currentWallet);
}, 1000);
return () => clearInterval(interval);
}
}, [currentWallet, hasStarted, hasInitialData, fetchData]);
// Data freshness detection provides visual feedback
const isDataStale = latestState && (Date.now() - latestState.timestamp > 3000);
Het ophalen van gegevens start en stopt automatisch op basis van gebruikersacties en vindt alleen plaats wanneer dat nodig is, om systeembronnen te sparen. De interface geeft aan wanneer gegevens verouderd zijn (ouder dan 3 seconden), zodat gebruikers op de hoogte blijven van de actualiteit van de gegevens.
Patronen voor databasequery's
De frontend maakt gebruik van geoptimaliseerde zoekpatronen om handelsgegevens in realtime uit Supabase op te halen:
// From Dashboard.tsx - Real-time data queries
const { data: latestData, error: latestError } = await supabase
.from('clearinghouse_states')
.select('*')
.eq('wallet_address', walletAddress)
.order('timestamp', { ascending: false })
.limit(1)
.maybeSingle();
// Get all positions for this wallet
const { data: positionsData, error: positionsError } = await supabase
.from('asset_positions')
.select('*')
.eq('wallet_address', walletAddress)
.order('timestamp', { ascending: false });
if (positionsError && positionsError.code !== 'PGRST116') throw positionsError;
De query's gaan soepel om met gevallen waarin wallets geen handelsgegevens bevatten; er worden dan lege resultaten weergegeven in plaats van foutmeldingen.
Omgaan met het wisselen van portemonnee
De frontend controleert de geldportemonnee-adressen en wist de status onmiddellijk bij het overschakelen:
// From Dashboard.tsx - Wallet validation and switching
const isValidWalletAddress = (address: string): boolean => {
return /^0x[a-fA-F0-9]{40}$/.test(address);
};
const handleWalletSearch = async () => {
if (!isValidWalletAddress(address)) {
setError('Invalid wallet address format');
return;
}
// Clear ALL old data immediately when switching wallets
setLatestState(null);
setPositions([]);
setVaultEquities([]);
setSpotBalances([]);
setIsSearching(true);
// Signal indexer to switch
await switchIndexerWallet(address);
setCurrentWallet(address);
};
De interface controleert of wallet-adressen geldig zijn en wist oude gegevens onmiddellijk bij het overschakelen, waarbij een laadindicatie wordt weergegeven totdat de nieuwe gegevens zijn geladen.
Weergave van gegevens
De transactiegegevens worden vanuit de React-status doorgestuurd naar gespecialiseerde UI-componenten die de informatie opmaken en weergeven:
// From PortfolioMetrics.tsx - Portfolio overview card component
interface PortfolioMetricsProps {
totalAccountValue: number;
totalUnrealizedPnl: number;
userRateLimit: UserRateLimit | null;
vaultEquities: UserVaultEquity[];
delegations: Delegation[];
formatCurrency: (value: number) => string;
}
export const PortfolioMetrics: React.FC<PortfolioMetricsProps> = ({
totalAccountValue,
totalUnrealizedPnl,
formatCurrency
}) => {
return (
<Card className="bg-slate-900/50 border-slate-700/50 backdrop-blur-sm mb-6">
<CardContent className="p-4">
<div className="text-xs text-slate-400 mb-3 font-medium tracking-wide uppercase">
Perp Account Value
</div>
<div className="text-2xl font-bold text-white">
{formatCurrency(totalAccountValue)}
</div>
</CardContent>
</Card>
);
};
De Dashboard De component geeft berekende waarden en opmaakfuncties door aan onderliggende componenten, die zorgen voor de visuele weergave en opmaak van handelsgegevens.
Conclusie
Gefeliciteerd! Je hebt met succes een realtime Hyperliquid-portefeuillevolger gebouwd met behulp van het Hyperliquid-info-eindpunt van Quicknode. Je hebt geleerd hoe je doorlopende handelsgegevens kunt ophalen, een PostgreSQL-database kunt structureren voor financiële nauwkeurigheid en een responsief dashboard kunt bouwen dat in realtime wordt bijgewerkt. Deze basis opent de deur naar geavanceerde handelstools, zoals geautomatiseerde risicobewaking en het vergelijken van meerdere wallets.
Je kunt dit project verder uitbreiden door grafiekbibliotheken zoals Recharts te integreren of door handelsmeldingen te maken met behulp van je favoriete meldingsdienst. Bekijk onze andere Hyperliquid-handleidingen om meer manieren te ontdekken om met Hyperliquid aan de slag te gaan.
Volgende stappen
Nu je een werkende portefeuille-tracker hebt, volgen hier een aantal manieren om de applicatie uit te breiden en te verbeteren:
- Waarschuwingen bij liquidatie wanneer posities gevaarlijke marges naderen
- Het bijhouden van de prestaties van een portefeuille in de loop van de tijd met grafieken
- Kortere laadtijden tussen het doorzoeken van portemonnees
Aanvullende bronnen
Als je ergens niet verder komt of vragen hebt, stel ze dan op onze Discord. Blijf op de hoogte van het laatste nieuws door ons te volgen op Twitter (@Quicknode) of via ons Telegram-kanaal voor aankondigingen.
We ❤️ feedback!
Laat het ons weten als je feedback hebt of suggesties voor nieuwe onderwerpen. We horen graag van je.