Flint Programming Language

June 2018

Flint is a new type-safe, contract-oriented programming language specifically designed for writing robust smart contracts on Ethereum.

Medium articles: Write Safer Smart Contracts and Flint: A New Language for Safe Smart Contracts on Ethereum

Programming 2018! paper: Writing Safe Smart Contracts in Flint

Current working paper: Flint for Safer Smart Contracts

Flint has been developed as part of projects and summer work at Imperial College Department of Computing under the supervision of Professors Susan Eisenbach and Sophia Drossopoulou. Its original developer was Franklin Schrans for his MEng thesis and then continued.

Flint is still under active development and proposes a variety of novel contract-oriented features.

Caller Protections

Caller protections require programmers to think about who should be able to call the contract’s sensitive functions. Protections are checked statically for internal calls (unlike Solidity modifiers), and at runtime for calls originating from external contracts.


// State declaration
contract Bank {
  var manager: Address

// Functions are declared in protection blocks,
// which specify which users are allowed to call them.
Bank :: (manager) { // manager is a state property.

  // Only `manager` of the Bank can call `clear`.
  func clear(address: Address) {
    // body

// Anyone can initialize the contract.
Bank :: (any) {
  public init(manager: Address) {
    self.manager = manager

Type States

Type States integrate a design pattern of stateful contracts into the language itself, which both require programmers to think about what state a function can be called in but also to prevent vulnerabilities (e.g. Parity Multi-Sig wallet) from mistakes with respect to administrating state. States are checked statically for internal calls (unlike Solidity modifiers), and at runtime for calls originating from external contracts.


// Enumeration of states.
contract Auction (Preparing, InProgress) {}

Auction @(Preparing, InProgress) :: caller <- (any) {
  public init() {
    // ...
    become Preparing

Auction @(Preparing) :: (beneficiary) {
  public func setBeneficiary(beneficiary: Address) mutates (beneficiary) {
    self.beneficiary = beneficiary

  func openAuction() -> Bool {
    // ...
    become InProgress

Immutability by default

Restricting writes to state in functions helps programmers more easily reason about the smart contract. A function which writes to the contract’s state needs to be annotated with the mutates (...) keyword, giving the list of variables that are mutated.


Bank :: (any) {
  func incrementCount() mutates (count) {
    // count is a state property
    count += 1

  func getCount() -> Int {
    return count

  func decrementCount() {
    // error: Use of mutating statement in a nonmutating function
    // count -= 1

Asset types

Assets, such as Ether, are often at the center of smart contracts. Flint puts assets at the forefront through the special Asset trait.

Flint's Asset type ensure a contract's state always truthfully represents its Ether value, preventing attacks such as TheDAO.

A restricted set of atomic operations can be performed on Assets. It is impossible to create, duplicate, or lose Assets (such as Ether) in unprivileged code. This prevents attacks relating to double-spending and re-entrancy.

Example use:

Bank :: account <- (balances.keys) {
   func deposit(implicit value: inout Wei) mutates (balances) {
    // Omitting this line causes a
    // compiler warning: the value received should be recorded.

  func withdraw() mutates(account, balances) {
    // balances[account] is automatically set to 0 before transferring.
    send(account, &balances[account])

The Asset feature is still in development. The FIP-0001: Introduce the Asset trait proposal includes more details.

Safer semantics

In the spirit of reducing vulnerabilities relating to unexpected language semantics, such as wrap-arounds due to integer overflows, Flint aims to provide safer operations. For instance, arithmetic operations on Int are safe by default: an overflow/underflow causes the Ethereum transaction to be reverted.