Our primary "smart contracts" consist of business logic (staking and math) in a cosmos-sdk based module. They run on our own cosmos chain.

We will in theory support token transfers of any cosmos-based IBC token. However, our system only interacts with the native currency of our chain, and we do not actually do any interactions with other types of tokens sent to our chain.

No.
Any limitations on values passed to the chain by protocol-specific actors are explicitly caught via validation. There is no special knowledge of unwritten limitations expected of any protocol-specific actor.

No.
There are no protocols we integrate with beyond IBC. We do not enforce any atypical constraints on our IBC code.

The permissioned functions are:

• AddToWhitelistAdmin
• RemoveFromWhitelistAdmin
• UpdateParams of which there are two: one in the emissions module and the other in the mint module

For each, the caller must simply have been added as a "whitelist admin" in the emissions module. This means that the emissions "tx function" AddToWhitelistAdmin() was called with an address of the admin, that RemoveFromWhitelistAdmin() was not successfully called with their address as an argument since last calling AddToWhitelistAdmin(), and that the address is a valid Bech32 string.

No.

Yes. These were also submitted as part of the audit. These are all facets of the Blockless network, including a head node that validators are expected to run in parallel to their node, and "Blockless worker nodes" that are ran by reputers and workers to submit losses or inferences and forecasts, respectively, when requested by the chain.

Each validator sets their env var to be a url that connects to their own Blockless head node. This is a simple server that initiates requests to all workers subscribed to a topic. We use a feature called "subgroups" where reputers and workers of each topics can subscribed to head nodes, specify what role they are to play (reputer or worker), specify the topic they are to play that role in (an integer). When a chain request is sent out, it includes data that is needed by reputers and workers to do their job, such as the nonce that determines which worker payloads should be judged by reputers.

After the head node receives a request, it conducts roll call, where workers that are part of that subgroup signal that they are ready to respond. The responsive workers then share their results with each other in a consensus mechanism between each other, signs their respective data, then a selected leader commits the batched data to the chain.

You can learn more about this and Blockless in general from their docs:
https://blockless.network/docs/protocol/core-concepts

Furthermore, delegators must claim their own rewards as they are awarded by calling RewardDelegateStake(), like a keeper of sorts.

No.

L2 not relevant. We're an L1.

Yes absolutely, here are the invariants/properties that should hold.
Topics

• The size of ActiveTopics should always be less than nextTopicId
• The size of churnableTopics should always be less than or equal to the size of ActiveTopics
• The size of rewardableTopics should always be less than or equal to ChurnableTopics
• The size of churnableTopics should always be less than or equal to params.MaxTopicsPerBlock
  Allora Staking (reputers, as opposed to cosmos validator staking):
• The balance of the totalStake in the emissions keeper should always equal the cosmos-sdk /x/bank balance of the "allorastaking" bank account
• the sum of all topicStake in every topic should always equal the totalStake
• the sum of all stakeReputerAuthority for a given topic should always equal the topic stake for that topic
• the sum of all stakeReputerAuthority should equal the total stake
• the stakeSumFromDelegator should always equal the sum of delegatedStakes[topicid, delegator, all reputers for that delegator])
• the stakeFromDelegatorsUponReputer should always equal the sum of delegatedStakes[topicid, all delegators for that reputer, reputer]
• the sum of all (delegateRewardsPerShare * delegated stake - reward debt) = the balance of the /x/bank AlloraPendingRewardForDelegatorAccountName module account
• the state of the stakeRemovalsByBlock and stakeRemovalsByActor should always be identical in terms of the number of keys in the map, and the content of those keys
• the sum of all stakeRemovals should always be less than or equal to the totalStake
  Mint module invariants
• The annual percentage yield of a staker should not exceed 12%

Delegation is modeled after the Sushi masterchef implementation, where the provisioning of rewards for delegators is maintained by themselves by calling RewardDelegateStake().

We implement a stake withdrawal delay on all actors with stake. This is a lengthy withdrawal period of time to ensure actors are committed to participating on the chain.

When stake is withdrawn, it still has the effect of being active so the consequences of placing stake there are fully felt. You can cancel a stake withdrawal at any time.

Like Tendermint, when your stake withdrawal period ends, the money is automatically sent to your wallet.
Similarly, when workers are rewarded, funds are automatically sent to their wallets.

We chose a "pull" pattern over "push" (from perspective of a worker) where the chain initiates Blockless requests to solicit losses and inferences. This offers us an efficiency gain by batching responses from actors via Blockless, so a fraction of the inbound requests are needed. The use of Blockless in this pattern also lowered the burden placed on nodes to connect to the Allora network, as Blockless abstracts much of the configuration necessary to connect to networks away, allowing workers and reputers to focus more on what they're best at.

We chose a "consumer-driven" pricing model for inferences because we expect that actors can drop out if they feel the price for their data are not worth their time. This plus off-chain communication mechanisms (e.g. public forums) are a fine, uncomplicated way to achieve price discovery. In this model, consumers pay the network for information from a particular topic, and those funds, as well as the topic's "weight", gradually drops per an exponential drip at the end of each topic's epoch. This ensures that the amount of funds a topic has left to spend is related to its "weight", so when funds are paid, the topic loses some probability of being churnable among the set of all topics.

We choose to implement a "competition" among topics by weight, where a topic with higher weight (one that has brought more value to ALLO via staked ALLO and/or consumer fees) is preferred to be churned over others. "Churning topics" means completing the process of soliciting inferences, judging them, then rewarding all involved. We only allow a fixed number of topics to be churned per block, which in theory drives competition among topics.

We use nonces to track requests based on the block that the request was sent. So if a worker request was sent at a particular height X, that is later associated to the returned inferences when they are returned. With this nonce, reputers can find said nonces then grade them.

We elected to combine much of the code into a monolithic module emissions purely for developer expediency.

All admins are super admins in that they can add and remove each other. All risks associated with that are acceptable risks.

Admins can set bad parameter values. This is an acceptable risk.

Yes. 12 hours, please.

We have a PDF of a previous, closed audit report for a slightly earlier version of the protocol we can share upon request.

Whitepaper:
https://whitepaper.assets.allora.network/whitepaper.pdf

Docs:
https://docs.allora.network/

Website:
https://www.allora.network/

The correct commit to use will be available on Friday morning for both repos requested. This may be the same as the commits presented at time of writing, but this is not guaranteed.

We ask that auditors look for both typical security vulnerabilities, but also departures of the codebase from the intentions defined in the whitepaper. This includes but is not limited to functions not correctly implemented or tied together as defined in the whitepaper. This requires an understanding of the math of the whitepaper, which we urge auditors to develop.