Introducing Brane
A modern Java SDK for Ethereum.
Brane is a Java 21 SDK for Ethereum. Working with blockchain data should feel like working with any other Java code. There is no code generation. Instead of running a tool to generate wrapper classes from a contract's ABI, you define a Java interface and Brane binds it at runtime. Ethereum addresses, amounts, and hashes each get their own Java type, so the compiler catches mistakes, like passing wei when you meant ether, before they become runtime bugs. Brane embraces modern Java features like records, sealed classes, pattern matching, and virtual threads, producing simple blocking code that scales.
What It Supports
- Transaction Types: Both standard EIP-1559 transactions (with automatic gas estimation) and EIP-4844 blob transactions, a newer format that lets L2 networks like Optimism and Arbitrum post data to Ethereum at significantly lower cost.
- Wallet Support: HD wallet support (BIP-39/BIP-44) for generating or restoring wallets from a recovery phrase. One 12 or 24-word phrase derives multiple accounts, the same standard MetaMask and Ledger use.
- Transaction Signing: EIP-712 typed data signing for structured messages. When a dapp asks you to approve a permit or sign a swap, this is what happens under the hood. Brane handles both programmatic signing and parsing requests from wallet connections.
- Real-time data: WebSocket subscriptions for blocks, transactions, and contract events. Multicall3 batching to combine many reads into one RPC call, useful for dashboards fetching dozens of values at once.
- Testing: Anvil integration with snapshot/restore, time manipulation, and address impersonation. Fast, deterministic integration tests that reset cleanly between runs.
Why Brane Exists
web3j has been the standard Java SDK for Ethereum for years. It works. It also carries friction that accumulates over time.
- Custom wrapper types everywhere. web3j uses its own type hierarchy, where
Uint256extendsIntTypeandDynamicByteswrapsbyte[]. These do not interoperate cleanly with standard Java types likeBigIntegerorString, so you end up writing conversion boilerplate. - Code generation for contracts. To call a smart contract, you typically run a command-line tool that generates Java wrapper classes from the contract's ABI. This works, but it adds a build step and can drift out of sync when contracts change.
- Reactive patterns for everything. web3j's API is built on
RxJava. Even simple operations like getting a block or sending a transaction return reactive types. For backend services that just need a result, this adds complexity without clear benefit.
brane.sh is live. Those interested in contributing can apply here.
