0age

@0age

173 Following

62435 Followers

0age pfp

https://x.com/z0age/status/1877127753956471235?s=46&t=LVgsZTPvHfabQtdsMW40fA

4 replies

15 recasts

90 reactions

0age pfp

0 reply

0 recast

1 reaction

0age pfp

elementary, really

3 replies

4 recasts

40 reactions

0age pfp

check it out, make some PRs, and stay posted as the onslaught of repos continues over the coming weeks and months we'll get there sooner than many expect — and we'll get there faster by working together mad respect for all the builders jumping into my DMs with q's & making PRs

0 reply

0 recast

1 reaction

0age pfp

for chains that don't use priority ordering, you can change out the priority tax mechanic and use something like a reverse dutch auction or an RFQ where the filler is selected based on a quote there's also a "directive" that maps to a cross-chain message Tribunal will dispatch

1 reply

0 recast

1 reaction

0age pfp

if a chain commits to priority ordering, you can actually run a fair auction where any filler can compete to fill the swap the output tokens the filler will pay are increased (or the input tokens they can claim are decreased) based on the priority fee it's beautifully simple

1 reply

0 recast

1 reaction

0age pfp

this initial version of Tribunal is focused on fill side chains with sequencers that enforce priority ordering this just means the sequencer orders all transactions in the block by gas price it's the de-facto behavior on all OP-stack chains today, & Unichain will enforce this

1 reply

0 recast

1 reaction

0age pfp

that's where Tribunal comes in it serves two core functions first, it protects fillers from settling a swap that another filler got to first second, it protects swappers from having claims processed from unrelated payments (like if you tried to do 2 cross-chain swaps at once)

1 reply

0 recast

1 reaction

0age pfp

most development effort thus far for The Compact has focused on the claim side that's where the resource locks are, of course allocators (mediating resource locks) & arbiters (processing claims) both live on the claim side too but arbiters need to act on a cross-chain action

1 reply

0 recast

1 reaction

0age pfp

so there are two "sides" to a cross-chain swap using The Compact or other resource locks the "fill side" is the chain where their output tokens are received the "claim side" is the chain where their input tokens are held & claimed by a filler

1 reply

0 recast

8 reactions

0age pfp

open-sourcing another piece of the cross-chain swap puzzle a framework for settling swaps on destination chains, handling disputes between fillers & redirecting MEV to swappers in the process: Tribunal ☝️ https://github.com/Uniswap/Tribunal let's get into what Tribunal's about 💬

2 replies

9 recasts

41 reactions

0age pfp

The “AdvancedCall” version here specifies regions of returndata and calldata where the former gets returndatacopy’d to fill in the latter in subsequent calls

0 reply

0 recast

1 reaction

0age pfp

https://github.com/dharmaprotocol/dharmaOS/blob/main/contracts/Wallet.sol

1 reply

0 recast

1 reaction

0age pfp

one final caveat here: this is really not meant for production use at all if you're working on chain abstraction & curious about how The Compact works i highly encourage you to give Smallocator a whirl much more to come; this is just another small step 🤏

0 reply

0 recast

2 reactions

0age pfp

📊 GraphQL integration with The Compact Indexer for multi-chain indexing 💾 Persistent storage using PGLite to track attested compacts and used nonces 🔎 Comprehensive validation pipeline to ensure resource locks never end up in an overallocated state

1 reply

0 recast

2 reactions

0age pfp

Smallocator features: 🔐 Secure session-based authentication using EIP-4361 ✍️ EIP-712 Compact message validation & signing on demand from session-gated accounts 🤫 No witness data or signature provided, sponsor intents stay secret (only typestring & witness hash is supplied)

1 reply

0 recast

2 reactions

0age pfp

this codebase is meant to serve as a reference if you want to learn more about allocators you can click around on the frontend (link on the readme) as well as with the API (the "main course") it's also a good starting point if you're looking into running an allocator yourself!

1 reply

0 recast

2 reactions

0age pfp

another approach is to run it in a server like Smallocator granted, fillers and solvers are counting on the server not to let users double-spend but it's fast & basically free it also delays revealing info about the cross-chain swap or other action to help avoid getting 🥪'd

1 reply

0 recast

2 reactions

0age pfp

arguably the most straightforward allocator would be a purely onchain contract to fill a cross-chain swap, you'd call this contract, it'd check your balance and your pending compacts, and reserve the tokens for you for a little while but this is slow, pricey, and not private

1 reply

0 recast

2 reactions

0age pfp

so the way that The Compact works is that you deposit into resource locks when you do, you choose an allocator for that lock then when you create a compact (e.g. a request to take some action) they make sure you're not double-spending & "attest" that the compact's good to go

1 reply

0 recast

6 reactions