Betalningskedjor Jag är ingen expert på betalningar, men jag har arbetat i 3/5 av de stora bankerna i Kanada, samt flera fintech-företag som bygger betalningsskenor och flyttar mycket pengar med kod – och nu senast på högpresterande kedjor det vill säga att jag har vissa åsikter om konceptet med en högpresterande kedja för betalningar detta kommer att bli ett långt inlägg så jag föreslår att du klickar på grok-knappen längst upp till höger För det första, hur kan en blockkedja ha ett betalningsfokus i första hand? Tidigare har det funnits flera tillvägagångssätt en är att begränsa kedjans programmerbarhet och inte vara Turing-komplett, detta är vad Stellar/XLM gjorde för många år sedan Detta fungerar men begränsar drastiskt vad som är möjligt på kedjan en annan är att tillåta kedjan, detta är vad många företagskedjor har försökt tidigare, och det verkar som om det är vad Tempo kommer att öppna med Detta fungerar i teorin men suddar ut gränsen mellan vad en blockkedja är kontra traditionella databaser Ett tredje alternativ som inte riktigt har gjorts tidigare är anpassad sekvensering och blockutrymmesregler för att prioritera/reservera block för betalningar TXN-typer detta är faktiskt ganska intressant men relativt avancerat ur ett designperspektiv, och jag misstänker att Paradigm är ett av de mycket få team som faktiskt kan hjälpa till att klara av det det finns några lösa paralleller till befintliga kedjor, t.ex. lokala avgiftsmarknader på Solana (till viss del) och Sui fast path (även om detta kommer att försvinna) men det närmaste är förmodligen Hyperliquids maker-prioritering (där avbokningar prioriteras så att MM:erna har en fördel jämfört med tagare) Detta skulle i teorin kunna fungera i en miljö utan tillstånd, men skulle vara extremt svårt att genomföra i praktiken ...