Documentation
Adina Labs Technical Documentation
Dual-chain architecture on Ethereum and Arbitrum.
Contents
Overview
The Adina protocol is the shared set of on-chain smart contracts that powers every Adina Labs platform. It runs on Ethereum and Arbitrum, and every product in the ecosystem, starting with Adina Employment, is built on top of it.
Five contract domains make up the protocol: the ADINA token, a fee router, staking, a credential attestation registry, and escrow. They are deployed across two chains by design. Ethereum Layer 1 (L1) is the settlement and permanence layer, home to the canonical token, on-chain treasury, and on-chain governance (Adina Labs). Arbitrum Layer 2 (L2) is the execution layer, where high-frequency marketplace activity (postings, matches, escrows, and payouts) actually runs. ADINA is a single Ethereum Request for Comments 20 (ERC-20) token, paired with USD Coin (USDC) on both chains, and is the settlement asset across the entire ecosystem.
The protocol is fully non-custodial. Every state change is a user-signed transaction from a wallet the user controls. Mainstream users sign in with a familiar email or social login through Privy. Crypto-native users connect an Ethereum Virtual Machine (EVM) wallet they already own. In both cases, Adina Labs never holds keys and cannot sign on a user's behalf. The protocol verifies, routes fees, and settles.
Contract addresses, Application Binary Interfaces (ABIs), and verified-source links will be published after independent audits, ahead of the March 2027 Fair Launch Initial DEX Offering (IDO). For deeper technical detail, the full Whitepaper will be released in November 2026.
Trust boundary
The Adina protocol is built for non-custodial settlement on public chains. Deliberate, and by design. The code and the assets live on public blockchains, and no company, not even Adina Labs, sits between a user and their funds. This section describes exactly where the line is drawn, so anyone reviewing the protocol can verify that claim.
The trust boundary is a single line that separates what a user controls from what runs on public code. The website, matching engine, and encrypted credential store sit off-chain. The smart contracts on Ethereum and Arbitrum do not. The line sits between the wallet that holds a user's keys and those contracts, which execute only what a signed transaction instructs them to do.
Everything above the line is controlled by the user. Everything below it is public, audited code deployed on Ethereum and Arbitrum, readable by anyone. Adina Labs, as a company, sits outside both sides and cannot move funds or issue transactions on a user's behalf.
Value moves only when the user's wallet signs. Adina Labs sits outside both sides and cannot spend on a user's behalf.
Above the boundary
User side
Runs in the browser or wallet app. User controls the private key.
- dApp client. The web interface constructs and previews transactions but cannot broadcast them without a wallet signature. It holds no funds and no session credentials with spend authority.
- Sign-in and wallet. People sign in through Privy with an email or social account, or connect an Externally Owned Account (EOA) they already own. Private keys never transit an Adina Labs server, and every write to the protocol requires a fresh, explicit signature.
- Indexer. A read-only service that reconstructs user interface (UI) state from public contract events and Remote Procedure Call (RPC) calls. It is operated by Adina Labs, holds no signing keys, and cannot move funds. An indexer compromise degrades display, not custody.
Below the boundary
Protocol side
Runs on Ethereum L1 and Arbitrum L2. Deployed on mainnet after audit. Executes as written until a timelocked upgrade is approved on-chain.
- Contracts. Token, fee router, staking, credential attestation registry, and escrow. Built on OpenZeppelin primitives, developed with Hardhat and Foundry, and reviewed by an independent auditor before mainnet deployment.
- Caller verification. Every state-changing call must come from the user's wallet address as
msg.sender. If the caller is not authorized, the transaction reverts. There is no back door that lets Adina Labs sign on a user's behalf. - Upgradeability. Where contracts are upgradeable, changes require an on-chain multisig and a public timelock. There is no silent admin key. Every proposed change is visible on-chain before it takes effect. At launch, that multisig is controlled by the founding team. Governance is designed to move toward community control over time.
In practice, a user trusts the maths of Ethereum and Arbitrum and the audited contracts on-chain. They do not need to trust Adina Labs' servers, front-end hosting, or any off-chain service to keep their funds safe. Funds move only when the user's wallet signs. That is what "non-custodial" means here. Matching and credential storage still run off-chain; settlement and attestations are on-chain. The protocol runs independently of any single interface, and any compatible client can interact with the same public contracts.
Dual-chain topology
The Adina protocol is deployed across two Ethereum-family chains, not one. This is a deliberate architectural choice. Ethereum L1 is the most secure smart contract environment in production. Arbitrum L2 is the most established Ethereum rollup, running the same EVM at a fraction of L1 transaction costs. The protocol uses both, and uses each for what it is best at.
We chose the EVM over building a bespoke chain because the EVM has the deepest pool of audited libraries, tooling, and independent security research in Web3. We chose Arbitrum over running everything on L1 because posting a job, releasing a milestone from escrow, or settling a micro-payment on Ethereum L1 alone would be too slow and too expensive for real users. Dual-chain is a division of labor, not a replacement for Ethereum.
Everything that must be permanent, censorship-resistant, and maximally secure lives on Ethereum L1. Everything that must be fast and low-cost to be usable lives on Arbitrum L2. The two chains talk to each other through Arbitrum's canonical bridge, which is user-signed like every other action in the protocol.
Every arrow between layers is a user-signed transaction on the canonical Arbitrum bridge. The protocol does not move balances on a user's behalf.
Ethereum L1
settlementThe permanence layer. Ethereum L1 holds the canonical ADINA token, the on-chain treasury, and on-chain governance (Adina Labs). Withdrawals from Arbitrum to Ethereum use the standard rollup exit path, which includes a challenge window. That trade-off is acceptable because day-to-day activity does not live on L1.
- Canonical ADINA token security
- Treasury multisig
- On-chain governance (Adina Labs)
- Final settlement and withdrawal anchor
- ADINA/USDC settlement pool (USD 1.8M at launch)
Arbitrum L2
executionThe activity layer. Arbitrum is EVM-equivalent, so Solidity, OpenZeppelin, Hardhat, and Foundry work as on Ethereum with familiar tooling, at a fraction of L1 gas. L2 block timing, gas accounting, and L2→L1 exits follow Arbitrum's rollup rules. Arbitrum is one of the most established Ethereum rollups, with deep DeFi liquidity, which matters for pricing ADINA against USDC in a public pool.
- Credential Attestation Registry
- Match attestations
- Staking for credential confirmation (later phase)
- Gig Economy escrow, milestones, and dispute resolution (later phase)
- Fee router and buy-and-burn execution
- High-frequency role posts, payouts, and swaps
- ADINA/USDC execution pool (USD 4.2M at launch)
In practice, this means enterprise-grade security for the assets and rules that must never change, and consumer-grade speed and cost for the day-to-day actions users take. Bridging ADINA between Ethereum and Arbitrum is always a user-signed action. The protocol does not move balances on a user's behalf.
Contract domains
The Adina protocol is a set of five smart contract domains that share a single token and a single custody model. Each domain has a defined responsibility, is built on OpenZeppelin primitives, and is developed and tested with Hardhat and Foundry. All five undergo independent security audits before any mainnet deployment. Their addresses, verified source, and ABIs will be published together, ahead of the March 2027 Fair Launch IDO.
Contracts are placed on Ethereum L1 or Arbitrum L2 by security-versus-cost trade-off. The canonical token, on-chain treasury, and on-chain governance (Adina Labs) live on L1. Everything transactional lives on L2.
Token
Ethereum L1 · Arbitrum L2 (bridged)Fixed-supply ERC-20. Hard cap of 1,000,000,000 ADINA. No inflation and no additional minting after genesis. The canonical contract lives on Ethereum L1, with a bridged representation on Arbitrum L2. ADINA is paired against USDC on both chains. Adina is a utility and governance token for platform access, fee settlement, and protocol voting within the Adina Labs ecosystem. It is not offered as a security or an investment product.
Fee router
Arbitrum L2Every fee-bearing platform action is settled through the fee router. Gross value splits three ways at contract execution: 65% to the operating company that runs and grows each platform, 30% to the Protocol Treasury Vault, and 5% to a programmatic buy-and-burn against public ADINA/USDC pools. The burn share starts higher at launch and steps down to 5% over time, with every change made through a timelock. The router runs on Arbitrum L2 alongside the activity it settles.
Staking
Arbitrum L2Staking applies to credential confirmation in a later phase, not to matching itself. Candidates may stake ADINA to confirm specific claims on their profile, such as a degree or employment dates, with partial or full confirmation levels. Employers may stake when posting a role. Staking is an economic commitment on those actions, not a gate to running a match.
Attestation registry
Arbitrum L2Stores Keccak-256 fingerprints of off-chain credential and match records. The registry never receives Personally Identifiable Information (PII) or raw documents. Its structure is designed to accept Zero-Knowledge Proofs (ZKPs) later, without breaking the anchoring model.
Escrow and settlement
Arbitrum L2 · Ethereum L1 (finality)Gig contracts, milestone releases, and dispute resolution for the Gig Economy Platform are contract flows. Funds move into escrow on a user signature and release only when the coded conditions are met. Final withdrawal to Ethereum L1 uses the standard Arbitrum canonical bridge.
Wallets and authentication
Every action that changes protocol state requires a signature from a wallet the user controls. That is the entire authentication model. Adina Labs does not run a login system that can spend on a user's behalf, does not hold session credentials with transaction authority, and does not have an admin path around the signature check. If any of those things existed, custody would sit with Adina Labs, and this would no longer be a non-custodial protocol.
There are two ways in, and both are first-class. Mainstream users sign in with a familiar email or social login through Privy, so they can start without installing anything or learning how wallets work. Crypto-native users connect a wallet they already own. Neither path gives Adina Labs custody, and the full private key never sits on an Adina Labs server.
Crypto-native path
Bring your own wallet
For users who already hold assets on Ethereum or Arbitrum.
- Standard. Any wallet that implements Ethereum Improvement Proposal 1193 (EIP-1193) or WalletConnect. That covers MetaMask, Coinbase Wallet, hardware wallets like Tangem, and any mobile wallet that supports WalletConnect.
- Interface. The dApp uses the wallet's native signing interface. No custom modal, no seed-phrase prompt, no browser extension of our own.
- State. Nothing about the wallet is persisted on Adina Labs servers.
Mainstream path
Sign in with Privy
For users who are new to Web3.
- Familiar login. Sign in with an email address or social account, the same way as any app. No extension to install and no seed phrase to manage.
- No custody. Privy authenticates the person. Signing in gives Adina Labs no custody and no signing authority, and Adina Labs never sees private keys.
- One account. The same sign-in works across every Adina Labs platform.
For any action that changes protocol state, the dApp constructs the transaction (for example, an attestation write, a stake lock, a Credit purchase, or an escrow release), the wallet prompts the user to review and sign, and the signed transaction is broadcast to Ethereum or Arbitrum through a standard EVM RPC. Read-only indexers observe the resulting logs to reconstruct UI state. Indexers hold no keys and cannot originate a spend.
Wallet connect is separate from identity verification. See Identity verification.
Identity verification
Adina Employment connects real job seekers with real employers: humans talking to humans, not bots. Verification is optional. Candidates and employers can tap Get verified to complete identity verification and receive a blue badge on their account.
Optional. Identity verification complete. Blue badge on the profile.
Former managers, colleagues, and institutions confirm a candidate's history, shown beside their experience.
On-chain fingerprint. Proves a record has not been altered.
Later phase. Candidates stake ADINA to confirm specific claims, such as a degree or employment dates.
KYC data stays off-chain through regulated providers. Connecting a wallet does not verify identity.
Credential integrity on-chain
Employment histories and gig-work performance records contain personal information that has no place on a public blockchain. At the same time, the value of that data comes from being able to prove it has not been altered. The Adina protocol resolves that tension with a hybrid design: the sensitive payload stays in encrypted off-chain storage, and the chain holds only a cryptographic fingerprint of it.
Nothing on the chain reveals what the credential says. What the chain provides is a permanent, tamper-evident record that a specific payload existed at a specific time, was recorded by the owner, and has not been modified since. Anyone holding the original payload can recompute the fingerprint and match it against the on-chain record. No trust in Adina Labs is required to run that integrity check.
PII stays off-chain. The chain stores only a Keccak-256 digest, an owner address, and a timestamp.
Off-chain payload
Encrypted object storeThe full credential payload, the transcript, contract, review, or performance record, lives in encrypted off-chain storage. Access to the payload is controlled by the user who owns it. The chain never sees the raw document or any personally identifiable information.
Keccak-256 fingerprint
bytes32 digestThe payload is hashed with Keccak-256, the native EVM hashing primitive. Keccak-256 is a fixed-length, collision-resistant one-way function: it produces a 32-byte digest that changes completely if a single character of the payload changes. Anyone holding the original payload can recompute the digest and check it.
On-chain attestation
Attestation registry on Arbitrum L2The digest is written to the attestation registry on Arbitrum L2, together with the owner's address and a timestamp. Only those three fields are stored on-chain. Any subsequent edit to the off-chain payload produces a different digest and fails verification against the record.
Independent verification
Recompute and compareA counterparty who receives the original payload hashes it locally and compares the digest to the one on-chain. A match proves the payload is unmodified and was attested to at the recorded time. A mismatch proves the payload has been altered or is not the one that was attested to. No trust in Adina Labs is required to run this check; the verification is a public function call.
The registry is deliberately minimal. It stores only what is needed to make integrity provable: a digest, an owner address, and a timestamp. This creates a clean upgrade path for Zero-Knowledge proofs after mainnet. Later releases can attach Zero-Knowledge (ZK) circuits that prove statements about credential data, without putting that data on-chain. The Keccak-256 anchoring layer stays as the base. New proof types can be added without rewriting existing on-chain records.
Marketplace matching
Adina Employment matches candidates to roles with Adina Labs' Almega+™. Almega+™ goes beyond keyword matching: every suggestion comes with the reasons behind it, never a score, and a person on the hiring team always makes the decision. Every match is written to the chain as an attestation either party can verify later.
Adina Labs' Almega+™ runs off-chain against verified accounts and profile data. The durable output is an on-chain match attestation, not a proprietary score.
Verified accounts and profile data
Candidate profiles and the requirements of an open role.
Adina Labs' Almega+™
Adina Labs' Almega+™ is the advanced matching mechanism for Adina Employment. It runs off-chain, does not write personally identifiable information to the chain, and returns written reasons rather than a score. Full technical detail will be published in the Whitepaper in November 2026.
On-chain match attestation
The match result is written to the attestation registry on Arbitrum L2 as a portable record. Either party can recompute and verify it later. A match attestation is valid across any Adina Labs platform that reads from the same registry.
Credits, liquidity, and the fee router
Credits keep platform prices in dollars. The fee router splits each fee three ways: 65% to the operating company, 30% to the Protocol Treasury Vault, and 5% to a programmatic buy-and-burn.
Services are denominated in Credits at USD 1.00 each, so platform prices do not float with the token. A Credit purchase is a user-signed transaction that market-buys ADINA on public ADINA/USDC pools and credits the user's on-chain balance. Platform prices stay in dollars. The user does not need to hold or price ADINA manually to use a platform; the buy path still creates on-chain demand.
Launch liquidity is dual-pool, 70/30 weighted to L2: USD 4.2M ADINA/USDC on Arbitrum for escrow, verifications, swaps, and payouts; USD 1.8M ADINA/USDC on Ethereum for institutional depth. The same pair on both chains keeps pricing in a dollar-stable unit.
At execution, the fee router splits gross transaction value three ways: 65% to the operating company that runs and grows each platform, 30% to the Protocol Treasury Vault, and 5% to a programmatic buy-and-burn that purchases ADINA from the pools and retires it. The burn share starts higher at launch and steps down to 5% over time. Supply only decreases, and the token contract has no mint path after genesis.
Escrow, milestone payouts, and dispute resolution belong to the Gig Economy Platform and run as L2 contract flows. They ship in a later phase, and the settlement domain is specified now so later platforms reuse the same contracts.
Security model
Adina Labs and the protocol hold no keys. Signing in through Privy grants no custody.
User signature required for every value-moving or attestation-writing call.
OpenZeppelin libraries; Hardhat and Foundry tests; independent audit before mainnet.
Encrypted off-chain. On-chain stores only Keccak-256 digests and owner metadata.
Read-only. Compromise of the indexer can degrade UX, not drain wallets.
Arbitrum optimistic window applies to L2→L1 exits. In-L2 activity confirms on L2 timescales.
Hash-based integrity proofs. Anyone can verify without trusting Adina Labs.
Implementation stack
Established open-source Web3 infrastructure. No custom L1.
Status
Adina Employment
Adina Employment launches in 2027, after the March IDO. Join the waitlist for early access.
adinaemployment.comPublished now
This architecture, tokenomics, and the Fair Launch IDO terms. Integration conversations via email.
community@adinalabs.comNot published yet
Mainnet addresses, ABIs, npm Software Development Kit (SDK). Those follow audit. Engineering discussion is on Discord.
discord.gg/pKKUmyzxVgFrequently Asked Questions (FAQ)
Still have questions?
Reach the team at community@adinalabs.com