Cross_Chain — LUKSO Universal Profile cross-chain toolkit
Browser tools by ChainIntegrate for redeploying an existing LUKSO Universal Profile (UP) at the same address on other EVM chains, then checking and using it there.
What it contains, in short:
- Redeploy and check the UP on another network (Deploy, Verify, Backup controller, Identity, NFT reception, Publish implementation): the guide walks through them.
- UP Wallet (
up-wallet.html, experimental): the UP's wallet on every network where it exists; it connects to dApps through WalletConnect, explains and simulates every request, and signs through the controller's wallet (MetaMask, on the website). Also an Android app and a browser extension, each signing with a key of its own kept on the device.
- Gas paid by the site (experimental): an ERC-4337 relayer and two paymasters, so a UP's controller needs no gas on the networks the site serves; paid subscriptions are in beta.
Non-custodial throughout: the pages never hold a key, and every transaction is signed in the user's own wallet (in the Android app and the browser extension, with a key that stays on the device and that only the user can unlock).
The system
Four parts. This README describes the whole system; each repository's own README describes its part in detail.
| Part | What it is | Where |
|---|
| The website | The toolkit (deploy, verify, backup controller, identity, NFT reception), UP Wallet, the gas relay's pages; the relayer (tools/relayer) and the contracts (contracts/) | this repository, public |
| UP Wallet for Android | UP Wallet on the phone, signing with the phone key (Android Keystore, fingerprint or PIN) | up-wallet-android, public |
| UP Wallet for the browser | UP Wallet on the computer (Chrome, Edge, Brave), signing with the computer key (passkey or password), with WalletConnect kept alive in the extension | up-wallet-extension, public |
| The signing service | The approvals of the paid paymaster and the subscriptions (gas paid by the site, beta) | private: it holds a key and its rules; described here and in AUDIT.md |
How they fit together:
- One page, three places. The app and the extension package UP Wallet's page from this repository at a pinned commit (their
UPSTREAM.json): the same checks, decoders and request window on the site, the phone and the computer. Changes to the page are collected in WALLET-BACKLOG.md and made in batches, then an app and an extension release.
- One key per device. The phone and the computer each have their own key, never exported or copied, authorized on the UP from the website's Backup page ("Authorize a device", once per network, by an admin controller), with no admin permissions; each controller can have a name kept on the UP.
- The server runs the website, the relayer and the signing service, two different things: the relayer (
tools/relayer, public, in this repository) sends the UPs' operations to the network and pays their gas up front, refunded by the paymaster; the signing service (private) sends nothing and holds no funds: it only approves, with its key, the operations that the sponsor paymaster may pay. Both accept the website's and the extension's origins.
- One register of the reviews, for the whole system: AUDIT.md (summary under "Audit trail").
Where to use it
What this is, and what it is not
- Not an official LUKSO product. It is an independent project by ChainIntegrate, built on LUKSO's public contracts and standards. LUKSO does not maintain, endorse or support it.
- Transparent by design. All the code the user runs is open source: the pages and the relayer here, the Android app and the browser extension in their repositories. The only part that is not public is the sponsor service's signing server, which holds a key and its rules; its behaviour is described here and in AUDIT.md. Before anything is signed, UP Wallet says in plain words what a request does, simulates it and shows what will change; after it, every operation links to the network's explorer. The reviews and their findings are published in AUDIT.md, open items included.
- Free to use, at your own risk. No account and no sign-up. The pages warn at their first opening, and before every irreversible step, about what can go wrong; read the warnings. The tools are experimental and not professionally audited (see "Audit trail"). Only the gas paid by the site is a service: for the UPs on its list, or with a paid subscription (beta).
- Help it get better. When UP Wallet meets a call it cannot explain, it offers to copy the call's data or to e-mail it (your mail app opens; you decide whether to send). Sending it is the most useful help: the next version can decode that call for everyone. Bug reports are welcome too, as GitHub issues (CONTRIBUTING.md); security problems privately (SECURITY.md).
How it works
A UP is created by LUKSO's LSP23LinkedContractsFactory, which lives at the same address (0x2300000A84D25dF63081feAa37ba6b62C4c89a30) on every EVM chain where it has been published. The profile's address is a CREATE2 result computed from the entire original creation calldata (deployERC1167Proxies, selector 0x6a66a753). If you send that exact calldata to the factory on another chain, you get the same UP (LSP0) and Key Manager (LSP6) addresses there. The controller that gets control of the profile is the one named in that calldata.
Missing implementations
A UP is a proxy that delegates everything to an implementation contract (LSP0 for the profile, LSP6 for the Key Manager). The implementation addresses are part of the calldata, and they depend on the contract version used by the tool that created the profile, not on the creation date. Two profiles created on the same day can therefore point to different versions. If a profile's implementations do not exist on the target chain, the redeployed profile would be "mute", so the Deploy tool blocks it.
LUKSO published its implementations through Nick's deterministic deployment proxy (0x4e59b44847b379578588920cA78FbF26c0B4956C), which lives at the same address on almost every EVM chain. Replaying the original transaction there creates the implementation at the same address. up-publish-implementation.html does this: it reads the original transaction from LUKSO, checks that it produces exactly the expected address, and has any wallet sign it. The operation is permissionless, gives nobody control over any profile, and only costs gas.
Contracts published with this tool (frozen list)
The first missing contracts published with up-publish-implementation.html, all through Nick's factory with one transaction per contract, with bytecode identical to LUKSO mainnet.
This list is frozen and will not be extended. If you publish missing LUKSO contracts on another chain, report them to LUKSO (for example with an issue in lsp-smart-contracts), not here. See CONTRIBUTING.md.
The deployed bytecode is identical to LUKSO mainnet. LUKSO has been informed, with a request to verify the source code on Polygonscan: lukso-network/lsp-smart-contracts#1151.
The tools never ask for a private key. The calldata is public on-chain data, and every transaction is signed in your own wallet.
Contents
| File | Purpose |
|---|
up-deploy-public.html | Deploy tool (public). Connects your UP, decodes the calldata and checks that it produces your address. It shows every controller and its permissions, then checks the target chain: wallet/RPC chain match, free addresses, implementation bytecode, gas and balance. Finally it deploys and verifies the resulting bytecode. At the end it links to the backup page, with the same network and UP. It also has an optional LYX donation panel. |
up-backup.html | Backup controller. Adds a backup controller (a second account with exactly the signer's permissions, AllowedCalls included) or removes a lost one, on any network where the UP exists, LUKSO included: one Key Manager transaction, simulated first and re-read after confirmation. The UP's address comes from the extension or LUKSO's Universal Profiles app, or is typed; the genesis key is recognized from the UP's creation transaction on the LUKSO explorer (a calldata counts only if it predicts this UP's address). Authorize a device (the UP Wallet app from 0.9.0, the browser extension): adds the app's phone key or the extension's computer key as a controller with no admin permissions but access to the UP's funds, SUPER_CALL, SUPER_TRANSFERVALUE, SIGN, the 4337 permission and SETDATA restricted to LSP3Profile by AllowedERC725YDataKeys (never controllers, permissions or extensions), with the same checks, plan, simulation and re-read; ?phone= fills it in from the app. A lost phone is revoked with "Remove". Controller names: a name for each controller ("Office PC · extension"), kept on the UP on each network, so that the page and UP Wallet show it on every device: an LSP2 mapping key, bytes10(keccak256("UPWalletControllerName")) + 0000 + the controller's address, whose value is the name in UTF-8 (at most 64 characters, one line). Given with "Authorize a device" in the same transaction, or later for any controller (one setData, a label only); cleared with "Remove". Public, as the controllers' addresses are. One key per device by choice: no key is ever exported or copied between devices. |
up-verify-only.html | Verify only. A read-only check of whether a correct deploy of a given calldata exists on a chain, and whether the implementations it points to are present there. |
up-test-operazione.html | Test. Writes a test key () through the Key Manager and reads it back, to prove the controller can operate the profile on the new chain. |
Usage
Online
The pages are published at https://crosschain-lukso.chainintegrate.it/. Start with the guide: up-crosschain-guide.html.
Android app (experimental)
UP Wallet on the phone (up-wallet-android, 0.9.7
today, APKs on its GitHub releases, not on the Play Store yet). Since 0.9.0 the app is the wallet: it
signs with a key created and kept on the phone (Android Keystore, fingerprint or PIN for every
signature), with no MetaMask. dApps connect through WalletConnect (a link pasted or shared, or a QR code
scanned), and a notification says when a request arrives. Experimental: the maintainer's own wallet,
small amounts, at your own risk. Details (the key, the permissions, versions, the Play Store plan): its
README. Privacy policy:
up-wallet-app-privacy.html.
Browser extension (experimental)
UP Wallet on the computer (up-wallet-extension,
0.1.7 today, zips on its GitHub releases, loaded in developer mode in Chrome, Edge or Brave). It is to the
computer what the app is to the phone: it signs with a key kept in the extension, opened with a passkey
(Windows Hello, Google Password Manager) or a password, in a small signing window that shows what is
signed; WalletConnect lives in the extension, so dApps stay connected with the wallet closed. Experimental:
the maintainer's own wallet, small amounts, at your own risk. Details (install and update, the key, the
signing window): its README.
For both: one key per device, by choice. Each key is authorized once per network from the Backup page
("Authorize a device", signed by an admin controller such as MetaMask), with no admin permissions but
access to all the UP's funds; a lost device is revoked alone, and the others keep working. Before a
revoke, the device's panel ("This phone", "This computer") sends the key's own balance to the UP.
Advanced: tools/decrypt.js (offline only)
Only for people who know exactly what they are doing. You normally don't need it: the controller key can be exported directly from the Universal Profile extension (Settings → Developer → Reveal private key, guide step 1). The script only helps in unusual setups, for example an extension installation whose controller is not the profile's original one, when the original key is only in an old backup.
It runs locally and offline (node tools/decrypt.js); instructions are in tools/README.md. It is not served by the website (see below).
Publishing the website
The site is deployed by running git pull in the web root (https://crosschain-lukso.chainintegrate.it/), so the whole repository lands on the server. The HTML pages, the shared scripts (site-ui.js, call-decode.js, abi-decode.js, token-image.js, chains.js, theme.js, backup-check.js, deploy-check.js, asset-list.js, sign-check.js, usd-price.js, op-cost.js, lifi-topup.js, gas-relay-client.js, gas-relay-page.js), vendor/, the images and guide-assets/ are website content. The .git/ folder and tools/ must not be reachable from the web.
The web server on this host does not apply .htaccess, so the protection is done in the server's git clone. It works with any web server. Run this once, inside the site folder on the server:
# 1. Keep tools/ out of the web root: files outside the pattern are removed now and on every future pull.
git sparse-checkout set --no-cone '/*' '!/tools/'
# 2. Move the git metadata out of the web root, into a folder shared by all sites' git dirs.
# Create it once (the only step that needs sudo), owned by the deploy user:
sudo mkdir -p /var/www/repos && sudo chown ubuntu:ubuntu /var/www/repos && sudo chmod 750 /var/www/repos
# `.git` becomes a one-line file containing only a path.
mv .git /var/www/repos/crosschain-lukso.git && echo "gitdir: /var/www/repos/crosschain-lukso.git" > .git
/var/www/repos is not the root of any site, so it is not reachable from the web. Always run git pull as the deploy user (ubuntu), never with sudo: root-owned files would break the next pull.
After that, git pull works exactly as before. The root .htaccess stays in the repository as an extra safety net for hosts that do apply it (Apache).
Site configuration. Some pages read their settings from config.js, which is not in the repository. Create it once on the server, in the site folder, by copying config.example.js and filling in the values; git pull leaves it untouched. Its values are not secret (the browser receives them): protect the WalletConnect Project ID with the allowed-domains list in the Reown dashboard, and the Alchemy API key (used by the Identity and UP Wallet pages to list a UP's tokens and NFTs) with the app's domain allowlist in the Alchemy dashboard.
Security headers. The web server (nginx) adds these headers to every response, pages and images: no other site may show the pages in a frame (X-Frame-Options: DENY, frame-ancestors 'none'; UP Wallet signs transactions, so it must not be framed by a site that could trick clicks), files keep their declared type (X-Content-Type-Options: nosniff), no referrer is sent (Referrer-Policy: no-referrer), and a fixed Content-Security-Policy:
default-src 'self'; script-src 'self' 'unsafe-inline' https://cdnjs.cloudflare.com/ajax/libs/ethers/6.13.4/; style-src 'self' 'unsafe-inline'; img-src 'self' data: blob: https:; font-src 'self' data:; connect-src 'self' https: wss://relay.walletconnect.org wss://relay.walletconnect.com; frame-src https://verify.walletconnect.org https://verify.walletconnect.com; worker-src 'none'; object-src 'none'; base-uri 'none'; form-action 'none'; frame-ancestors 'none'
connect-src allows any HTTPS host because the pages talk to the RPCs and explorers of many networks, custom RPCs included; img-src too, because profiles and tokens point to images anywhere. Scripts are restricted by a second policy in each page: a <meta http-equiv="Content-Security-Policy"> whose script-src allows the site's files, ethers from the CDN and the page's own inline scripts by their SHA-256 hash, nothing else. The browser applies both policies, so an injected script or an inline event handler does not run. node tools/csp.js writes the hashes; run it after every change to an inline script (node tools/csp.js --check only checks, as the GitHub workflow does on every push).
In production the site is served by nginx, and these nginx snippets are what applies; the root .htaccess only carries the same rules for a host running Apache (nginx ignores it). The headers are in /etc/nginx/snippets/security-headers.conf (the same file is committed as tools/nginx/security-headers.conf, with tools/nginx/crosschain-deny.conf; .htaccess sets the same headers for Apache), included in the site's server block and again in every location that has its own add_header (nginx drops the server-level headers there). The same server block includes /etc/nginx/snippets/crosschain-deny.conf, which returns 404 for dot files and folders (except /.well-known/, used to renew the certificate), /tools/ and every .md file, whatever the git clone contains. Check: curl -sI https://crosschain-lukso.chainintegrate.it/up-wallet.html.
Check after every deploy. Each of these URLs must return 404 Not Found:
https://crosschain-lukso.chainintegrate.it/.git/HEADhttps://crosschain-lukso.chainintegrate.it/.git/confighttps://crosschain-lukso.chainintegrate.it/tools/decrypt.jshttps://crosschain-lukso.chainintegrate.it/decrypt.js (old location, removed by the pull)https://crosschain-lukso.chainintegrate.it/.gitignorehttps://crosschain-lukso.chainintegrate.it/AUDIT.md (and any other .md, such as vendor/README.md)
Roadmap
A direction, not a schedule. UP Wallet is growing towards a complete wallet for a Universal Profile on every network where it exists: open source, explaining every request in plain words, cross-chain first. Since 2026-10-25 the phone key comes first (it was step 6): the app signs by itself, with a key that stays on the phone, and MetaMask leaves the app. The website keeps signing through an external wallet.
- The phone key (app 0.9.0, done). A new key created on the phone, which never leaves it (still non-custodial), encrypted with the Android Keystore and used only after fingerprint or PIN, for every signature. It is added to the UP once per network from the Backup page, signed by an admin controller, as a controller with no admin permissions: calls, transfers, signatures, the gas relay and the profile data (so it can use all the UP's funds), never controller management. A lost phone is handled by revoking that key from another controller. MetaMask leaves the app; the website keeps it.
- The wallet on the computer: a browser extension (phase 1 done, 0.1.7, up-wallet-extension). The same UP Wallet page packaged as a desktop browser extension, as the Android app packages it for the phone, so that the computer needs no MetaMask either. An extension is installed code, versioned and updated only when the user chooses, unlike a web page, whose code comes from the server at every visit: that is why a page must not hold a key, and an extension can. Its own secp256k1 key, created in the extension, encrypted, and unlocked with a passkey (fingerprint, Windows Hello, Touch ID) through WebAuthn's PRF extension, or a password where no passkey gives a PRF value, for every signature; authorized on the UP from the Backup page with no admin permissions, as the phone key. No new contract. Done for Chrome, Edge and Brave (on GitHub releases, loaded in developer mode, no automatic updates), with WalletConnect kept alive in the extension. Next: Firefox, as an
.xpi signed by Mozilla as an unlisted add-on (installed with one click, updates included); dApps without WalletConnect in step 5; the extension stores later, after checking their rules for crypto wallets.
- The Android app on Google Play. Before the listing: an organization developer account (registered business, D-U-N-S number), Google's developer verification, and the store's forms (financial features, data safety for an app that keeps a key on the phone, with the privacy policy updated). Google Play's licensing rules for crypto apps cover custodial wallets and exchanges; non-custodial wallets are excluded.
- Clearer requests (in progress). Decode any call to a contract verified on the network's explorer, from its published ABI, besides the cases decoded today: done on Base, Arbitrum One and Arc (
abi-decode.js, app 0.8.0), with contracts named as the explorer names them; more networks as their explorers allow it. Name smart-account recipients from what they declare (ERC-7579 accountId()), as a hint.
- dApps without WalletConnect. The UP offered to web dApps as an injected wallet (EIP-1193, announced through EIP-6963), as MetaMask is: in the browser extension, in the browser's tabs (it needs the extension to reach every site, a much wider permission than today's, hence later and with its own review); in the Android app, through a dApp browser inside the app, with bookmarks. Every request goes through the same checks, simulation and signing window or fingerprint. Native apps keep using WalletConnect.
Requirements
- Your UP address: read from the Universal Profile extension, from LUKSO's Universal Profiles app through WalletConnect (on a phone, for example), or typed.
- A signing wallet such as MetaMask, connected to the target chain (in the Android app, from 0.9.0, the phone key instead, and in the browser extension the computer key, once authorized from the Backup page): the browser extension on a computer, or MetaMask on the phone through WalletConnect when the browser has no wallet. For deploys it can be any funded account. For Test, UP Wallet and the pages that change the UP (backup controller, Identity section 6, NFT reception, gas relay setup) it must be one of the profile's controllers.
- The original deployment calldata of your UP. The guide explains how to find it on the LUKSO explorer.
Security and privacy notes
- Irreversible actions. Deploys and transfers cannot be undone. Try a testnet or a small amount first.
- Chain checks. Every transaction requires the signing wallet, the RPC and the selected network to be on the same chain. A check is invalidated as soon as any input, the network or the wallet account changes.
- Private key handling. Operating the profile on another chain needs the original controller key (guide, steps 1 and 6). Import it into a dedicated wallet, and treat it as the key that also controls your profile on LUKSO.
- Scripts. The only script loaded from another site is
ethers 6.13.4 from cdnjs, pinned with Subresource Integrity; the WalletConnect bundles are served from this site (vendor/), with Subresource Integrity too. A Content-Security-Policy in every page lets only these files and the page's own inline scripts (by their hash) run.
- Third parties. WalletConnect's telemetry is turned off. There are no analytics or trackers. Checks are made through public RPCs, which can see your IP address and the addresses you query; you can use the "Custom RPC" option to choose your own provider. Some pages also call, only when used: Blockscout or Alchemy (lists of tokens and NFTs), IPFS gateways (profile images), the WalletConnect relay (UP Wallet, and the tool pages when you take the UP's address from the Universal Profiles app or connect MetaMask on a phone), the site's own relayer and signing service (gas paid by the site, subscriptions), LI.FI's public API (the operator's top-up from USDC, section 3c of the operator's page), and LUKSO's profile index (
envio.lukso-mainnet.universal.tech, a UP or a recipient searched by name).
- Support. Support will never ask for a private key, seed phrase or backup password.
Audit trail
Status: no professional audit yet. All the reviews below are the maintainer's own or AI-assisted, with local tests. None is a professional security audit. The contracts the gas relay depends on have never had a professional audit: UPPaymaster, UPVerifyingPaymaster and LUKSO's Extension4337, which LUKSO describes as experimental. A professional audit of the paymasters and the 4337 flow is required before the paid relay service holds significant customer funds. Until then, keep balances small and use the service at your own risk.
Last review (2026-10-29). An external, AI-assisted review of the whole project, the new browser extension included: not a professional audit, but an in-depth one (every repository's full diff, the extension's key handling read line by line, every earlier fix checked again in the code). No Critical, High or Medium; every earlier finding fixed. Three Low, accepted with their reasons: the extension's password fallback (the passkey is the recommended way), the site relayer on by default (UP Wallet's design), the server header's 'unsafe-inline' (the pages' own hash-based policy is the one that blocks scripts). Summary and status in AUDIT.md §17; its brief in §16.
Review policy (from 2026-10-29). The whole project is reviewed every six months by two LLMs of different providers, each from the same written brief, in separate environments with no shared context; the maintainer reads both reports and decides what to fix, and the decisions are recorded in AUDIT.md. The first pair was done on 2026-10-29 (Claude, section 17; Codex, its summary to come with the fixes); the next is due around April 2027. A structural change is reviewed again before its release, whatever the date: how a key is kept or signs (for example the key signing inside the hardware, roadmap step 8), the contracts, the gas relay's money flow, or a wider reach of the extension (dApps in the browser's tabs, roadmap step 5). Ordinary changes rely on the tests and the live tests until the next six-monthly pair. Not a professional audit, which stays planned for the gas relay when the paid service has significant users or funds.
| Date | Scope | Result | Report |
|---|
| 2026-09-27 | Whole repository and git history (commit f56dd29) | 2 High, 8 Medium, 9 Low, 6 Informational. All High and Medium findings are fixed. | AUDIT.md |
| 2026-09-29 | WalletConnect pages: up-wallet.html, up-walletconnect-basenames.html, vendored WalletKit (commit 47642bc) | 1 Medium, 3 Low (all fixed), 7 Informational (accepted or planned). Tested live on Base and Polygon. | AUDIT.md §7 |
| 2026-10-01 | Gas relay: Extension4337, UPPaymaster, relayer, the three Base UPs (AI-assisted) | The 4337 setup adds no way to move funds beyond what the controller key already allows. Findings fixed or tracked. | AUDIT.md §8 |
| 2026-10-02 | Whole repository at 40f0bc0, system live (AI-assisted) | 2 High and 3 of 4 Medium fixed; M-1 (paymaster gas per operation) open, bounded by the caps; some Low and Info in the hardening backlog. | AUDIT.md §9 |
| 2026-10-04 | UPVerifyingPaymaster (AI-assisted) | No Critical, High or Medium bug in the code. The signing key's power (VP-H1) is mitigated off-chain; Low and Info fixed or accepted. | AUDIT.md §10 |
| 2026-10-04, 2026-10-05 | Launch reviews of the whole system, toolkit and private signing service (AI-assisted; the second covers paid subscriptions) | No Critical or High. One Medium on the availability of the paid service (SP-A, no funds at risk; fixed with SP-B) and Low items open. H-1 and H-2 confirmed fixed. |
Main fixes from the 2026-09-27 audit:
- Wallet and RPC chain verification before every transaction. Previously the Send and Test pages could sign on the wrong chain, including LUKSO.
- A verification is invalidated whenever inputs, the network or the wallet account change.
- The local deploy page works with any profile's pasted calldata instead of a hard-coded list.
- HTML escaping of all untrusted values (a DOM XSS through pasted calldata is fixed).
- The Key Manager is derived from the calldata or read from
owner(), instead of using a hard-coded implementation.
- Correct LSP6 permission classification: admin-level permissions are always flagged.
- SRI on the ethers script, and a no-referrer policy.
tools/decrypt.js (moved out of the published files) rewritten: interactive input (public salt/IV kept as defaults), hidden password prompt, input validation.- Much more explicit private-key handling rules in the guide (steps 1 and 8).
Follow-up on the same date: gas prices are now read directly from the RPC. Before, ethers called a third-party gas-station API on Polygon, and the checks failed when that service was unreachable (AUDIT.md L-09).
Main fixes from the 2026-09-29 review of the WalletConnect pages:
- A transaction already broadcast is never reported as failed: if the answer to the dApp fails (expired session), the page says the transaction was sent and must not be repeated.
- Malformed transaction values are rejected instead of leaving the dApp waiting.
- EIP-712 messages without a chainId get a warning (the signature would be valid on every network where the UP exists).
- Sessions restored from a previous visit for another UP or network are closed.
The remaining recommendations (periodic RPC refresh, a second review of UP Wallet before removing its "experimental" label) are listed in AUDIT.md §5.
Contributing
Bug reports and improvements to the tools are welcome. This repository does not add new chains: the tools already work on any EVM chain through "Custom RPC", and official support for a chain is LUKSO's responsibility. Read CONTRIBUTING.md before opening an issue or a pull request.
License
Released under the MIT License, with these exceptions:
contracts/UPPaymaster.sol and contracts/UPVerifyingPaymaster.sol are under GPL-3.0 (text), like the ERC-4337 interfaces (@account-abstraction/contracts, GPL-3.0) they are built on.- Third-party code included in the repository keeps its own license: the WalletConnect bundles in
vendor/ (WalletConnect Community License Agreement of Reown, Inc., plus MIT/ISC/Apache-2.0/0BSD dependencies), the QR code library (MIT) and the sources embedded in contracts/*.input.json (LUKSO, ERC725, OpenZeppelin, @account-abstraction). See THIRD_PARTY_NOTICES.md.
The software is provided "as is", without warranty of any kind: these tools prepare irreversible on-chain transactions, and you use them at your own risk.
The ChainIntegrate name, logo and banner are not covered by the license.
The site relayer in tools/relayer/ is run by ChainIntegrate. It relays the operations of the UPs on the allowlist paymaster's list and of the UPs with an active subscription (sponsor paymaster, up-subscribe.html). Both are experimental and offered as they are.
